[Search for users] [Overall Top Noters] [List of all Conferences] [Download this site]

Conference orarep::nomahs::rdb_60

Title:Oracle Rdb - Still a strategic database for DEC on Alpha AXP!
Notice:RDB_60 is archived, please use RDB_70..
Moderator:NOVA::SMITHISON
Created:Fri Mar 18 1994
Last Modified:Thu May 29 1997
Last Successful Update:Fri Jun 06 1997
Number of topics:5118
Total number of notes:28246

5084.0. "Filaccerr...acconflict on root file" by 138.2.136.82::GHODSON () Thu Feb 27 1997 11:37

Hi:

I have a customer on a 4 node VAX cluster running VMS 6.2 with Rdb 6.1-04.
Everything was fine...until yesterday.

He has a command procedure which does an RMU/CLOSE/CLUSTER/WAIT on his
database, followed by a "RDO> CHANGE DATABASE FILE ... NOJOURNAL."  Last
night when this was run, it got:

     -rdms-f-filaccerr, ...error opening the db root file
     -system-w-acconflict, ...

This command file has worked fine for a long time until last night.
This morning he was able to disable journaling and do some db maintenance.
Then he tried to enable aij and got the exact same error:

    $ rmu/close/cluster/wait     <--  no /abort qualifier
    $ rmu/dump/users ... no active users
    $ rmu/show/users ... requested database is not is use
    $ mcr sql$
    sql> alter database filename ... add journal ...
    -rdms-f-filaccerr, ...error opening the db root file
    -system-w-acconflict, ...

He then did a SHOW DEV/FILES on each of the 4 nodes for the root file
device and it did not show an open channel to the root file.  He also
tried the sql alter database on a different node with the same result.
The root file is on a solid state drive, ESC20:. Eventually he was able 
to do the alter database to set up his aij.

Any ideas on what could be causing this error and how he can isolate
it next time?

Thanks.
--Gary Hodson
T.RTitleUserPersonal
Name		DateLines
5084.1NOVA::SMITHIDon&#039;t understate or underestimate Rdb!Thu Feb 27 1997 11:396
~     -system-w-acconflict, ...

Well VMS thinks it is open already.  Was a VMS BACKUP in progress by any
chance?

Ian
5084.2sql$database?caotv1.ca.oracle.com::BZINN[email protected]Thu Feb 27 1997 11:533
    Did somebody define an SQL$DATABASE logical in some .COM file he's
    passing through that points to the database he's working with?
5084.3hotrdb.us.oracle.com::PMEADPaul, [email protected], 719-577-8032Thu Feb 27 1997 12:184
    If SHOW DEVICE/FILE doesn't show the file, and he is sure he still gets
    the error even when SHOW DEVICE/FILE doesn't show the file, then I
    suspect VMS has gotten confused somehow.  He might want to ask VMS
    support if there are any known problems in that area.
5084.4Thanksm5.us.oracle.com::GHODSONThu Feb 27 1997 12:4014
    Thanks for the replies.  I talked to the customer again and he is
    sure that there was no vms backup being done and also that no user
    defined sql$database to this database causing it to be inadvertently
    openned.
    
    He then said that another site experienced this problem yesterday
    also, so that maybe it is an application issue.  I did suggest that
    next time it happens, to do the following from each node:
         $ anal/sys
         SDA> set output channel.log
         SDA> show proc/channel all
    and then search the channel.log for his database root filename.
    
    --Gary
5084.5ORAREP::HERON::GODFRINDOracle Rdb EngineeringThu Feb 27 1997 12:4312
>    Did somebody define an SQL$DATABASE logical in some .COM file he's
>    passing through that points to the database he's working with?

That in itself should not caus any trouble (especially not in RDO) However, I'd
like to follow on Brenda's idea. Is it possible that someone defined the
logical RDOINI and/or SQLINI ? Those logicals point to command files that get
executed each time RDO or SQL is started. 

A command in there could cause the database to be automatically attached and
would make the other command (ALTER) fail.

/albert