【MOS】How to backup or restore OLR in 11.2/12c Grid Infrastructure

How to backup or restore OLR in 11.2/12c Grid Infrastructure (文档 ID 1193643.1)

In this Document

Goal
Solution
  OLR location
  To backup
  To list backups
  To restore
References

APPLIES TO:

Oracle Database - Enterprise Edition - Version 11.2.0.1.0 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.

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

 

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:

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

OR 

# <GI_HOME>/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 

$ <GI_HOME>/bin/crsctl start has  <========= for GI Standalone, this must be done as grid user.

About Me


...............................................................................................................................

● 本文来自于MOS转载文章(文档 ID 1193643.1)

● 小麦苗云盘地址:http://blog.itpub.net/26736162/viewspace-1624453/

● QQ群:230161599     微信群:私聊

● 联系我请加QQ好友(642808185),注明添加缘由

● 版权所有,欢迎分享本文,转载请保留出处

...............................................................................................................................

手机长按下图识别二维码或微信客户端扫描下边的二维码来关注小麦苗的微信公众号:xiaomaimiaolhr,免费学习最实用的数据库技术。

 

时间: 2024-10-26 07:23:04

【MOS】How to backup or restore OLR in 11.2/12c Grid Infrastructure的相关文章

【MOS】OCR/Vote disk 维护操作: (添加/删除/替换/移动) (文档 ID 1674859.1)

[MOS]OCR/Vote disk 维护操作: (添加/删除/替换/移动) (文档 ID 1674859.1) 文档内容 目标 解决方案   准备磁盘   1. 磁盘大小   2. 裸设备或者块设备 (pre 11.2)   3. ASM disks (11.2+)   4. 集群文件系统   5. 权限   6. 冗余   添加/删除/替换/移动 OCR device   1. 当只有一个 OCR 设备时,添加一个 OCRMIRROR 设备:   2. 删除一个 OCR 设备   3. 替换

【MOS】在不同版本和平台之间进行还原或复制 (文档 ID 1526162.1)--跨版本恢复

[MOS]关于在不同版本和平台之间进行还原或复制的常见问题 (文档 ID 1526162.1)--跨版本恢复 Questions and Answers    1) 我能用更高版本的 Oracle 还原或复制旧版本的数据库吗?    2) 我能在两个不同的补丁程序集之间进行还原或复制吗?    3) 我能在同一操作系统的不同版本之间进行还原或复制吗?    4) Oracle 的位(bit)级别(32 位或 64 位)不匹配时,可以进行还原或复制吗?    5) 可以将更高版本的备份还原到较早版

【MOS】Troubleshooting Performance Issues (文档 ID 1377446.1)

[MOS]Troubleshooting Performance Issues (文档 ID 1377446.1) In this Document Purpose   Best Practices   Pro-Active Problem Avoidance and Diagnostic Collection   Performance Service Request Diagnostic Collection (SRDC) documents Troubleshooting Steps  

【MOS】常见问题cursor library cache类型的等待事件

[MOS]常见问题:'cursor:mutex ..'/ 'cursor:pin ..'/ 'library cache:mutex ..'类型的等待事件 (文档 ID 1525791.1) 文档内容 用途 问题和答案   什么是 'cursor: ' 等待事件?   最常见的等待事件是什么?   等待事件最常见的原因是什么?   如何避免这些等待事件?   可以在什么位置找到原因诊断以及关于这些等待事件的更多信息?   有用参考 参考 适用于: Oracle Database - Enterp

【MOS】Limitations of the Oracle Cost Based Optimizer (文档 ID 212809.1)

[MOS]Limitations of the Oracle Cost Based Optimizer (文档 ID 212809.1) APPLIES TO: Oracle Database - Personal Edition - Version 7.1.4.0 and laterOracle Database - Enterprise Edition - Version 6.0.0.0 and laterOracle Database - Standard Edition - Versio

【MOS】RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1)

[MOS]RAC 环境中 gc block lost 和私网通信性能问题的诊断 (文档 ID 1674865.1) 文档内容 症状   概要:   场景:   原因:   Global Cache Block Loss诊断指南 更改 原因 解决方案 参考 适用于: Oracle Database - Enterprise Edition - 版本 9.2.0.1 和更高版本本文档所含信息适用于所有平台Oracle Clusterware & Oracle Real Application Clu

【MOS】零宕机迁移ASM磁盘组到另一个SAN/磁盘阵列/DAS的准确步骤 (文档 ID 1946664.1)

[MOS]零宕机时间迁移 ASM 磁盘组到另一个 SAN/磁盘阵列/DAS 的准确步骤 (文档 ID 1946664.1) 文档内容 目标   提问,获得帮助,并分享您对于这篇文档的经验. 解决方案 参考 适用于: Oracle Database - Enterprise Edition - 版本 10.2.0.1 到 11.2.0.4 [发行版 10.2 到 11.2]本文档所含信息适用于所有平台 目标 本文详述了在零宕机时间的前提下将 ASM 磁盘组从一个存储设备(SAN/磁盘阵列/DAS等

【MOS】Why an Object Not Be Exported? ORA-39166 or ORA-31655 (文档 ID 2114233.1)

[MOS]Why Can an Object Not Be Exported? Expdp of SYSTEM User's Table Returns ORA-39166 or ORA-31655 (文档 ID 2114233.1) In this Document Goal Solution References APPLIES TO: Oracle Database - Enterprise Edition - Version 12.1.0.2 and laterOracle Databa

【MOS】EVENT: DROP_SEGMENTS - cleanup of TEMPORARY segments (文档 ID 47400.1)

[MOS]EVENT: DROP_SEGMENTS - Forcing cleanup of TEMPORARY segments (文档 ID 47400.1) ***Checked for relevance on 14-Jun-2012*** The DROP_SEGMENTS event ~~~~~~~~~~~~~~~~~~~~~~~ Available from 8.0 onwards. DESCRIPTION Finds all the temporary segments in a