n this Document

Applies to:

Oracle Database - Enterprise Edition - Version 11.2.0.1 and later

Information in this document applies to any platform.

Purpose

本文档的目的是总结可能阻止 Grid Infrastructure (GI) 成功启动的 5 大问题。

Scope

本文档仅适用于 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'

Details

问题 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" 进程而没有其他进程

可能的原因：

1. 文件“/etc/inittab”并不包含行

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1 2. 未达到运行级别 3，一些 rc3 脚本挂起

3. Init 进程 (pid 1) 并未衍生 /etc/inittab (h1) 中定义的进程，或 init.ohasd 之前的不当输入，如 xx:wait: 阻碍了 init.ohasd 的启动

4. CRS 自动启动已禁用

5. Oracle 本地注册表 ($GRID_HOME/cdata/.olr) 丢失或损坏

解决方案：

1. 将以下行添加至 /etc/inittab

h1:35:respawn:/etc/init.d/init.ohasd run >/dev/null 2>&1    并以 root 用户身份运行“init q”。

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 本地注册表)：

# touch $GRID_HOME/cdata/.olr

# chown root:oinstall $GRID_HOME/cdata/.olr

# ocrconfig -local -restore$GRID_HOME/cdata//backup__.olr

# crsctl start crs

如果出于某种原因，OLR 备份不存在，要重建 OLR 就需要以 root 用户身份执行 deconfig 并重新运行 root.sh：

# $GRID_HOME/crs/install/rootcrs.pl -deconfig -force

# $GRID_HOME/root.sh

问题 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

可能的原因：

1. 表决磁盘丢失或无法访问

2. 多播未正常工作(对于 11.2.0.2 及以上版本)

3. 私网未工作，ping 或 traceroute 显示无法访问目标。或虽然 ping/traceroute 正常工作，但是在私网中启用了防火墙

4. 使用正常 ping 命令可对私网进行 ping 操作，但启用巨帧时(MTU：9000+)，不能使用巨帧尺寸(如：ping -s 8900 )进行 ping 操作。或部分集群节点设置了巨帧(MTU：9000)，但问题节点未设置巨帧(MTU：1500)

5. gpnpd 未出现，卡在 dispatch 线程中，

6. 通过 asm_diskstring 发现的磁盘太多，或由于 Bug 13454354 导致扫描太慢(仅在 Solaris 11.2.0.3 上出现)

解决方案：

1. 通过检查存储存取性、磁盘权限等恢复表决磁盘存取。

如果 OCR ASM 磁盘组中的 voting disk已经丢失，以独占模式启动 CRS，并重建表决磁盘：

# crsctl start crs -excl

# crsctl replace votedisk

2. 请参考Document 1212703.1，了解多播功能的测试及修正

3. 咨询网络管理员，恢复私网访问或禁用私网防火墙(对于 Linux，请检查服务 iptables 状态和服务 ip6tables 状态)

4. 如果巨帧在网卡中启用，则联系网络管理员在交换机层也启用。

5. 终止正常运行节点上的 gpnpd.bin 进程，请参考Document 10105195.8

一旦以上问题得以解决，请重新启动 Grid Infrastructure。

如果 ping/traceroute 对私网均可用，但是问题发生在从 11.2.0.1 至 11.2.0.2 升级过程中，请检查

获取解决方法。

6. 通过提供更加具体的 asm_diskstring，限制 ASM 扫描磁盘的数量，请参考

对于 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 实例无法启动

3. OCR 无法访问

4. 网络配置已改变，导致 gpnp profile.xml 不匹配

5. Crsd 的 $GRID_HOME/crs/init/.pid 文件已被手动删除或重命名，crsd.log 显示：“Error3 -2 writing PID to the file”

6. ocr.loc 内容与其他集群节点不匹配。crsd.log 显示：“Shutdown CacheLocal. my hash ids don't match”

解决方案：

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//profiles/peer/profile.xml 中定义的接口相同，请参考

Document 283684.1了解如何修改私网配置。

5. 请使用 touch 命令，在 $GRID_HOME/crs/init 目录下创建名为 .pid 的文件。

对于 11.2.0.1，该文件归 用户所有。

对于 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

问题 4：Agent 或者 mdnsd.bin, gpnpd.bin, gipcd.bin 未运行

症状：

1. orarootagent 未运行. ohasd.log 显示:

2012-12-21 02:14:05.071: [    A**][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: [    A**][1164069184] {0:2:27} Created alert : (:CRSAGF00130:) :  Failed to start the agent /u01/app/grid/11.2.0/bin/appagent_oracle

可能的原因：

1. orarootagent 缺少执行权限

2. 缺少进程相关的 .pid 文件或者这个文件的所有者/权限不对

3. GRID_HOME 所有者/权限不对

解决方案：

1. 和一个好的GRID_HOME比较所有者/权限，并做相应的改正，或者以root用户执行:，

# cd /crs/install

# ./rootcrs.pl -unlock

# ./rootcrs.pl -patch

这将停止集群软件，对需要的文件的所有者/权限设置为root用户，并且重启集群软件。

2. 如果对应的 .pid 不存在, 就用touch命令创建一个具有相应所有者/权限的文件, 否则就按要求改正文件.pid的所有者/权限, 然后重启集群软件.

这里是下，所有者属于root:root 权限 644的.pid 文件列表：./ologgerd/init/.pid

./osysmond/init/.pid

./ctss/init/.pid

./ohasd/init/.pid

./crs/init/.pid

所有者属于:oinstall，权限644

./mdns/init/.pid

./evm/init/.pid

./gipc/init/.pid

./gpnp/init/.pid

3. 对第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实例无法启动

解决方案：

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信息

要进一步调试 GI 启动问题，请参考 Document 1050908.1Troubleshoot Grid Infrastructure Startup Issues.