| Title: | VAX and Alpha VMS |
| Notice: | This is a new VMSnotes, please read note 2.1 |
| Moderator: | VAXAXP::BERNARDO |
| Created: | Wed Jan 22 1997 |
| Last Modified: | Fri Jun 06 1997 |
| Last Successful Update: | Fri Jun 06 1997 |
| Number of topics: | 703 |
| Total number of notes: | 3722 |
Hi, here is a new configuration : 2 alphaservers 4000 5/300 in cluster FDDI running V6.2-1h3. patches installed ALPSHAD05_062, ALPDRIV04_062 (drdriver) RDB v6.1 ECO4. A database on DSA310 ($20$dra0, $21$dra0). Each DRA0 is a RAID 1 device (2 RZ28s) Firmwares : RZ28 00010 KZPSC V2.36 ana/sys clue config gives : PAL code V1.19-2 console version V3.0-10 no errors in sh error The problem : an application gets the following error : %RDB-F-IO_ERROR, input or output error -RDMS-F-CANTWRITEDBS, error writing pages xxx -SYSTEM-F-NOPRIV, First, customer copied his database to an alphaserver 2000 with "standalone disks" ==> no error when using same application from the cluster (alphaserver 4000). But, another test consists in copying this database to the same DSA shadow set and the problem "disappears" also. Any hints very appreciated. Maria.
| T.R | Title | User | Personal Name | Date | Lines |
|---|---|---|---|---|---|
| 246.1 | Check With Oracle, Check Security Audits | XDELTA::HOFFMAN | Steve, OpenVMS Engineering | Tue Feb 25 1997 11:50 | 21 |
`NOPRIV' looks like either a site-specific OpenVMS local security configuration problem, an Rdb security configuration problem (Rdb has internal ACLs and internal security), or an Rdb internal error of some sort. It could certainly be an OpenVMS problem, but there's not enough information here to try to pin this down.) Please check with the folks over at Oracle first (to see if they have seen this before), and please enable and check OpenVMS auditing to determine if any OpenVMS security audits are being logged when the problem occurs. (The Oracle Rdb notes conference is ORAREP::NOMAHS::RDB_60; the RDB_60 conference is on the Oracle internal network, and is accessable to Oracle engineers.) There are specific steps involved with relocating or restoring an Rdb database onto another device, including specific RMU/ALTER commands. (The customer may already be aware of these commands.) We (and Oracle) will need to see the specific Rdb commands involved, and the full error message(s) from the Rdb failure, and any information from OpenVMS auditing, etc... | |||||
| 246.2 | AUSS::GARSON | DECcharity Program Office | Thu Feb 27 1997 01:03 | 6 | |
re .0
I believe this is a known incompatibility between certain versions of
Oracle RDB and certain versions of VMS. Something to do with PHY_IO
and shadowsets. The Oracle RDB conference (reference in .1) will have
details.
| |||||
| 246.3 | HERON::GODFRIND | Oracle Rdb Engineering | Fri Feb 28 1997 05:29 | 18 | |
> I believe this is a known incompatibility between certain versions of > Oracle RDB and certain versions of VMS. Something to do with PHY_IO > and shadowsets. The Oracle RDB conference (reference in .1) will have > details. That is correct. There used to be such a problem in Rdb V6.1-0 and V6.1-01. It got fixed in V6.1-02 and that fix is included in V6.1-04 (each ECO level includes all fixes from prior levels). However, there is another problem currently being fixed (the ECO with that fix, V6.1-11, is being made). That problem only happens when using global buffers and optimized page transfer. Disabling optimized page transfer (= the "page transfer via memory" sql option) makes the problem go away. In any case, your best bet (or the customer's) is to call the local Oracle support. /albert | |||||
| 246.4 | Disabling optimized page transfer. | PRSSOS::MENICACCI | Fri Feb 28 1997 10:35 | 8 | |
Thanks to you all. The audit gives nothing more. But thanks to the pointer to RDB notesfile, we could help the customer who is gonna call his Oracle support. Maria. | |||||