1748089 Members
5158 Online
108758 Solutions
New Discussion

OpenVMS and RDB

 
ww593369
Occasional Visitor

OpenVMS and RDB

To Experts,

 

This is actually regarding Oracle RDB running under OpenVMS Alpha.

Who knows and can tell where is the Oracle RDB Forum I can ask questions ?? Links ??

 

I recently did a RDB restore to its original location to make all DB file's version to be 2 (including .RDB; .RDA; .SNP etc.) so I want to delete the version 1 DB file set. I use "SQL> drop database filename SYS$SYSROOT:[SYSMGR.GCXDB]mf_personnel.rdb;1;" to drop, but the command hang over night and finally returns this infor:

 

%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error opening database root file VMSD01$DKA0:[SYS0.SYSMGR.GCXDB]MF_PERSONNEL.RDB;1
-SYSTEM-W-ACCONFLICT, file access conflict

 

Is anyone can tell why and how to fix this problem ??

Thanks much inadvance.

 

6 REPLIES 6
tsgdavid2
Occasional Advisor

Re: OpenVMS and RDB

Spoiler

Have you tried to see what files are open on the disk:  The following command will list open files and the process(es) that has them open:

 

SHOW DEVICE/FILES VMSD01$DKA0:[

 

David Williams
tsgdavid2
Occasional Advisor

Re: OpenVMS and RDB

have you tried to see what files are open on the disk? The following command will show this information:

SHOW DEVICE/FILES/NOSYS VMSD01$DKA0:
David Williams
Andy_Bustamant2
Advisor

Re: OpenVMS and RDB

>>>recently did a RDB restore to its original location to make all DB file's version to be 2

 

Before you do anything else, if you didn't create the backup with RMU, you should delete the version 2 files. What are trying to accomplish?  When you say you "did an RDB restore" were you using the RDB RMU function or were you using the operating system backup utility. 

 

In ether case, the original version 1 files are open by the RDB instance. If you created an RMU backup and restore, the version 2 files will reflect the database at the point in time the backup was created.  If any changes have been made, they will be lost if the version 1 files are delteted. 

 

This is potentially a dangerous situation for data integrity.  Consider investing in an RDB consultant.  RDB is an Oracle product and documentation on RMU is availabe http://www.oracle.com/technetwork/database/rdb/documentation/rdb-doc-index-094939.html#rmustathdbk 

 

Keith Cayemberg
Trusted Contributor

Re: OpenVMS and RDB

This is actually regarding Oracle RDB running under OpenVMS Alpha.

Who knows and can tell where is the Oracle RDB Forum I can ask questions ?? Links ??

JCC hosts the Oracle Rdb Listserver which is also monitored by Oracle Rdb software engineers. Instructions for how to subscribe to the Rdb Listserver are found here...

http://www.jcc.com/listserver.htm

 

I recently did a RDB restore to its original location to make all DB file's version to be 2 (including .RDB; .RDA; .SNP etc.) so I want to delete the version 1 DB file set. I use "SQL> drop database filename SYS$SYSROOT:[SYSMGR.GCXDB]mf_personnel.rdb;1;" to drop, but the command hang over night and finally returns this infor:

 

%RDB-F-SYS_REQUEST, error from system services request
-RDMS-F-FILACCERR, error opening database root file VMSD01$DKA0:[SYS0.SYSMGR.GCXDB]MF_PERSONNEL.RDB;1
-SYSTEM-W-ACCONFLICT, file access conflict

 

Is anyone can tell why and how to fix this problem ??

Thanks much inadvance.

Probably version 1 of your database was still open, meaning it is being accessed by the Rdb monitor process.  As long as the database is still accessed by another user or the Rdb monitor process, the drop database command will wait for the database to be closed, or if it must wait too long (I believe the default is one hour) the command will time-out with an error such as the one you received.

 

I tried to reproduce your situation...

 

 

CH21 show dev/files $DISK3

Files accessed on device $21$DKB300: (CH21) on  5-JUL-2011 08:17:44.24

Process name      PID     File name
                00000000  [000000]INDEXF.SYS;1
RDMS_MONITOR71  20200433  [PROSI.DB.DB.PUCHOV]MENSTE.RDB;4
RDMS_MONITOR71  20200433  [PROSI.DB.DB.PUCHOV]MENSTE.RDB;1

 

[at this point the drop command hangs]

Instead of waiting for the command to time-out, I then logged-in to another process and closed the version one of the database...

 

Immediately the drop command in the first process completed.

 

 

CH21 show dev /files $DISK3

Files accessed on device $21$DKB300: (CH21) on  5-JUL-2011 08:36:09.05

Process name      PID     File name
                00000000  [000000]INDEXF.SYS;1
RDMS_MONITOR71  20200433  [PROSI.DB.DB.PUCHOV]MENSTE.RDB;4

If the RMU/CLOSE fails to close database due to a user still in the database, you can use...

 

$ RMU/CLOSE/ABORT=DELPRC $21$DKB300: [PROSI.DB.DB.PUCHOV]MENSTE.RDB;1

 

or if your application is programmed with condition handlers to respond to a FORCEX signal...

 

$ RMU/CLOSE/ABORT=FORCEX $21$DKB300: [PROSI.DB.DB.PUCHOV]MENSTE.RDB;1

 

to throw all the users out of the database.

 

Cheers!

 

Keith Cayemberg

 

 

Keith Cayemberg
Consultant
Wipro Technologies
Tim_Peer
Occasional Collector

Re: OpenVMS and RDB

Another comment on closing an Rdb database using DCL: $RMU/Close. If the database is opened by another node on a cluster... issue the DCL command: 

 

$RMU/CLOSE/CLUSTER/ABORT=DELPRC

 

Regards,

TRitter
Occasional Visitor

Re: OpenVMS and RDB

This command will do exactly what it says.

 

$RMU/CLOSE/CLUSTER/ABORT=DELPRC

 

But understand the system impacts if you have 1000 connections compared to say 10. The impact of recovery processes handling can halt database activities for quite sometime. Are you running "global buffers" ? Bigger impact.

Know your systems.