Oracle Clusterware Diagnosis - Expert Oracle RAC Performance Diagnostics and Tuning - page 538

877: [ OCRRAW][1666246176]proprinit: Successfully initialized the backend handle (propribctx).
877: [ OCRAPI][1666246176]proa_init: Successfully initialized the Storage Layer.
879: [ OCRAPI][1666246176]proa_init: Successfully initlaized the Messaging Layer.
979: [ OCRAPI][1666246176]a_init:18: Thread init successful
979: [ OCRAPI][1666246176]a_init:19: Client init successful
2014-01-17 22:39:22.
024: [ OCRAPI][1666246176]a_init:21: OLR init successful. Init Level [1]
What if the OLR file is missing or has been accidently removed from its current location listed in the
/etc/oracle/olr.loc file? The following workshop discusses this scenario and what's required to get the node
functional again.
Workshop
A missing or corrupted OLR file only affects the node of the cluster from which it is missing or on which it is
corrupted. Other nodes remain functional. As discussed earlier, OLR is used by the OHASD to read the resources that
are to be started on each specific node during clusterware and node startup. This means the file is only required once
during node reboot and clusterware startup. This file is not later read—even for stopping and starting the clusterware
stack using the crsctl utility ( crsctl stop cluster -all ) provided the OHASD demaon is still up and running.
However if the OHASD crashes or is stopped for some reason, the clusterware would not start without the OLR file
being present.
Step 1
The systems administrator had shut down the clusterware stack to complete a regular maintenance using
crsctl stop cluster -all
After maintenance was complete, the system administrator tried to restart the clusterware using the following
crsctl command. However, the clusterware failed to start.
crsctl start cluster -all
The first step in Oracle Database 11g Release 2 and higher is to look for any entries in the clusterware alert log
and OHASD log files. In prior releases the OCSSD log would report any startup issues.
Unfortunately, the OHASD log does not contain any information pertaining to the error. This may be because the
OHASD has not started and the daemon is unable to write any information to the log files.
Step 2
An important prerequisite for the OHASD process to start is the availablility of the OLR file. The first step is to check
whether the OLR file exists or not.
Using the definition contained in the olr.loc file, the current location of the OLR file can be determined.
The olr.loc file is stored in /etc/oracle directory on the respective nodes of the cluster.
[root@ssky1l4p2 ]# cat /etc/oracle/olr.loc
olrconfig_loc=/u01/app/12.1.0.1/grid/cdata/ssky1l4p2.olr
crs_home=/u01/app/12.1.0.1/grid