oracle集群olr,Oracle集群技术 | OLR与套接字文件（二）

最新推荐文章于 2024-06-04 11:39:17 发布

weixin_39740346

最新推荐文章于 2024-06-04 11:39:17 发布

阅读量224

点赞数

文章标签： oracle集群olr

上篇

中我们说到系统启动后由init.ohasd和ohasd两个脚本相互配合共同来完成集群的启动，当init.ohash前期工作准备完成，ohasd启动集群时需要首先读取olr文件，根据olr文件中记录的信息启动集群的初始化资源层，并在该过程中创建集群启动及运行时所需的套接字文件。

OLR

OLR文件中记录的信息是ohasd守护进程启动集群初始化资源时所需要的资源定义信息，当集群启动时ohasd会从/etc/oracle/olr.loc文件中获取olr文件的位置。

[root@node1 ~]# ls -ltr /etc/oracle

total 2248

drwxr-xr-x. 3 root oinstall 4096 Nov 21 01:38 scls_scr

drwxrwxr-x. 5 root oinstall 4096 Nov 21 01:38 oprocd

-rws--x---. 1 root oinstall 2279833 Nov 21 01:38 setasmgid

-rw-r--r--. 1 root root 0 Nov 21 01:38 olr.loc.orig

-rw-r--r--. 1 root oinstall 81 Nov 21 01:38 olr.loc

-rw-r--r--. 1 root root 0 Nov 21 01:38 ocr.loc.orig

-rw-r--r--. 1 root oinstall 40 Nov 21 01:38 ocr.loc

drwxrwx---. 2 root oinstall 4096 Nov 21 01:44 lastgasp

[root@node1 ~]# cat /etc/oracle/olr.loc

olrconfig_loc=/u01/app/11.2.0/grid/cdata/node1.olr

crs_home=/u01/app/11.2.0/grid

[root@node1 ~]# ls -ltr /u01/app/11.2.0/grid/cdata/node1.olr

-rw-------. 1 root oinstall 272756736 Jan 8 21:40 /u01/app/11.2.0/grid/cdata/node1.olr

[root@node1 ~]#

对于olr文件，每个节点都有自己的olr文件，默认位置在$GRID_HOME/cdata/.olr，上面我们也提到olr配置文件的路径记录在/etc/oracle/olr.loc文件中，获取olr配置文件的位置也可以使用ocrcheck命令，ocrcheck命令同时也会验证ocr/olr的逻辑完整性:

[root@node1 ~]# ocrcheck -local

Status of Oracle Local Registry is as follows :

Version : 3

Total space (kbytes) : 262120

Used space (kbytes) : 2676

Available space (kbytes) : 259444

ID : 810831447

Device/File Name : /u01/app/11.2.0/grid/cdata/node1.olr

Device/File integrity check succeeded

Local registry integrity check succeeded

Logical corruption check succeeded

[root@node1 ~]# ocrcheck -local -config

Oracle Local Registry configuration is :

Device/File Name : /u01/app/11.2.0/grid/cdata/node1.olr

[root@node1 ~]#

ocrcheck验证完整性是根据安装时生成libocr11.so,根据libocr11.so内容来检查ocr/olr。

注:如果ocrcheck检查完整性失败可以参考文档(ID 1617639.1)。

转储OLR文件

olr文件为二进制方式保存，我们可以使用oracle提供的ocrdump工具对olr文件进行转储，生成文本模式的文件，方便我们了解olr文件内容。

[root@node1 ~]# ocrdump -local

[root@node1 ~]# ls -ltr

total 284

drwxr-xr-x. 2 root root 4096 Jan 10 2018 tmp

drwxr-xr-x. 2 root root 4096 Jan 10 2018 scripts

...

-rw-r--r--. 1 root root 10257 Nov 20 09:20 install.log.syslog

-rw-r--r--. 1 root root 52196 Nov 20 09:23 install.log

-rw-------. 1 root root 1717 Nov 20 09:23 anaconda-ks.cfg

-rw-------. 1 root root 179399 Jan 8 22:05 OCRDUMPFILE

[root@node1 ~]#

[grid@rac1 tmp]$ cat OCRDUMPFILE

05/31/2018 03:50:13

/u01/app/11.2.0/grid/bin/ocrdump.bin -local

[SYSTEM]

UNDEF :

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/11.2.0/grid

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##GI_HOME信息

[SYSTEM.WALLET]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_CREATE_SUB_KEY, OTHER_PERMISSION : PROCR_CREATE_SUB_KEY, USER_NAME : root, GROUP_NAME : root}

...

[SYSTEM.version.activeversion]

ORATEXT : 11.2.0.4.0

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##集群版本信息

[SYSTEM.GPnP]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

##集群初始化资源GPnP定义信息

[SYSTEM.GPnP.profiles]

BYTESTREAM (16) :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.GPnP.profiles.peer]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_NONE, OTHER_PERMISSION : PROCR_NONE, USER_NAME : grid, GROUP_NAME : oinstall}

…

[SYSTEM.network]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group.cluster_interconnect]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

[SYSTEM.network.haip.group.cluster_interconnect.interface]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : grid, GROUP_NAME : oinstall}

##集群初始化资源HAIP信息

[SYSTEM.OCR]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

##OCR信息

[SYSTEM.OCR.BACKUP]

UNDEF :

SECURITY : {USER_PERMISSION : PROCR_ALL_ACCESS, GROUP_PERMISSION : PROCR_READ, OTHER_PERMISSION : PROCR_READ, USER_NAME : root, GROUP_NAME : root}

...

OLR与OCR文件的数据存储都是采用树形结构，详细信息查看dump后的文件即可，这里不再解读。

OLR文件丢失导致的初始化资源层无法启动

olr文件丢失后，集群启动时alert[hostname].log日志中会有明显olr文件无法读取的错误信息，如下：

alertnode1.log:

2018-03-26 06:15:17.579:

[ohasd(5219)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

2018-03-26 06:15:17.733:

[ohasd(5230)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

2018-03-26 06:15:17.886:

[ohasd(5241)]CRS-0704:Oracle High Availability Service aborted due to Oracle Local Registry error [PROCL-33: Oracle Local Registry is not configured Storage layer error [Error opening olr.loc file. No such file or directory] [2]]. Details at (:OHAS00106:) in /u01/app/11.2.0/grid/log/node1/ohasd/ohasd.log.

[client(5256)]CRS-10001:CRS-10132: No msg for has:crs-10132 [10][60]

日志中直接报olr.loc文件无法打开。(opening olr.loc file. No such file or directory)

root 1332 1 0 20:53 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run

[root@node1 ~]#

后台进程中，只有init.ohasd脚本运行在后台，初始化资源层中所有资源均为启动，对于olr文件丢失，我只需要通过备份的olr文件还原即可。

OLR文件的备份与恢复

OLR文件会在GI软件安装之后，或者GI升级之后自动进行一次备份，OLR文件并不会像OCR一样自动进行备份，如果初始化资源层面的资源出现变动，建议手工备份OLR文件。

1.手动备份OLR

ocrconfig -local -manualbackup

2.查看OLR文件的备份

ocrconfig -local -showbackup

3.恢复OLR文件

ocrconfig -local -restore

恢复时确保ohasd.bin未启动，如果ohasd.bin仍在运行，请使用crsctlstop crs停止GI。

恢复OLR过程中如果出现PROTL-16:Internal Error错误，导致恢复失败，可能是由于olr.loc文件丢失导致，因为olr文件还原时会读取olr.loc文件，将olr文件恢复到olr.loc指定的位置。

[root@rac1 oracle]# ocrconfig -local -restore /u01/app/11.2.0/grid/cdata/rac1/backup_20180221_045700.olr

PROTL-16: Internal Error

[root@rac1 oracle]#

如果仍然失败，请尝试创建虚拟OLR，设置正确的所有权和权限，然后重试还原命令：

#cd

#touch .olr

#chmod 600 .olr

#chown ： .olr

4.验证OLR文件的完整性

对于OLR文件的完整性验证，也可以使用Oracle提供的CVU进行验证，但这里的验证并不检查OLR文件内容的逻辑完整性，如果需要同时验证逻辑完整性还需使用ocrcheck -local进行验证。

[grid@node1 ~]$ cluvfy comp olr

Verifying OLR integrity

Checking OLR integrity...

Checking OLR config file...

OLR config file check successful

Checking OLR file attributes...

OLR file check successful

WARNING:

This check does not verify the integrity of the OLR contents. Execute 'ocrcheck -local' as a privileged user to verify the contents of OLR.

OLR integrity check passed

Verification of OLR integrity was successful.

[grid@node1 ~]$

5.OLR文件的自动备份

在12.2.0.1以上版本中，Grid也开始支持OLR文件的自动备份，自动备份功能作为BUG的一部分而进行提供，BUG 24799186(现由BUG 26493466取代)，但在18.1以及GI RU 12.2.0.1.180116中以包含OLR自动备份功能。

| 套接字文件

套接字文件是进程与进程之间双向通信的端点，是进程间通信的一种约定，Oracle集群在启动时，首先读取OLR文件进行初始化资源层的启动，并逐步实现集群的启动，在此过程中会在/var/tmp/.oracle目录中创建相关集群进程需要的套接字文件。

套接字文件是集群运行过程中必不可少的文件，在集群运行过程中请不要删除相关套接字文件，如果套接字文件丢失会导致一些不可预知的问题。

如下测试是在集群运行过程，手工删除/var/tmp/.oracle中的所有文件后，通过crsctl检查集群状态，输出CRS-4535与CRS-4000以及CRS-4639，第一感觉是集群未启动，但实际情况是集群与数据库均运行正常。

[root@node1 ~]# crsctl stat res -t

CRS-4535: Cannot communicate with Cluster Ready Services

CRS-4000: Command Status failed, or completed with errors.

[root@node1 ~]# crsctl check crs

CRS-4639: Could not contact Oracle High Availability Services

root 1332 1 0 Jan20 ? 00:00:00 /bin/sh /etc/init.d/init.ohasd run

root 3829 1 0 Jan20 ? 00:01:19 /u01/app/11.2.0/grid/bin/ohasd.bin reboot

grid 3951 1 0 Jan20 ? 00:01:10 /u01/app/11.2.0/grid/bin/oraagent.bin

grid 3962 1 0 Jan20 ? 00:00:00 /u01/app/11.2.0/grid/bin/mdnsd.bin

grid 3973 1 0 Jan20 ? 00:00:11 /u01/app/11.2.0/grid/bin/gpnpd.bin

grid 3984 1 0 Jan20 ? 00:01:43 /u01/app/11.2.0/grid/bin/gipcd.bin

root 3986 1 0 Jan20 ? 00:02:18 /u01/app/11.2.0/grid/bin/orarootagent.bin

root 4030 1 0 Jan20 ? 00:00:16 /u01/app/11.2.0/grid/bin/cssdagent

grid 4390 1 0 Jan20 ? 00:00:05 asm_pmon_+ASM1

grid 4559 1 0 Jan20 ? 00:02:03 /u01/app/11.2.0/grid/bin/oraagent.bin

root 4567 1 0 Jan20 ? 00:02:17 /u01/app/11.2.0/grid/bin/orarootagent.bin

oracle 4769 1 0 Jan20 ? 00:01:44 /u01/app/11.2.0/grid/bin/oraagent.bin

oracle 4832 1 0 Jan20 ? 00:00:07 ora_pmon_oraapp1

[root@node1 ~]#

对于套接字文件丢失导致集群运行不正常以及其他问题，最简单的办法就是重新启动集群，集群在启动时会重新创建需要的套接字文件。

| 作者简介

杨禹航·沃趣科技高级数据库技术专家

熟悉Oracle数据库内部机制，丰富的数据库及RAC集群层故障诊断、性能调优、OWI、数据库备份恢复及迁移经验。

weixin_39740346

关注

0
点赞
踩
1

收藏

觉得还不错? 一键收藏
0
评论
oracle集群olr,Oracle集群技术 | OLR与套接字文件（二）

上篇中我们说到系统启动后由init.ohasd和ohasd两个脚本相互配合共同来完成集群的启动，当init.ohash前期工作准备完成，ohasd启动集群时需要首先读取olr文件，根据olr文件中记录的信息启动集群的初始化资源层，并在该过程中创建集群启动及运行时所需的套接字文件。|OLROLR文件中记录的信息是ohasd守护进程启动集群初始化资源时所需要的资源定义信息，当集群启动时ohasd会从/...
复制链接

扫一扫