topic Re: OpenVMS and RDB in Operating System - OpenVMS

OpenVMS and RDB

ww593369 — Tue, 28 Jun 2011 12:05:25 GMT

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.

Re: OpenVMS and RDB

tsgdavid2 — Tue, 28 Jun 2011 18:35:28 GMT

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

Re: OpenVMS and RDB

tsgdavid2 — Tue, 28 Jun 2011 18:37:41 GMT

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:

Re: OpenVMS and RDB

Andy_Bustamant2 — Fri, 01 Jul 2011 22:43:12 GMT

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

Re: OpenVMS and RDB

Keith Cayemberg — Tue, 05 Jul 2011 06:48:22 GMT

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

%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

Re: OpenVMS and RDB

Tim_Peer — Mon, 11 Jul 2011 17:25:21 GMT

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,

Re: OpenVMS and RDB

TRitter — Wed, 07 Sep 2011 06:36:09 GMT

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.