适用于:
Oracle Database – Enterprise Edition – 版本 11.2.0.1 和更高版本
Oracle Database Cloud Schema Service – 版本 N/A 和更高版本
Oracle Database Exadata Cloud Machine – 版本 N/A 和更高版本
Oracle Cloud Infrastructure – Database Service – 版本 N/A 和更高版本
Oracle Database Cloud Exadata Service – 版本 N/A 和更高版本
本文档所含信息适用于所有平台
用途
本文档的目的是总结可能阻止 Grid Infrastructure (GI) 成功启动的 5 大问题。
适用范围
本文档仅适用于 11gR2 Grid Infrastructure。
要确定 GI 的状态，请运行以下命令：
1. $GRID_HOME/bin/crsctl check crs 2. $GRID_HOME/bin/crsctl stat res -t -init 3. $GRID_HOME/bin/crsctl stat res -t 4. ps -ef | egrep 'init|d.bin'
详细信息
问题 1：CRS-4639：无法连接 Oracle 高可用性服务，ohasd.bin 未运行或 ohasd.bin 虽在运行但无 init.ohasd 或其他进程
症状：
1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：
CRS-4639: Could not contact Oracle High Availability Services
2. 命令“ps -ef | grep init”不显示类似于如下所示的行：
root 4878 1 0 Sep12 ? 00:00:02 /bin/sh /etc/init.d/init.ohasd run
3. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：
root 21350 1 6 22:24 ? 00:00:01 /u01/app/11.2.0/grid/bin/ohasd.bin reboot 或者它只显示 "ohasd.bin reboot" 进程而没有其他进程
4. 日志 ohasd.log 中出现以下信息:
2013-11-04 09:09:15.541: [ default][2609911536] Created alert : (:OHAS00117:) : TIMED OUT WAITING FOR OHASD MONITOR
5. 日志 ohasOUT.log 中出现以下信息:
2013-11-04 08:59:14 Changing directory to /u01/app/11.2.0/grid/log/lc1n1/ohasd OHASD starting Timed out waiting for init.ohasd script to start; posting an alert
6. ohasd.bin 一直处于启动状态，ohasd.log 信息：
2014-08-31 15:00:25.132: [ CRSSEC][733177600]{0:0:2} Exception: PrimaryGroupEntry constructor failed to validate group name with error: 0 groupId: 0x7f8df8022450 acl_string: pgrp:spec:r-x
2014-08-31 15:00:25.132: [ CRSSEC][733177600]{0:0:2} Exception: ACL entry creation failed for: pgrp:spec:r-x
2014-08-31 15:00:25.132: [ INIT][733177600]{0:0:2} Dump State Starting ...
7. 只有ohasd.bin运行，但是ohasd.log没有任何信息。 OS 日志/var/log/messages显示
2015-07-12 racnode1 logger: autorun file for ohasd is missing
可能的原因：
1. 文件“/etc/inittab”并不包含行(对于OL5/RHEL5以及以下版本，内容也会因版本的不同而不同)
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2. 未达到运行级别 3，一些 rc3 脚本挂起
3. Init 进程 (pid 1) 并未衍生 /etc/inittab (h1) 中定义的进程，或 init.ohasd 之前的不当输入，如 xx:wait:<process> 阻碍了 init.ohasd 的启动
4. CRS 自动启动已禁用
5. Oracle 本地注册表 ($GRID_HOME/cdata/<node>.olr) 丢失或损坏(root用户执行命令检查 “ocrdump -local /tmp/olr.log”, 文件 /tmp/olr.log 应该包含所有GI进程有关信息,对比一个正常工作的集群环境)
6. root用户之前在”spec”组，但是现在”spec”组被删除，但是旧组仍然记录在OLR中，可以通过OLR dump验证。
7. 节点重启后当init.ohasd启动时 HOSTNAME 为空。
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
2. 未达到运行级别 3，一些 rc3 脚本挂起
3. Init 进程 (pid 1) 并未衍生 /etc/inittab (h1) 中定义的进程，或 init.ohasd 之前的不当输入，如 xx:wait:<process> 阻碍了 init.ohasd 的启动
4. CRS 自动启动已禁用
5. Oracle 本地注册表 ($GRID_HOME/cdata/<node>.olr) 丢失或损坏(root用户执行命令检查 “ocrdump -local /tmp/olr.log”, 文件 /tmp/olr.log 应该包含所有GI进程有关信息,对比一个正常工作的集群环境)
6. root用户之前在”spec”组，但是现在”spec”组被删除，但是旧组仍然记录在OLR中，可以通过OLR dump验证。
7. 节点重启后当init.ohasd启动时 HOSTNAME 为空。
解决方案：
1. 将以下行添加至 /etc/inittab （对于OL5/RHEL5以及以下版本）
h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 </dev/null
并以 root 用户身份运行“init q”。 对于Linux OL6/RHEL6, 请参考文档 note 1607600.1
2. 运行命令“ps -ef | grep rc”，并kill看起来受阻的所有 rc3 脚本。
3. 删除 init.ohasd 前的不当输入。如果“init q”未衍生“init.ohasd run”进程，请咨询 OS 供应商
4. 启用 CRS 自动启动：
# crsctl enable crs # crsctl start crs
5. 以 root 用户身份从备份中恢复 OLR（Oracle 本地注册表）：(参考Note 1193643.1)
# crsctl stop crs -f # touch $GRID_HOME/cdata/<node>.olr # chown root:oinstall $GRID_HOME/cdata/<node>.olr # ocrconfig -local -restore$GRID_HOME/cdata/<node>/backup_<date>_<num>.olr # crsctl start crs如果出于某种原因，OLR 备份不存在，要重建 OLR 就需要以 root 用户身份执行 deconfig 并重新运行 root.sh： # $GRID_HOME/crs/install/rootcrs.pl -deconfig -force # $GRID_HOME/root.sh
6. 需要重新初始化/创建OLR, 使用命令与前面创建OLR命令相同。
7. 重启init.ohasd进程或者在init.ohasd中添加”sleep 30″，这样允许在启动集群前输出hostname信息，参考Note 1427234.1.
8. 如果上面方法不能解决问题，请检查OS messages中有关ohasd.bin日志信息，按照OS message中提示信息，
设置LD_LIBRARY_PATH = <GRID_HOME>/lib，并且手动执行crswrapexece.pl命令。
问题 2：CRS-4530：联系集群同步服务守护进程时出现通信故障，ocssd.bin 未运行
症状：
1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：
CRS-4638: Oracle High Availability Services is online CRS-4535: Cannot communicate with Cluster Ready Services CRS-4530: Communications failure contacting Cluster Synchronization Services daemon CRS-4534: Cannot communicate with Event Manager
2. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：
oragrid 21543 1 1 22:24 ? 00:00:01 /u01/app/11.2.0/grid/bin/ocssd.bin
3. ocssd.bin 正在运行，但在 ocssd.log 中显示消息“CLSGPNP_CALL_AGAIN”后又中止运行
4. ocssd.log 显示如下内容：
2012-01-27 13:42:58.796: [ CSSD][19]clssnmvDHBValidateNCopy: node 1, racnode1, has a disk HB, but no network HB, DHB has rcfg 223132864, wrtcnt, 1112, LATS 783238209, lastSeqNo 1111, uniqueness 1327692232, timestamp 1327693378/787089065
5. 对于 3 个或更多节点的情况，2 个节点形成的集群一切正常，但是，当第 3 个节点加入时就出现故障，ocssd.log 显示如下内容：
2012-02-09 11:33:53.048: [ CSSD][1120926016](:CSSNM00008:)clssnmCheckDskInfo: Aborting local node to avoid splitbrain. Cohort of 2 nodes with leader 2, racnode2, is smaller than cohort of 2 nodes led by node 1, racnode1, based on map type 2 2012-02-09 11:33:53.048: [ CSSD][1120926016]################################### 2012-02-09 11:33:53.048: [ CSSD][1120926016]clssscExit: CSSD aborting from thread clssnmRcfgMgrThread
6. 10 分钟后 ocssd.bin 启动超时
2012-04-08 12:04:33.153: [ CSSD][1]clssscmain: Starting CSS daemon, version 11.2.0.3.0, in (clustered) mode with uniqueness value 1333911873
......
2012-04-08 12:14:31.994: [ CSSD][5]clssgmShutDown: Received abortive shutdown request from client.
2012-04-08 12:14:31.994: [ CSSD][5]###################################
2012-04-08 12:14:31.994: [ CSSD][5]clssscExit: CSSD aborting from thread GMClientListener
2012-04-08 12:14:31.994: [ CSSD][5]###################################
2012-04-08 12:14:31.994: [ CSSD][5](:CSSSC00012:)clssscExit: A fatal error occurred and the CSS daemon is terminating abnormally
7. alert<node>.log 显示:
2014-02-05 06:16:56.815
[cssd(3361)]CRS-1714:Unable to discover any voting files, retrying discovery in 15 seconds; Details at (:CSSNM00070:) in /u01/app/11.2.0/grid/log/bdprod2/cssd/ocssd.log
...
2014-02-05 06:27:01.707
[ohasd(2252)]CRS-2765:Resource 'ora.cssdmonitor' has failed on server 'bdprod2'.
2014-02-05 06:27:02.075
[ohasd(2252)]CRS-2771:Maximum restart attempts reached for resource 'ora.cssd'; will not restart.
>
可能的原因：
1. 表决磁盘丢失或无法访问
2. 多播未正常工作（对于版本11.2.0.2，这是正常的情况。对于 11.2.0.3 PSU5/PSU6/PSU7 和 12.1.0.1 版本，是由于Bug 16547309）
3. 私网未工作，ping 或 traceroute <private host> 显示无法访问目标。或虽然 ping/traceroute 正常工作，但是在私网中启用了防火墙
4. gpnpd 未出现，卡在 dispatch 线程中， Bug 10105195
5. 通过 asm_diskstring 发现的磁盘太多，或由于 Bug 13454354 导致扫描太慢（仅在 Solaris 11.2.0.3 上出现）
2. 多播未正常工作（对于版本11.2.0.2，这是正常的情况。对于 11.2.0.3 PSU5/PSU6/PSU7 和 12.1.0.1 版本，是由于Bug 16547309）
3. 私网未工作，ping 或 traceroute <private host> 显示无法访问目标。或虽然 ping/traceroute 正常工作，但是在私网中启用了防火墙
4. gpnpd 未出现，卡在 dispatch 线程中， Bug 10105195
5. 通过 asm_diskstring 发现的磁盘太多，或由于 Bug 13454354 导致扫描太慢（仅在 Solaris 11.2.0.3 上出现）
解决方案：
1. 通过检查存储存取性、磁盘权限等恢复表决磁盘存取。如果表决盘在 OS 级别无法访问，请敦促操作系统管理员恢复磁盘访问。
如果 OCR ASM 磁盘组中的 voting disk已经丢失，以独占模式启动 CRS，并重建表决磁盘：
如果 OCR ASM 磁盘组中的 voting disk已经丢失，以独占模式启动 CRS，并重建表决磁盘：
# crsctl start crs -excl # crsctl replace votedisk <+OCRVOTE diskgroup>
2. 请参考 Document 1212703.1 ，了解多播功能的测试及修正。对于版本 11.2.0.3 PSU5/PSU6/PSU7 和12.1.0.1， 您可以为集群私网启用多播或者应用补丁16547309 或最新的PSU。更多信息请参考Document 1564555.1
3. 咨询网络管理员，恢复私网访问或禁用私网防火墙（对于 Linux，请检查服务 iptables 状态和服务 ip6tables 状态）
4. 终止正常运行节点上的 gpnpd.bin 进程，请参考 Document 10105195.8
一旦以上问题得以解决，请重新启动 Grid Infrastructure。
如果 ping/traceroute 对私网均可用，但是问题发生在从 11.2.0.1 至 11.2.0.2 升级过程中，请检查Bug 13416559 获取解决方法。
5. 通过提供更加具体的 asm_diskstring，限制 ASM 扫描磁盘的数量，请参考 bug 13583387
对于 Solaris 11.2.0.3，请应用补丁 13250497，请参阅 Document 1451367.1.
问题 3：CRS-4535：无法与集群就绪服务通信，crsd.bin 未运行
症状：
1. 命令“$GRID_HOME/bin/crsctl check crs”返回错误：
CRS-4638: Oracle High Availability Services is online CRS-4535: Cannot communicate with Cluster Ready Services CRS-4529: Cluster Synchronization Services is online CRS-4534: Cannot communicate with Event Manager
2. 命令“ps -ef | grep d.bin”不显示类似于如下所示的行：
root 23017 1 1 22:34 ? 00:00:00 /u01/app/11.2.0/grid/bin/crsd.bin reboot
3. 即使存在 crsd.bin 进程，命令“crsctl stat res -t –init”仍然显示：
ora.crsd 1 ONLINE INTERMEDIATE
可能的原因：
1. ocssd.bin 未运行，或资源 ora.cssd 不在线
2. +ASM<n> 实例无法启动
3. OCR 无法访问
4. 网络配置已改变，导致 gpnp profile.xml 不匹配
5. Crsd 的 $GRID_HOME/crs/init/<host>.pid 文件已被手动删除或重命名，crsd.log 显示：“Error3 -2 writing PID to the file”
6. ocr.loc 内容与其他集群节点不匹配。crsd.log 显示：“Shutdown CacheLocal. my hash ids don’t match”
7.当巨帧（Jumbo Frame）在集群私网被启用时，节点私网能够通过“ping”命令互相联通，但是无法通过巨帧尺寸ping通（例如：ping -s 8900 <私网 ip>）或者
集群中的其他节点已经配置巨帧(MTU: 9000)，而出现问题的节点没有配置巨帧(MTU:1500)。
8.对于平台 AIX 6.1 TL08 SP01 和 AIX 7.1 TL02 SP01，由于多播数据包被截断。
2. +ASM<n> 实例无法启动
3. OCR 无法访问
4. 网络配置已改变，导致 gpnp profile.xml 不匹配
5. Crsd 的 $GRID_HOME/crs/init/<host>.pid 文件已被手动删除或重命名，crsd.log 显示：“Error3 -2 writing PID to the file”
6. ocr.loc 内容与其他集群节点不匹配。crsd.log 显示：“Shutdown CacheLocal. my hash ids don’t match”
7.当巨帧（Jumbo Frame）在集群私网被启用时，节点私网能够通过“ping”命令互相联通，但是无法通过巨帧尺寸ping通（例如：ping -s 8900 <私网 ip>）或者
集群中的其他节点已经配置巨帧(MTU: 9000)，而出现问题的节点没有配置巨帧(MTU:1500)。
8.对于平台 AIX 6.1 TL08 SP01 和 AIX 7.1 TL02 SP01，由于多播数据包被截断。
解决方案：
1. 检查问题 2 的解决方案，确保 ocssd.bin 运行且 ora.cssd 在线
2. 对于 11.2.0.2 以上版本，确保资源 ora.cluster_interconnect.haip 在线，请参考 Document 1383737.1 了解和HAIP相关的，ASM无法启动的问题。
3. 确保 OCR 磁盘可用且可以访问。如果由于某种原因丢失 OCR，请参考 Document 1062983.1 了解如何恢复OCR。
4. 恢复网络配置，与 $GRID_HOME/gpnp/<node>/profiles/peer/profile.xml 中定义的接口相同，请参考Document 283684.1 了解如何修改私网配置。
5. 请使用 touch 命令，在 $GRID_HOME/crs/init 目录下创建名为 <host>.pid 的文件。
对于 11.2.0.1，该文件归 <grid> 用户所有。
对于 11.2.0.2，该文件归 root 用户所有。
6. 使用 ocrconfig 命令修正 ocr.loc 内容：
例如，作为 root 用户：
# ocrconfig -repair -add +OCR2 （添加条目） # ocrconfig -repair -delete +OCR2 （删除条目）
以上命令需要 ohasd.bin 启动并运行 。一旦以上问题得以解决，请通过以下命令重新启动 GI 或启动 crsd.bin：
# crsctl start res ora.crsd -init
7. 如果巨帧只是在网卡层面配置了巨帧，请敦促网络管理员在交换机层面启动巨帧。如果您不需要使用巨帧，请将集群中所有节点的私网MTU值设置为1500，之后重启所有节点。
8. 对于平台 AIX 6.1 TL08 SP01 和 AIX 7.1 TL02 SP01，根据下面的note应用对应的 AIX 补丁
Document 1528452.1 AIX 6.1 TL8 or 7.1 TL2: 11gR2 GI Second Node Fails to Join the Cluster as CRSD and EVMD are in INTERMEDIATE State
Document 1528452.1 AIX 6.1 TL8 or 7.1 TL2: 11gR2 GI Second Node Fails to Join the Cluster as CRSD and EVMD are in INTERMEDIATE State
问题 4：Agent 或者 mdnsd.bin, gpnpd.bin, gipcd.bin 未运行
症状：
1. orarootagent 未运行. ohasd.log 显示:
2012-12-21 02:14:05.071: [ AGFW][24] {0:0:2} Created alert : (:CRSAGF00123:) : Failed to start the agent process: /grid/11.2.0/grid_2/bin/orarootagent Category: -1 Operation: fail Loc: canexec2 OS error: 0 Other : no exe permission, file [/grid/11.2.0/grid_2/bin/orarootagent]
2. mdnsd.bin, gpnpd.bin 或者 gipcd.bin 未运行, 以下是 mdnsd log中显示的一个例子:
2012-12-31 21:37:27.601: [ clsdmt][1088776512]Creating PID [4526] file for home /u01/app/11.2.0/grid host lc1n1 bin mdns to /u01/app/11.2.0/grid/mdns/init/
2012-12-31 21:37:27.602: [ clsdmt][1088776512]Error3 -2 writing PID [4526] to the file []
2012-12-31 21:37:27.602: [ clsdmt][1088776512]Failed to record pid for MDNSD
或者
2012-12-31 21:39:52.656: [ clsdmt][1099217216]Creating PID [4645] file for home /u01/app/11.2.0/grid host lc1n1 bin mdns to /u01/app/11.2.0/grid/mdns/init/ 2012-12-31 21:39:52.656: [ clsdmt][1099217216]Writing PID [4645] to the file [/u01/app/11.2.0/grid/mdns/init/lc1n1.pid] 2012-12-31 21:39:52.656: [ clsdmt][1099217216]Failed to record pid for MDNSD
3. oraagent 或 appagent 未运行, 日志crsd.log显示:
2012-12-01 00:06:24.462: [ AGFW][1164069184] {0:2:27} Created alert : (:CRSAGF00130:) : Failed to start the agent /u01/app/grid/11.2.0/bin/appagent_oracle
可能的原因：
1. orarootagent 缺少执行权限
2. 缺少进程相关的 <node>.pid 文件或者这个文件的所有者/权限不对
3. GRID_HOME 所有者/权限不对
2. 缺少进程相关的 <node>.pid 文件或者这个文件的所有者/权限不对
3. GRID_HOME 所有者/权限不对
解决方案：
1. 和一个好的GRID_HOME比较所有者/权限，并做相应的改正，或者以root用户执行:
# cd <GRID_HOME>/crs/install # ./rootcrs.pl -unlock # ./rootcrs.pl -patch 这将停止集群软件，对需要的文件的所有者/权限设置为root用户，并且重启集群软件。
2. 如果对应的 <node>.pid 不存在, 就用touch命令创建一个具有相应所有者/权限的文件, 否则就按要求改正文件<node>.pid的所有者/权限, 然后重启集群软件.
这里是<GRID_HOME>下，所有者属于root:root 权限 644的<node>.pid 文件列表：
这里是<GRID_HOME>下，所有者属于root:root 权限 644的<node>.pid 文件列表：
./ologgerd/init/<node>.pid
./osysmond/init/<node>.pid
./ctss/init/<node>.pid
./ohasd/init/<node>.pid
./crs/init/<node>.pid
所有者属于<grid>:oinstall，权限644
./mdns/init/<node>.pid
./evm/init/<node>.pid
./gipc/init/<node>.pid
./gpnp/init/<node>.pid3.
对第3种原因，请参考解决方案1
问题 5：ASM 实例未启动，ora.asm 不在线
症状：
1. 命令“ps -ef | grep asm”不显示 ASM 进程
2. 命令“crsctl stat res -t –init”显示：
ora.asm 1 ONLINE OFFLINE
可能的原因：
1. ASM spfile 损坏
2. ASM discovery string不正确，因此无法发现 voting disk/OCR
3. ASMlib 配置问题
4. ASM实例使用不同的cluster_interconnect, 第一个节点 HAIP OFFLINE 导致第二个节点ASM实例无法启动
2. ASM discovery string不正确，因此无法发现 voting disk/OCR
3. ASMlib 配置问题
4. ASM实例使用不同的cluster_interconnect, 第一个节点 HAIP OFFLINE 导致第二个节点ASM实例无法启动
解决方案：
1. 创建临时 pfile 以启动 ASM 实例，然后重建 spfile，请参考 Document 1095214.1 了解更多详细信息。
2. 请参考 Document 1077094.1 以更正 ASM discovery string。
3. 请参考 Document 1050164.1 以修正 ASMlib 配置。
4. 请参考 Document 1383737.1 作为解决方案。请参考 Document 1210883.1 了解更多HAIP信息
2. 请参考 Document 1077094.1 以更正 ASM discovery string。
3. 请参考 Document 1050164.1 以修正 ASMlib 配置。
4. 请参考 Document 1383737.1 作为解决方案。请参考 Document 1210883.1 了解更多HAIP信息
要进一步调试 GI 启动问题，请参考 Document 1050908.1 Troubleshoot Grid Infrastructure Startup Issues.
Comment