OpenVMS and RDB

[ww593369]

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.

[tsgdavid2]

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:[

[tsgdavid2]

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:

[Andy_Bustamant2]

>>>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]

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

[Tim_Peer]

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]

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.