Introduction:-
In
Oracle Clusterware 11g release 2 (11.2), each node in a cluster has a local
registry for node-specific resources, called an Oracle Local Registry (OLR),
that is installed and configured when Oracle Clusterware installs OCR. OLR is
local registry for node specific resources. OLR is not shared by other nodes in
cluster. Multiple processes on each node have simultaneous read and write
access to the OLR particular to the node on which they reside, regardless of
whether Oracle Clusterware is running or fully functional.
Purpose Of OLR:-
It is
the very first file that is accessed while starting clusterware when OCR is
stored on ASM. OCR should be available to find out the resources which should be
up on a node. If OCR is on ASM, it can’t be read until ASM (which itself is a
resource for the node and this information is stored in OCR) is up. To solve
this issue, information about the resources which need to be started on a node
is stored in an operating system file
which is called OLR. Since OLR is operating system file, it can be accessed by
various processes on the node for read/write irrespective of the status of the
clusterware (up/down).
Hence,
when a node joins the cluster,OLR on
that node is read and various resources including ASM are started on the node. Once ASM is up,OCR
is accessible and is used henceforth to manage all the clusterware resources.If
OLR is missing or corrupted, clusterware can’t be started on that node!
Details :-
With
the OCR and Voting disks being placed in ASM, these files are accessible only
when the cluster processes have started up and ASM instance is up and running.
However without the OCR file the clusterware processes cannot start up. To
resolve this, a copy of the Oracle Local Registry(OLR) registry is now created
on each node during the initial installation which stores node specific
information and allows us to get around the problem. OLR stores the information
on the clusterware configuration, version information, and GpnP wallets. OHASD
process mostly manages OLR. The OCR in turn is managed by the CRSD processes.
The OLR is stored in GRID_HOME/cdata and must be available on the node before
other services can be started up.Without
this the clusterware will fail to start.
Location:-
The
OLR location is stored in '/etc/oracle/olr.loc' or '/var/opt/oracle/olr.loc'
depending on platform.
#The
default location after installing Oracle Clusterware is:-
GI Cluster: <GI_HOME>/cdata/<hostname.olr>
GI Standalone (Oracle Restart):
<GI_HOME>/cdata/localhost/<hostname.olr>
#To
check the location using command (as oracle user):-
[oracle@rac1 ~]$ ocrcheck -local -config
Oracle Local Registry configuration is :
Device/File
Name :
/u01/app/11.2.0/grid/cdata/rac1.olr
#To
check the location using command (as root user):-
[root@rac1 ~]# ocrcheck -local
Status of Oracle Local Registry is as follows :
Version : 3
Total space
(kbytes) : 262120
Used space
(kbytes) : 2372
Available
space (kbytes) : 259748
ID : 2017112488
Device/File
Name :
/u01/app/11.2.0/grid/cdata/rac1.olr
Device/File
integrity check succeeded
Local
registry integrity check succeeded
Logical
corruption check succeeded
What does OLR contain?
Information
stored in the OLR is needed by OHASD to start or join a cluster.
The
OLR stores data about :-
ORA_CRS_HOME
localhost
version
active
version
GPnP
details
OCR
latest backup time and location
information
about OCR daily, weekly backup location
node
name etc.
Commands :-
To
display the content of OLR on the local node to the text terminal that
initiated the program using the OCRDUMP utility
# ocrdump -local -stdout
# ocrdump -h
To
export OLR to a file
# ocrconfig –local –export file_name
Note :-
Oracle recommends that you use the -manualbackup and
-restore commands and not the -import and -export commands.When exporting OLR, Oracle recommends including
"olr", the host name, and the timestamp in the name string. For
example: olr_myhost1_20090603_0130_export
To
import a specified file to OLR
# ocrconfig -local –import file_name
To
manually back up OLR:(root)
# ocrconfig -local -manualbackup
Note:-
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. You should create a new backup when you
migrate OCR from Oracle ASM to other storage, or when you migrate OCR from
other storage to Oracle ASM. The default backup location for the OLR is in the
path Grid_home/cdata/host_name.
To view
the contents of the OLR backup file
#ocrdump -local -backupfile olr_backup_file_name
To
change the OLR backup location
#ocrconfig -local -backuploc new_olr_backup_path
To List
Available Backup
#ocrconfig -local -showbackup
Note:-
Clusterware maintains the history of the five most recent
manual backups and will not update/delete a manual backups after it has been created.
Below command shows manual backups in the registry though they are removed or
archived manually in OS file system by OS commands
[oracle@rac1 rac1]$ ocrconfig -local -showbackup
rac1 /u01/app/11.2.0/grid/cdata/rac1/backup_20170307_060226.olr
rac1 /u01/app/11.2.0/grid/cdata/rac1/backup_20170307_060225.olr
rac1 /u01/app/11.2.0/grid/cdata/rac1/backup_20170307_060222.olr
rac1 /u01/app/11.2.0/grid/cdata/rac1/backup_20170307_060220.olr
rac1 /u01/app/11.2.0/grid/cdata/rac1/backup_20170307_060218.olr
Here we can see list of 5 latest backups but physically we
have only 3 latest backups available.
[oracle@rac1 rac1]$ ls -ltr
total 18964
-rw------- 1 root root 6447104 Mar 7 06:02 backup_20170307_060222.olr
-rw------- 1 root root 6467584 Mar 7 06:02 backup_20170307_060225.olr
-rw------- 1 root root 6467584 Mar 7 06:02 backup_20170307_060226.olr
Restoring
OLR
We need to follow few steps to restore OLR, which have been described in my post "How To Restore OLR" Here .
References :-
https://docs.oracle.com/cd/E11882_01/rac.112/e41959/votocr.htm#CWADD837
