Why OLR is Required
Before we get into this, we should see some of the improvements in Oracle 11gR2 RAC infrastructure. Until 11gR2, the CRS resources namely the OCR components and the voting disks were maintained in RAW or shared file systems. With the new 11gR2, the Oracle clusterware related files can be maintained in Oracle ASM (Automatic Storage Management). A feature that was introduced with Oracle 10g DB release. This ability to host OCR and Voting disks in ASM poses an interesting situation.
In order for the cluster resources to be up, the ASM needs to be up. If ASM needs to be up, the clusterware components should be functional. By having all the CRS and cluster resource information stored in OCR, this contradicting situation cannot be resolved unless somehow the cluster specific components detail is separately maintained from other resources/services.
As a solution, Oracle has come up with a new approach; the Oracle Local Registry. The Oracle Local registry maintains the node specific information and gets created with Oracle Clusterware installation of OCR. Since this maintains node specific resources, the clusterware components (crs,css,ctss,evm,gip, and asm) can be made available, with ASM being made available, this makes the OCR and voting disks access possible which eventually opens up the various cluster resources and components.
Without OLR, the clusterware resources will not start which in turn will not start the dependent components.
Note:
Oracle Clusterware includes two important components that manage configuration and node membership: Oracle Cluster Registry (OCR), which also includes the local component Oracle Local Registry (OLR), and voting disks.
1. OCR manages Oracle Clusterware and Oracle RAC database configuration information
2. OLR resides on every node in the cluster and manages Oracle Clusterware configuration information for each particular node
3. Voting disks manage information about node membership. Each voting disk must be accessible by all nodes in the cluster for nodes to be of the cluster
4. You can store OCR and voting disks on Oracle Automatic Storage Management (Oracle ASM), or a certified cluster file system.
Important Points for OLR
1. OCR contains information about all Oracle resources in the cluster.
2. OLR is a registry similar to OCR located on each node in a cluster, but contains information specific to each node. It contains manageability information about Oracle Clusterware, including dependencies between various services. Oracle High Availability Services uses this information. OLR is located on local storage on each node in a cluster. Its default location is in the path Grid_home/cdata/host_name.olr, where Grid_home is the Oracle Grid Infrastructure home, and host_name is the host name of the node.
3. The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR.
4. GRID_HOME/cdata/localhost/$host_name.olr
e.g /u01/app/oracle/product/11.2.0/grid/cdata/localhost/node1.olr
even we can also check the location of this file from
/etc/oracle/olr.loc
5. OLR is automatically installed when we install Oracle Grid Infrastructure S/W
6. The OLR is managed by adding the –local option to the OCRCHECK, OCRDUMP, and OCRCONFIG commands as shown in the slide.
e.g $ ocrcheck –local
$ ocrdump –local –stdout
$ ocrconfig –local -manualbackup
7. You can define the backup location of the OLR using the ocrconfig –local –backuploc file_name command.
8. The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR.
9. You should create a new OLR backup each time you modify your Oracle Restart configuration.
Thanks,
Before we get into this, we should see some of the improvements in Oracle 11gR2 RAC infrastructure. Until 11gR2, the CRS resources namely the OCR components and the voting disks were maintained in RAW or shared file systems. With the new 11gR2, the Oracle clusterware related files can be maintained in Oracle ASM (Automatic Storage Management). A feature that was introduced with Oracle 10g DB release. This ability to host OCR and Voting disks in ASM poses an interesting situation.
In order for the cluster resources to be up, the ASM needs to be up. If ASM needs to be up, the clusterware components should be functional. By having all the CRS and cluster resource information stored in OCR, this contradicting situation cannot be resolved unless somehow the cluster specific components detail is separately maintained from other resources/services.
As a solution, Oracle has come up with a new approach; the Oracle Local Registry. The Oracle Local registry maintains the node specific information and gets created with Oracle Clusterware installation of OCR. Since this maintains node specific resources, the clusterware components (crs,css,ctss,evm,gip, and asm) can be made available, with ASM being made available, this makes the OCR and voting disks access possible which eventually opens up the various cluster resources and components.
Without OLR, the clusterware resources will not start which in turn will not start the dependent components.
Note:
Oracle Clusterware includes two important components that manage configuration and node membership: Oracle Cluster Registry (OCR), which also includes the local component Oracle Local Registry (OLR), and voting disks.
1. OCR manages Oracle Clusterware and Oracle RAC database configuration information
2. OLR resides on every node in the cluster and manages Oracle Clusterware configuration information for each particular node
3. Voting disks manage information about node membership. Each voting disk must be accessible by all nodes in the cluster for nodes to be of the cluster
4. You can store OCR and voting disks on Oracle Automatic Storage Management (Oracle ASM), or a certified cluster file system.
Important Points for OLR
1. OCR contains information about all Oracle resources in the cluster.
2. OLR is a registry similar to OCR located on each node in a cluster, but contains information specific to each node. It contains manageability information about Oracle Clusterware, including dependencies between various services. Oracle High Availability Services uses this information. OLR is located on local storage on each node in a cluster. Its default location is in the path Grid_home/cdata/host_name.olr, where Grid_home is the Oracle Grid Infrastructure home, and host_name is the host name of the node.
3. The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR.
4. GRID_HOME/cdata/localhost/$host_name.olr
e.g /u01/app/oracle/product/11.2.0/grid/cdata/localhost/node1.olr
even we can also check the location of this file from
/etc/oracle/olr.loc
5. OLR is automatically installed when we install Oracle Grid Infrastructure S/W
6. The OLR is managed by adding the –local option to the OCRCHECK, OCRDUMP, and OCRCONFIG commands as shown in the slide.
e.g $ ocrcheck –local
$ ocrdump –local –stdout
$ ocrconfig –local -manualbackup
7. You can define the backup location of the OLR using the ocrconfig –local –backuploc file_name command.
8. The OLR is backed up at the end of an installation or an upgrade. After that time, you can only manually back up the OLR. Automatic backups are not supported for the OLR.
9. You should create a new OLR backup each time you modify your Oracle Restart configuration.
Thanks,
Nice post. Thanks for sharing
ReplyDelete