0% found this document useful (0 votes)
82 views

How To Backup or Restore OLR in Grid Infrastructure (Doc ID 1193643.1)

The document discusses Oracle Local Registry (OLR) which contains node-specific configuration for Oracle Grid Infrastructure. It provides steps to backup and restore the OLR manually or automatically depending on the Oracle version. The steps include using crsctl commands to stop and start the OLR, and ocrconfig commands to backup, list backups, and restore the OLR.

Uploaded by

geteaglet
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
82 views

How To Backup or Restore OLR in Grid Infrastructure (Doc ID 1193643.1)

The document discusses Oracle Local Registry (OLR) which contains node-specific configuration for Oracle Grid Infrastructure. It provides steps to backup and restore the OLR manually or automatically depending on the Oracle version. The steps include using crsctl commands to stop and start the OLR, and ocrconfig commands to backup, list backups, and restore the OLR.

Uploaded by

geteaglet
Copyright
© © All Rights Reserved
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 3

Document 1193643.

1
support.oracle.com/epmos/faces/DocumentDisplay

Applies to:
Gen 1 Exadata Cloud at Customer (Oracle Exadata Database Cloud Machine) - Version N/A and
later
Oracle Cloud Infrastructure - Database Service - Version N/A and later
Oracle Database Backup Service - Version N/A and later
Oracle Database Cloud Exadata Service - Version N/A and later
Oracle Database Exadata Express Cloud Service - Version N/A and later
Information in this document applies to any platform.

Goal
Oracle Local Registry (OLR) is introduced in 11gR2/12c Grid Infrastructure. It contains local node
specific configuration required by OHASD and is not shared between nodes; in other word, every
node has its own OLR.

This note provides steps to backup or restore OLR.

Solution

OLR location
The OLR location pointer file is '/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 backup
OLR will be backed up during GI configuration(installation or upgrade). In contrast to OCR, OLR
will NOT be automatically backed up again after GI is configured, only manual backups can be
taken. If further backup is required, OLR needs to be backed up manually. To take a backup of the
OLR use the following command.

1/3
# <GI_HOME>/bin/ocrconfig -local -manualbackup

In 12.2.0.1 & Above


OLR autobackup functionality is available as part of BUG:24799186 (superseded by
BUG:26493466)included in 18.1 or GI RU 12.2.0.1.180116

To list backups
To List the backups currently available:

# <GI_HOME>/bin/ocrconfig -local -showbackup

<node1> 2010/12/14 14:33:20


/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20101214_143320.olr
<node1> 2010/12/14 14:33:17
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20101214_143317.olr

Clusterware maintains the history of the five most recent manual backups and will not
update/delete a manual backups after it has been created.

$ocrconfig -local -showbackup shows manual backups in the registry though they are removed or
archived manually in OS file system by OS commands

#ocrconfig -local -showbackup


<node1> 2014/02/21 08:02:57
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20140221_080257.olr
<node1> 2014/02/21 08:02:56
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20140221_080256.olr
<node1> 2014/02/21 08:02:54
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20140221_080254.olr
<node1> 2014/02/21 08:02:51
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20140221_080251.olr
<node1> 2014/02/21 08:02:39
/opt/app/oracle/grid/11.2.0.1/cdata/<node1>/backup_20140221_080239.olr

#ls -ltr /opt/app/oracle/grid/11.2.0.1/cdata/<node1>


total 38896
-rw------- 1 root root 6635520 Feb 21 08:02 backup_20140221_080256.olr
-rw------- 1 root root 6635520 Feb 21 08:02 backup_20140221_080257.olr

To restore
Be sure GI stack is completely down and ohasd.bin is not up and running, use the following
command to confirm:

ps -ef| grep ohasd.bin

This should return no process, if ohasd.bin is still up and running, stop it on local node:

2/3
# <GI_HOME>/bin/crsctl stop crs -f <========= for GI Cluster

OR

# /bin/crsctl stop has <========= for GI Standalone


Once it's down, restore with the following command:

# <GI_HOME>/bin/ocrconfig -local -restore <olr-backup>

If the command fails, create a dummy OLR, set correct ownership and permission and retry the
restoration command:

# cd <OLR location>
# touch <hostname>.olr
# chmod 600 <hostname>.olr
# chown <grid>:<oinstall> <hostname>.olr

Once it's restored, GI can be brought up:

# <GI_HOME>/bin/crsctl start crs <========= for GI Cluster

OR

$ /bin/crsctl start has <========= for GI Standalone, this must be done as grid user.
In 12.1 onward, if patches are applied after the OLR is backed up, and later the backup is
restored, the patch level will be different and GI won't start with error:

CRS-6706: Oracle Clusterware Release patch level ('1196363452') does not match Software
patch level ('600291166'). Oracle Clusterware cannot be started.

To fix the above problem, run as root user:

<GI_HOME>/crs/install/rootcrs.sh -prepatch
<GI_HOME>/crs/install/rootcrs.sh -postpatch

References

3/3

You might also like