Oracle集群中OLR与套接字文件分析

59次阅读

共计 9449 个字符，预计需要花费 24 分钟才能阅读完成。

这篇文章主要介绍“Oracle 集群中 OLR 与套接字文件分析”，在日常操作中，相信很多人在 Oracle 集群中 OLR 与套接字文件分析问题上存在疑惑，丸趣 TV 小编查阅了各式资料，整理出简单好用的操作方法，希望对大家解答”Oracle 集群中 OLR 与套接字文件分析”的疑惑有所帮助！接下来，请跟着丸趣 TV 小编一起来学习吧！

| 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/ hostname .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。

| 转储 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@node1 ~]# ps -ef | grep -E  ohasd|agent|gpnp|gipc|mdns  | grep -v grep
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  olr 备份

恢复时确保 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  OLR location  
#touch  hostname  .olr 
#chmod 600  hostname  .olr 
#chown  grid：oinstall   hostname  .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@node1 ~]# ps -ef | grep -E  ohasd|agent|mdns|gpnp|gipc|pmon  | grep -v grep
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 集群中 OLR 与套接字文件分析”的学习就结束了，希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习，快去试试吧！若想继续学习更多相关知识，请继续关注丸趣 TV 网站，丸趣 TV 小编会继续努力为大家带来更多实用的文章！

正文完