Oracle集群技术 | OLR与套接字文件(二)

本文涉及的产品
自定义KV模板,自定义KV模板 500次/账号
企业资质识别,企业资质识别 200次/月
车辆物流识别,车辆物流识别 200次/月
简介: 上篇《Oracle集群技术 | 集群的自启动系列(一)》中我们说到系统启动后由init.ohasd和ohasd两个脚本相互配合共同来完成集群的启动,当init.ohash前期工作准备完成,ohasd启动集群时需要首先读取olr文件,根据olr文件中记录的信息启动集群的初始化资源层,并在该过程中创建集群启动及运行时所需的套接字文件。

上篇《Oracle集群技术 | 集群的自启动系列(一)》中我们说到系统启动后由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/<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。

注:如果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@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 ~]#


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


| 作者简介

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

目录
相关文章
|
6月前
|
存储 Oracle NoSQL
Oracle 表空间、数据文件、schema的关系
Oracle 表空间、数据文件、schema的关系
185 2
|
6月前
|
XML Java 数据库连接
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——hibernate的config文件(hibernate.cfg.xml)
struts+hibernate+oracle+easyui实现lazyout组件的简单案例——hibernate的config文件(hibernate.cfg.xml)
|
2月前
|
Oracle 关系型数据库 数据库
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
打开oracle数据库报错“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。 数据库没有备份,无法通过备份去恢复数据库。用户方联系北亚企安数据恢复中心并提供Oracle_Home目录中的所有文件,急需恢复zxfg用户下的数据。 出现“system01.dbf需要更多的恢复来保持一致性”这个报错的原因可能是控制文件损坏、数据文件损坏,数据文件与控制文件的SCN不一致等。数据库恢复工程师对数据库文件进一步检测、分析后,发现sysaux01.dbf文件损坏,有坏块。 修复并启动数据库后仍然有许多查询报错,export和data pump工具使用报错。从数据库层面无法修复数据库。
数据库数据恢复—Oracle数据库文件出现坏块的数据恢复案例
|
6月前
|
运维 Oracle 容灾
Oracle dataguard 容灾技术实战(笔记),教你一种更清晰的Linux运维架构
Oracle dataguard 容灾技术实战(笔记),教你一种更清晰的Linux运维架构
|
28天前
|
Oracle 关系型数据库 数据库
oracle数据恢复—Oracle数据库文件损坏导致数据库打不开的数据恢复案例
打开oracle数据库时报错,报错信息:“system01.dbf需要更多的恢复来保持一致性,数据库无法打开”。急需恢复zxfg用户下的数据。 出现上述报错的原因有:控制文件损坏、数据文件损坏、数据文件与控制文件的SCN不一致等。数据恢复工程师对数据库文件做进一步检测分析后发现sysaux01.dbf文件有坏块。修复sysaux01.dbf文件,启动数据库依然有许多查询报错。export和data pump工具无法使用,查询告警日志并分析报错,确认发生上述错误的原因就是sysaux01.dbf文件损坏。由于该文件损坏,从数据库层面无法修复数据库。由于system和用户表空间的数据文件是正常的,
|
3月前
|
运维 Oracle 前端开发
Oracle 11g RAC集群日常运维命令总结
Oracle 11g RAC集群日常运维命令总结
81 2
|
3月前
|
SQL 存储 Oracle
"挑战极限!Oracle数据库精英试炼场:夺命连环5问,你能否一路披荆斩棘,登顶技术巅峰?"
【8月更文挑战第9天】Oracle,数据库领域的巨擘,以卓越的数据处理能力、稳定性和安全性成为企业级应用首选。今天我们带来“Oracle夺命连环25问”。首问:核心组件有哪些?答:实例(含内存结构和后台进程)、物理存储(数据文件、控制文件等)及逻辑存储(表空间、段等)。第二问:如何理解事务隔离级别?答:Oracle支持四种级别,默认READ COMMITTED,避免脏读,但可能遇到不可重复读和幻读。
45 0
|
6月前
|
SQL Oracle 关系型数据库
JAVAEE框架数据库技术之12_oracle常用函数和高级查询子查询
JAVAEE框架数据库技术之12_oracle常用函数和高级查询子查询
112 0
JAVAEE框架数据库技术之12_oracle常用函数和高级查询子查询
|
6月前
|
存储 Java 数据库
JAVAEE框架数据库技术之13_oracle 之PLSQL技术及存储过程和函数(二)
JAVAEE框架数据库技术之13_oracle 之PLSQL技术及存储过程和函数
75 0