您好,登录后才能下订单哦!
这篇文章主要介绍“Oracle集群中OLR与套接字文件分析”,在日常操作中,相信很多人在Oracle集群中OLR与套接字文件分析问题上存在疑惑,小编查阅了各式资料,整理出简单好用的操作方法,希望对大家解答”Oracle集群中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/<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与套接字文件分析”的学习就结束了,希望能够解决大家的疑惑。理论与实践的搭配能更好的帮助大家学习,快去试试吧!若想继续学习更多相关知识,请继续关注亿速云网站,小编会继续努力为大家带来更多实用的文章!
免责声明:本站发布的内容(图片、视频和文字)以原创、转载和分享为主,文章观点不代表本网站立场,如果涉及侵权请联系站长邮箱:is@yisu.com进行举报,并提供相关证据,一经查实,将立刻删除涉嫌侵权内容。