Oracle 集群的自启动，OLR与套接字文件

Hehuyi_In

已于 2023-01-20 22:23:40 修改

阅读量2.6k

点赞数

分类专栏： Oracle RAC 文章标签： oracle 数据库 java

于 2020-10-24 20:28:17 首次发布

原文链接：http://blog.itpub.net/28218939/viewspace-2565014/

版权

Oracle 同时被 2 个专栏收录

189 篇文章 33 订阅

订阅专栏

RAC

6 篇文章 0 订阅

订阅专栏

当Oracle集群安装部署完成后，默认会处于启动的状态，当服务器重启之后集群也会被自动启动，那么，Oracle集群是如何来实现自启动的呢？

一、集群的自启动

1. 自启动脚本

Oracle 10G:

cat /etc/inittab
h1:35:respawn:/etc/init.d/init.evmd run >/dev/null 2>&1 </dev/null
h2:35:respawn:/etc/init.d/init.cssd fatal >/dev/null 2>&1 </dev/null
h3:35:respawn:/etc/init.d/init.crsd run >/dev/null 2>&1 </dev/null

Oracle 11G:

cat /etc/inittab
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

10g版本中，系统启动时由init进程根据/etc/inittab配置文件来派生出集群的高可用守护进程。11g中，init仅派生出init.ohasd，然后由init.ohasd启动ohasd.bin实现集群的自启动。

另外，由于RedHat 6.x弃用了inittab文件，目前配置init.ohasd进程的文件由/etc/inittab变为/etc/init/oracle-ohasd.conf。

 cat /etc/rc.d/init.d/oracle-ohasd.conf 
 # Copyright (c) 2001, 2011, Oracle and/or its affiliates. All rights reserved. 
 #
 # Oracle OHASD startup
 start on runlevel [35]
 stop  on runlevel [!35]
 respawn
 exec /etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null

在RedHat 7.*以上版本中，init.ohasd变为以service形式配置在/etc/systemd/system下。

cat /etc/systemd/system/oracle-ohasd.service
# Copyright (c) 2016, Oracle and/or its affiliates. All rights reserved.
#
# Oracle OHASD startup
[Unit]
Description=Oracle High Availability Services
After=syslog.target network-online.target remote-fs.target
[Service]
ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
ExecStop=/etc/init.d/init.ohasd stop >/dev/null 2>&1 </dev/null
TimeoutStopSec=60min
Type=simple
Restart=always
# Do not kill any processes except init.ohasd after ExecStop, unless the
# stop command times out.
KillMode=process
SendSIGKILL=yes
[Install]
WantedBy=multi-user.target graphical.target

实际上，Oracle集群自启动是由init.ohasd和ohasd两个脚本相互配合来完成的，这两个脚本均位于/etc/rc.d/init.d目录下。

[root@rac1 init.d]# pwd
/etc/rc.d/init.d

[root@rac1 init.d]# ls -ltr *ohasd*
-rwxr-xr-x. 1 root root 6835 Aug 29 09:57 ohasd
-rwxr-xr-x. 1 root root 9076 Aug 29 10:40 init.ohasd

2. init.ohasd

主要有两个作用：

创建名为npohasd的命名管道文件，并在init.ohasd运行过程中始终read该命名管道文件，以此作为标记，该作用为init.ohasd最重要的作用。当命名管道文件未被read标记时，集群无法启动
init.ohasd作为ohasd.bin的高可用守护进程而存在，当ohasd.bin进程异常终止时，由init.ohasd再次启动ohasd.bin，来实现ohasd.bin进程的高可用。ohasd.bin进程是集群的高可用进程，当集群资源意外终止时由ohasd.bin所属的agent进程负责重新启动相应资源，同时ohasd.bin也是负责整个集群启动的进程。(集群并非由init.ohasd脚本启动，init.ohasd做集群启动时的前期准备工作)

3. ohasd

ohasd脚本是在系统启动时真正启动集群的脚本，集群安装完毕后，ohasd脚本被软连接到/etc/rc.d下面的相关启动级别目录中(/etc/rc.d/rc[0-6].d/*)。系统启动时，执行不同级别的脚本程序，启动级别为3时，/etc/rc.d/rc3.d/S96ohasd被执行，此时ohasd脚本调用$ORACLE_HOME/bin/crsctl脚本来启动集群。

ohasd脚本在执行时会判断/var/tmp/.oracle目录是否存在，如果不存在将会创建，并将目录权限置为01777 ，/var/tmp/.oracle目录中存放着集群启动及正常运行时所产生的套接字以及命名管道文件。

如下为/etc/rc.d/rc[0-6]/*中ohasd脚本的软连接情况：

ls -ltr /etc/rc.d/rc[0-6].d/*ohasd*
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc5.d/S96ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc6.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc4.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc2.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc1.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Feb 21  2018 /etc/rc.d/rc0.d/K15ohasd -> /etc/init.d/ohasd
lrwxrwxrwx. 1 root root 17 Mar 26 01:40 /etc/rc.d/rc3.d/S96ohasd -> /etc/init.d/ohasd

4. init.ohasd/ohasd何时被调用

1）开机BIOS自检，根据BIOS中配置的启动设备读取MBR并加载Bootloader程序。
2）加载并执行引导程序GRUB。
3）GRUB根据配置加载内核映像。
4）内核启动（根文件系统挂载,内核执行/sbin/init）
5）init依据/etc/inittab中配置运行级别进行系统的初始化（/etc/rc.d/rc.sysinit），/etc/init/*内配置文件生效是在该步进行
6）根据不同的运行级别，启动相应服务 (服务程序脚本位于/etc/rc.d/rc[0-6].d中)。

其中，init.ohasd和ohash是在第5步和第6步来被调用启动集群。

当系统启动到第5步的时候，init进程会扫描/etc/init/下所有配置文件，根据/etc/init/oracle-ohasd.conf中的内容派生init.ohasd进程（由init.ohasd发出read命名管道文件npohasd的命令）。

系统启动到第6步时，根据系统的不同启动级别，/etc/rc.d/rc[0-6].d/*中的脚本程序被执行，此时ohasd调用$ORACLE_HOME/bin/crsctl脚本，由crsctl负责集群的启动。

5. init.ohasd/ohasd丢失怎么办

这两个脚本是在集群安装时执行root.sh过程中，从$GRID_HOME/crs/init/目录中复制而来的。如果丢失，可以从$GRID_HOME/crs/init目录中重新复制，并将/etc/init.d中的init.ohasd/ohasd权限置为755即可。

二、禁用集群自启动

1. ohasdstr

在/etc/oracle/scls_scr/[SID]/root/目录中有一个配置文件ohasdstr，当ohasd脚本被调用时会读取ohasdstr文件，根据ohasdstr文件中记录的enable/disable来判断集群是否自启动。

正确启/禁用集群自启动的做法是：

crsctl disable/enable crs

该命令实际上就是修改配置文件ohasdstr

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
enable

crsctl disable crs
CRS-4621: Oracle High Availability Services autostart is disabled.

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
disable

crsctl enable crs
CRS-4622: Oracle High Availability Services autostart is enabled.

cat /etc/oracle/scls_scr/qdata1/root/ohasdstr 
enable

当然，也可以直接手工修改ohasdstr文件。

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

三、 OLR文件

1. OLR文件作用及位置

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

cat /etc/oracle/olr.loc
#输出
olrconfig_loc=/u01/app/11.2.0/grid/cdata/node1.olr  #olr文件的位置
crs_home=/u01/app/11.2.0/grid

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

每个节点都有自己的olr文件，默认位置在$GRID_HOME/cdata/<hostname>.olr，olr配置文件的位置也可以使用ocrcheck命令获取，ocrcheck命令同时会验证ocr/olr的逻辑完整性。

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


ocrcheck -local -config
#输出
Oracle Local Registry configuration is :
     Device/File Name         : /u01/app/11.2.0/grid/cdata/node1.olr

ocrcheck验证完整性是根据安装时生成的libocr11.so文件的内容来检查ocr/olr。如果ocrcheck检查完整性失败可以参考文档(ID 1617639.1)。

2. 转储OLR文件

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

[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

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

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}
...

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

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

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]

后台进程中，只有init.ohasd脚本运行在后台，初始化资源层中所有资源均未启动。

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

对于olr文件丢失，只需要通过备份的olr文件还原即可。

4. OLR文件的备份与恢复

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

手动备份OLR

ocrconfig -local -manualbackup

查看OLR文件的备份

ocrconfig -local -showbackup

恢复OLR文件

ocrconfig -local -restore <olr备份>

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

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

ocrconfig -local -restore /u01/app/11.2.0/grid/cdata/rac1/backup_20180221_045700.olr
PROTL-16: Internal Error

可以尝试创建虚拟OLR，设置正确的所有权和权限，然后重试还原命令：

cd <OLR location> 
touch <hostname> .olr 
chmod 600 <hostname> .olr 
chown <grid>：<oinstall> <hostname> .olr

5. 验证OLR文件的完整性

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

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.

6. OLR文件的自动备份

在12.2.0.1以上版本中，OLR文件的自动备份功能作为BUG的一部分提供（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，第一感觉是集群未启动，但实际情况是集群与数据库均运行正常。

crsctl stat res -t
#输出
CRS-4535: Cannot communicate with Cluster Ready Services
CRS-4000: Command Status failed, or completed with errors.

crsctl check crs
#输出
CRS-4639: Could not contact Oracle High Availability Services

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

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

Hehuyi_In

关注

0
点赞
踩
4

收藏

觉得还不错? 一键收藏
1
评论
Oracle 集群的自启动，OLR与套接字文件

当Oracle集群安装部署完成后，默认会处于启动的状态，当服务器重启之后集群也会被自动启动，那么，Oracle集群是如何来实现自启动的呢？一、集群的自启动1. 自启动脚本Oracle 10G:cat/etc/inittabh1:35:respawn:/etc/init.d/init.evmdrun>/dev/null2>&1</dev/nullh2:35:respawn:/etc/init.d/init.cssdfatal>/dev/n...
复制链接

扫一扫