Oracle - Unable to identify control file

[Clive Nicholas]

I have a spare dual server system running HP-UX B.11.00 and Oracle 8.0.5
The servers are setup to use serviceguard so that the server running the package in the cluster can access the oracle DB, stored on a shared volume group.
My question is this: One of the servers can access the shared disks and mount and open the dtabase with no problems.
However, when I switch servers and try to do the same process from the second server, it cannot open the database and reports that it is "Unable to identify the controlfile".
I cannot understand what could cause this.
I have temporarily made the volume group non-cluster aware with vgchange -c n /dev/vg05 , then activated the volume group outside of the cluster on one server first. I am then able to mount and open the dtabase on this server. I shut the dtabase down and deactivated the volume group before trying the same process on the other. I can activate the volume group and even navigate to the /dev/vg05 directory and view the three control files. But i am unable to open the database as it cannot identify the controlfile again.
I can't understand this as surely both servers are looking at the same database and controlfile when they have access to this volume group. So why should one server fail to identify the control file when the other cannot identify it ?
I have checked the alert.log on the problem server and the message is simply that it is Unable to access control file and Permission is denied.

[Kapil Jha]

Hi Clive,

If I am understanding you point currently, its like you have 2 cluster machine, accessing a shared storage and only server can open the data base.

If this is, then its absolutely right cause in cluster Oracle need to be run on one machine at one point of time and if it runs on other then there are great chance to have currupt database, transaction would be confused on where to go.

FOr this thing you can use RAC (real application cluster) on which DB runs on both machine but its still active on one, only when other machine goes down it would route the transaction to other machine withing 1-2 seconds.

I hope this would help.

BR,
Kapil+

[Sanjay_6 · Accepted solution]

Hi,

Did you check the permission of the /dev/vg05 directory, the permission on the control file if it is a raw device database to make sure the raw device is owned by oracle user id.

If it is a flat filesystem database, the permision of the mount point and the directory within which the control file reside.

Can you as "oracle" or your Database user, navigate into the directory where the control file is located. Does you "Database" user has read & write permission to the control file ?

Hope this helps.

Regds
Sanjay

[Rita C Workman]

OK...works on first node, oracle doesn't on second node.
But on second node you can mount the volume group and it mounts fine.
On MC/SG, rem out the startup of Oracle and make sure that MC/SG will mount and activate the volume properly. (I'm guessing it will, but do it to be sure).
Double check that all mountpoints are there and correct.

..Now with package up and volume group mounted, it is an Oracle issue. Check Oracle's "init" file. The one that controls things like where control files go. You're looking for where it is pointing a control file, is it within the parameters of the package & are permissions solid. I have caught DBA's putting this on some mountpoint in vg00, and then of course on failover...poof things don't work cause it didn't failover.
Point...make sure that everything you need to start Oracle is contained within the package. On rare occassions where something must be in vg00, then make sure they are documented and kept current.

Just a thought,
Rita

[Clive Nicholas]

OK .. thanks for all your responses.
The problem is now sorted.
Solution was indeed very simple and was, as you suggested, a matter of permissions.
I had checked the permissions, (but from the server that had worked)and of course they were fine. I had restored the local disks on the other server from a backup DAT and had incorrectly assumed that the permsisions would remain as they should be, but for some reason they were not .. they were owned by root on this server.
I have now changed ownership of these to oracle:dba and all is well.
I'm afraid I overlooked this !
Thanks to everone who helped me out with this.

[Clive Nicholas]

Problem sorted - thanks to all!