Database Reference
In-Depth Information
Here is an extract from the OLR file. Compare this data with the data illustrated earlier from the OCR file.
[SYSTEM.crs.user_default_dir]
ORATEXT : /u01/app/12.1.0/grid/ohasd/public
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,
OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
[SYSTEM.ORA_CRS_HOME]
ORATEXT : /u01/app/12.1.0/grid
SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ,
OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}
Each tier is managed and administrated by Oracle's high availability services daemon (OHASD) processes, which
use appropriate privileges to manage them. For example, all SYSTEM -level resources or application definitions would
require “root,” or super user, privileges to start, stop, and execute resources defined at this level. However, those
defined at the DATABASE level will require “DBA” privileges to execute.
Apart from the difference mentioned previously, the following are some of the other differences:
1.
OLR is configured on local storage and only contains the resource-related information
pertaining to the local server or node in the cluster.
2.
Unlike the OCR, the clusterware does not automatically back up the OLR. It's a good
practice to add the OLR file from all nodes into the backup strategy.
3.
Unlike OCR, OLR cannot be stored on ASM or on shared storage—it would defeat the
purpose of having an OLR file. The OLR file is maintained locally on each node to help
the clusteware start some of the critical resources while it waits for the ASM disks to be
mounted, and the OCR files are visible to the clusterware.
OLR plays an important role during the startup process of the cluster on each node. The following output
illustrates the first few steps that take place when the OHASD process is started and reads the OLR file to get the
node-level information.
Oracle Database 12c Clusterware Release 12.1.0.1.0 - Production Copyright 1996, 2013 Oracle.
All rights reserved.
2014-01-17 22:39:21.
689: [ default][1666246176] OHASD Daemon Starting. Command string :reboot
689: [ default][1666246176] OHASD params []
753: [ default][1666246176]
753: [ default][1666246176] Initializing OLR
753: [ default][1666246176] proa_init: OLR Abstraction layer initialization. Bootlevel:[1]
876: [ OCRAPI][1666246176]a_init: Successfully initialized the patch management context.
876: [ OCRAPI][1666246176]a_init: Successfully initialized the OLR specific states.
876: [ OCRAPI][1666246176]a_init:13: Clusterware init successful
876: [ OCRAPI][1666246176]a_init:15: Successfully initialized the Cache layer.
876: [ OCRRAW][1666246176] proprioo: opening OCR device(s)
876: [ OCRRAW][1666246176]proprioo: Successfully opened the non-ASM locations if configured.
876: [ OCRRAW][1666246176] proprioo: for disk 0 (/u01/app/12.1.0/grid/cdata/ssky3l11p1.olr), id match (1),
total id sets, (1) need recover (0), my votes (0), total votes (0), commit_lsn (30), lsn (30)
877: [ OCRRAW][1666246176]proprioo: my id set: (745565135, 1028247821, 0, 0, 0)
877: [ OCRRAW][1666246176]proprioo: 1st set: (745565135, 1028247821, 0, 0, 0)
877: [ OCRRAW][1666246176]proprioo: 2nd set: (0, 0, 0, 0, 0)
877: [ OCRRAW][1666246176]proprinit: Successfully initialized the I/O module (proprioini).
 
Search WWH ::




Custom Search