诊断 Grid Infrastructure 启动问题 (文档 ID 1623340.1)

文档内容

适用于:

用途

本文提供了诊断 11GR2 和 12C Grid Infrastructure 启动问题的方法。对于新安装的环境（root.sh 和 rootupgrade.sh 执行过程中）和有故障的旧环境都适用。针对 root.sh 的问题，我们可以参考 note 1053970.1 来获取更多的信息。

适用范围

本文适用于集群/RAC数据库管理员和 Oracle 支持工程师。

详细信息

启动顺序：

简而言之，操作系统负责启动 ohasd 进程，ohasd 进程启动 agents 用来启动守护进程(gipcd, mdnsd, gpnpd, ctssd, ocssd, crsd, evmd ,asm …) ，crsd 启动 agents 用来启动用户资源(database,SCAN,Listener 等)。

如果需要了解更详细的 Grid Infrastructure Cluster 启动顺序，请参阅 note 1053147.1。

集群状态

查询集群和守护进程的状态:

如果守护进程 offline 我们可以通过以下命令启动:

问题 1: OHASD 无法启动

由于 ohasd.bin 的责任是直接或者间接的启动集群所有的其它进程，所以只有这个进程正常启动了，其它的进程才能起来，如果 ohasd.bin 的进程没有起来，当我们检查资源状态的时候会报错 CRS-4639 (Could not contact Oracle High Availability Services); 如果 ohasd.bin 已经启动了，而再次尝试启时，错误 CRS-4640 会出现；如果它启动失败了，那么我们会看到以下的错误信息：

自动启动 ohasd.bin 依赖于以下的配置：

1. 操作系统配置了正确的 run level:

OS 需要在 CRS 启动之前设置成指定的 run level 来确保 CRS 的正常启动。

我们可以通过以下方式找到 CRS 需要 OS 设置的 run level：

以上例子展示了，CRS 需要 OS 运行在 run level 3 或 5；请注意，由于操作系统的不同，CRS 启动需要的 OS 的 run level 也会不同。

找到当前 OS 正在运行的 run level:

2. "init.ohasd run" 启动

在 Linux/Unix 平台上，由于"init.ohasd run" 是配置在 /etc/inittab中，进程 init（进程id 1，linux，Solars和HP-UX上为/sbin/init ，Aix上为/usr/sbin/init）会启动并且产生"init.ohasd run"进程，如果这个过程失败了，就不会有"init.ohasd run"的启动和运行，ohasd.bin 也是无法启动的：

注意：Oracle Linux (OL6)以及 Red Hat Linux 6 (RHEL6) 已经不再支持 inittab 了，所以 init.ohasd 会被配置在 /etc/init 中，并被 /etc/init 启动，尽管如此，我们还是应该能看到进程 "/etc/init.d/init.ohasd run" 被启动；

如果任何 rc Snncommand 的脚本（在 rcn.d 中，如 S98gcstartup）在启动的过程中挂死，此时 init 的进程可能无法启动"/etc/init.d/init.ohasd run"；您需要寻求 OS 厂商的帮助，找到为什么 Snncommand 脚本挂死或者无法正常启动的原因；

错误"[ohasd(<pid>)] CRS-0715:Oracle High Availability Service has timed out waiting for init.ohasd to be started." 可能会在 init.ohasd 无法在指定时间内启动后出现
 
如果系统管理员无法在短期内找到 init.ohasd 无法启动的原因，以下办法可以作为一个临时的解决办法：

3. Clusterware 自动启动；--自动启动默认是开启的

默认情况下 CRS 自动启动是开启的，我们可以通过以下方式开启：

检查这个功能是否被开启:

如果以下信息被输出在OS的日志中

原因是由于这个文件不存在或者不可访问，产生这个问题的原因一般是人为的修改或者是打 GI 补丁的过程中使用了错误的 opatch (如：使用 Solaris 平台上的 opatch 在 Linux 上打补丁)


4. syslogd 启动并且 OS 能够执行 init 脚本 S96ohasd

节点启动之后，OS 可能停滞在一些其它的 Snn 的脚本上，所以可能没有机会执行到脚本 S96ohasd；如果是这种情况，我们不会在 OS 日志中看到以下信息

如果在 OS 日志里看不到上面的信息，还有一种可能是 syslogd（(/usr/sbin/syslogd）没有被完全启动。GRID 在这种情况下也是无法正常启动的，这种情况不适用于 AIX 的平台。

为了了解 OS 启动之后是否能够执行 S96ohasd 脚本，可以按照以下的方法修改该脚本：

From:

To:

重启节点后，如果您没有看到文件 /tmp/ohasd.start.timestamp 被创建，那么就是说 OS 停滞在其它的 Snn 的脚本上。如果您能看到 /tmp/ohasd.start.timestamp 生成了，但是"Oracle HA daemon is enabled for autostart"没有写入到messages 文件里，就是 syslogd 没有被完全启动了。以上的两种情况，您都需要寻求系统管理员的帮助，从 OS 的层面找到问题的原因，对于后一种情况，有个临时的解决办法是“休眠”2分钟， 按照以下的方法修改 ohasd 脚本：

From:

To:

5. GRID_HOME 所在的文件系统在执行初始化脚本 S96ohasd 的时候在线；正常情况下一旦 S96ohasd 执行结束，我们会在 OS message 里看到以下信息：

如果您只看到了第一行，没有看到最后一行的信息，很可能是 GRID_HOME 所在的文件系统在脚本 S96ohasd 执行的时候还没有正常挂载。


6. Oracle Local Registry  (OLR, $GRID_HOME/cdata/${HOSTNAME}.olr) 有效并可以正常读写

如果 OLR 是不可读写的或者损坏的，我们会在 ohasd.log 中看到以下的相关信息

或者

或者

或者

或者

解决办法就是使用下面的命令，恢复一个好的备份 "ocrconfig -local -restore <ocr_backup_name>"。

默认情况下，OLR 在系统安装结束后会自动的备份在 $GRID_HOME/cdata/$HOST/backup_$TIME_STAMP.olr 。

7. ohasd.bin可以正常的访问到网络的 socket 文件:

在 Grid Infrastructure 环境中，和 ohasd 有关的 socket 文件属主应该是 root 用户，但是在 Oracle Restart 的环境中，他们应该是属于 grid 用户的，关于更多的关于网络 socket 文件权限和属主，请参考章节"网络 socket 文件，属主和权限" 给出的例子.

8. ohasd.bin 能够访问日志文件的位置:

OS messages/syslog 显示以下信息:

请参考章节"日志位置, 属主和权限"部分的例子，并确定这些必要的目录是否有丢失的，并且是按照正确的权限和属主创建的。

9. 节点启动后，在 SUSE Linux 的系统上，ohasd 可能无法启动，此问题请参考 note 1325718.1 - OHASD not Starting After Reboot on SLES

10. OHASD 无法启动，使用 "ps -ef| grep ohasd.bin" 显示 ohasd.bin 的进程已经启动，但是 $GRID_HOME/log/<node>/ohasd/ohasd.log 在好几分钟之后都没有任何信息更新,使用 OS 的 truss 工具 可以看到该进程一致在循环的执行关闭从未被打开的文件句柄的操作:

通过 ohasd.bin 的 Call stack ，可以看到以下信息:

这是由于 bug 11834289 导致的， 该问题在 11.2.0.3 和之上的版本已经被修复,该 bug 的其它症状还有：集群的进程无法启动，而且做 call stack 和 truss 查看的时候也会看到相同的情况(循环的执行 OS 函数 "close") . 如果该 bug 发生在启动其它的资源时，我们会看到错误信息： "CRS-5802: Unable to start the agent process" 提示。

11. 其它的一些潜在的原因和解决办法请参见 note 1069182.1 - OHASD Failed to Start: Inappropriate ioctl for device

12. ohasd.bin 正常启动，但是, "crsctl check crs" 只显示以下一行信息:

并且命令 "crsctl stat res -p -init" 无法显示任何信息

这个问题是由于 OLR 损坏导致的，请参考 note 1193643.1 进行恢复。

13. 如果 ohasd 仍然无法启动，请参见 ohasd 的日志 <grid-home>/log/<nodename>/ohasd/ohasd.log 和 ohasdOUT.log 来获取更多的信息；
 

问题 2: OHASD Agents  未启动

OHASD.BIN 会启动 4 个 agents/monitors 来启动其它的资源:

  oraagent: 负责启动  ora.asm, ora.evmd, ora.gipcd, ora.gpnpd, ora.mdnsd 等
  orarootagent: 负责启动 ora.crsd, ora.ctssd, ora.diskmon, ora.drivers.acfs 等
  cssdagent / cssdmonitor: 负责启动 ora.cssd(对应 ocssd.bin) 和 ora.cssdmonitor(对应 cssdmonitor)

如果 ohasd.bin 不能正常地启动以上任何一个 agents，集群都无法运行在正常的状态。

1. 通常情况下，agents 无法启动的原因是 agent 的日志或者日志所在的目录没有正确设置属主和权限。

关于日志文件和文件夹的权限和属主设置，请参见章节 "日志文件位置, 属主和权限" 中的介绍。

2. 如果 agent 的二进制文件（oraagent.bin 或者 orarootagent.bin 等）损坏, agent 也将无法启动，从而导致相关的资源也无法启动：

解决办法： 您可以和正常节点上的 agent 文件进行比较，并且恢复一个好的副本回来。

问题 3: OCSSD.BIN 无法启动

cssd.bin 的正常启动依赖于以下几个必要的条件:

1. GPnP profile 可正常读写 - gpnpd  需要完全正常启动来为profile服务。

如果 ocssd.bin 能够正常的获取 profile，通常情况下，我们会在 ocssd.log 中看到以下类似的信息：

否则，我们会看到以下信息显示在 ocssd.log 中。

2. Voting Disk 可以正常读写

在 11gR2 的版本中， ocssd.bin 通过 GPnP profile 中的记录获取 Voting disk 的信息, 如果没有足够多的选举盘是可读写的，那么 ocssd.bin 会终止掉自己。

如果所有节点上的 ocssd.bin 因为以下错误无法启动，这是因为 voting file 正在被修改:

解决的办法是，参照 note 1364971.1 中的步骤，以 exclusive 模式启动 ocssd.bin。 


如果选举盘的位置是非 ASM 的设备，它的权限和属主应该是如下显示：

-rw-r----- 1 ogrid oinstall 21004288 Feb  4 09:13 votedisk1

3. 网络功能是正常的，并且域名解析能够正常工作:

如果 ocssd.bin 无法正常的绑定到任何网络上，我们会在 ocssd.log 中看到以下类似的日志信息：

如果私网上出现了联通性的故障（包含多播功能关闭），我们会在 ocssd.log 中看到以下类似的日志信息：

验证网络是否正常，请参见：note 1054902.1

如果第三方的集群管理软件没有完全正常启动，我们在 ocssd.log 中看到以下类似的日志信息：

未安装集群管理软件之前，请使用 grid 用户执行以下操作验证:

5. 在错误的 GRID_HOME 下执行命令"crsctl" 

命令"crsctl" 必须在正确的 GRID_HOME 下执行，才能正常启动其它进程,否则我们会看到以下的错误信息提示：

问题 4: CRSD.BIN 无法启动

crsd.bin 的正常启动依赖于以下几个必要的条件:

1. ocssd 已经完全正常启动

如果 ocssd.bin 没有完全正常启动，我们会在 crsd.log 中看到以下提示信息:

2. OCR 可以正常读写

如果 OCR 保存在 ASM 中,那么 ora.asm 资源(ASM 实例) 必须已经启动而且 OCR 所在的磁盘组必须已经被挂载,否则我们在 crsd.log 会看到以下的类似信息：

注意：在11.2 的版本中 ASM 会比 crsd.bin 先启动，并且会把含有 OCR 的磁盘组自动挂载。


如果您的 OCR 在非 ASM 的存储中，该文件的属主和权限如下：

-rw-r----- 1 root  oinstall  272756736 Feb  3 23:24 ocr


如果 OCR 是在非 ASM 的存储中，并且不能被正常访问，在 crsd.log 会看到以下的类似信息

如果 OCR 是坏掉了，在 crsd.log 会看到以下的类似信息:

如果您的 grid 用户的权限或者所在组发生了变化，尽管 ASM 还是可以访问的，在 crsd.log 会看到以下的类似信息:

如果 GRID_HOME 下的 oracle 二进制文件的属主或者权限错误，尽管 ASM 正常启动并运行，在 crsd.log 会看到以下的类似信息：

正常的 GRID_HOME 下该文件的属主和权限应该是如下显示：

如果 OCR 文件或者它的镜像文件无法正常访问 (可能是 ASM 已经启动, 但是 OCR/mirror 所在的磁盘组没有挂载),在 crsd.log 会看到以下的类似信息:

3. crsd.bin 的进程号文件（<GRID_HOME>/crs/init/<节点名>.pid）存在，但是却指向其它的进程

如果进程号文件不存在,在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我们会看到以下的提示信息:

解决办法，我们可以手工创建一个进程号文件：使用 grid 用户执行 "touch" 命令，然后重新启动 ora.crsd 资源。

如果进程号文件存在，但是记录的 PID 是指向了其它的进程，而不是 crsd.bin 的进程，在日志 $GRID_HOME/log/$HOST/agent/ohasd/orarootagent_root/orarootagent_root.log 我们会看到以下的提示信息:

在 OS 层面检查该问题:

解决办法是，使用 root 用户，创建一个空的进程号文件，然后重启资源 ora.crsd：

4. 网络功能是正常的，并且域名解析能够正常工作：

如果网络功能不正常，ocssd.bin 进程仍然可能被启动, 但是 crsd.bin 可能会失败，同时在 crsd.log 中会提示以下信息:

或者:

或者:

关于网络和域名解析的验证，请参考：note 1054902.1

5. crsd 可执行文件(crsd.bin 和 crsd in GRID_HOME/bin) 的权限或者属主正确并且没有进行过手工的修改, 一个简单可行的检查办法是对比好的节点和坏节点的以下命令输出 "ls -l <grid-home>/bin/crsd <grid-home>/bin/crsd.bin".


6. 关于CRSD进程启动问题的进一步深入诊断，请参考 note 1323698.1 - Troubleshooting CRSD Start up Issue
 

问题 5: GPNPD.BIN 无法启动

1. 网络的域名解析不正常

gpnpd.bin 进程启动失败，以下信息提示在 gpnpd.log 中:

以上的例子，请确定当前节点能够正常的 ping 到“node2” ，并且确认两个节点之间没有任何防火墙。

2. bug 10105195

由于 bug 10105195, gpnp 的调度线程（dispatch thread）可能被阻断，例如：网络扫描。这个 bug 在 11.2.0.2 GI PSU2，11.2.0.3 及以上版本被修复，具体信息，请参见 note 10105195.8。

问题 6: 其它的一些守护进程无法启动

常见原因:

1. 守护进程的日志文件或者日志所在的路径权限或者属主不正确。

如果日志文件或者日志文件所在的路径权限或者属主设置有问题，通常我们会看到进程尝试启动，但是日志里的信息却始终没有更新.

关于日志位置和权限属主的限制，请参见 "日志文件位置, 属主和权限" 获取更多的信息。


2. 网络的 socket 文件权限或者属主错误

这种情况下，守护进程的日志会显示以下信息:

3. OLR 文件损坏

这种情况下，守护进程的日志会显示以下信息(以下是个 ora.ctssd 无法启动的例子):

 
解决办法，请恢复一个好的OLR的副本，具体办法请参见 note 1193643.1   
 

问题 7: CRSD Agents 无法启动

CRSD.BIN 会负责衍生出两个 agents 进程来启动用户的资源，这两个 agents 的名字和 ohasd.bin 的 agents 的名字相同：

  orarootagent: 负责启动 ora.netn.network, ora.nodename.vip, ora.scann.vip 和 ora.gns
  oraagent: 负责启动 ora.asm, ora.eons, ora.ons, listener, SCAN listener, diskgroup, database, service 等资源

我们可以通过以下命令查看用户的资源状态:

如果 crsd.bin 无法正常启动以上任何一个 agent，用户的资源都将无法正常启动.  

1. 通常这些 agent 无法启动的常见原因是 agent 的日志或者日志所在的路径没有设置合适的权限或者属主。

请参见以下 "日志文件位置, 属主和权限" 部分关于日志权限的设置。

2. agent 可能因为 bug 11834289 无法启动，此时我们会看到 "CRS-5802: Unable to start the agent process"错误信息，请参见 "OHASD 无法启动"  #10 获取更多信息。

问题 8: HAIP 无法启动

HAIP 无法启动的原因有很多,例如：

请参见 note 1210883.1 获取更多关于 HAIP 的信息。

网络和域名解析的验证

CRS 的启动，依赖于网络功能和域名解析的正常工作，如果网络功能或者域名解析不能正常工作，CRS 将无法正常启动。

关于网络和域名解析的验证，请参考： note 1054902.1

日志文件位置, 属主和权限

正确的设置 $GRID_HOME/log 和这里的子目录以及文件对 CRS 组件的正常启动是至关重要的。

在 Grid Infrastructure 的环境中:

我们假设一个 Grid Infrastructure 环境，节点名字为 rac1, CRS 的属主是 grid, 并且有两个单独的 RDBMS 属主分别为： rdbmsap 和 rdbmsar，以下是 $GRID_HOME/log 中正常的设置情况:

drwxrwxr-x 5 grid oinstall 4096 Dec  6 09:20 log
  drwxr-xr-x  2 grid oinstall 4096 Dec  6 08:36 crs
  drwxr-xr-t 17 root   oinstall 4096 Dec  6 09:22 rac1
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:20 admin
    drwxrwxr-t 4 root   oinstall  4096 Dec  6 09:20 agent
      drwxrwxrwt 7 root    oinstall 4096 Jan 26 18:15 crsd
        drwxr-xr-t 2 grid  oinstall 4096 Dec  6 09:40 application_grid
        drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 oraagent_grid
        drwxr-xr-t 2 rdbmsap oinstall 4096 Jan 26 18:15 oraagent_rdbmsap
        drwxr-xr-t 2 rdbmsar oinstall 4096 Jan 26 18:15 oraagent_rdbmsar
        drwxr-xr-t 2 grid  oinstall 4096 Jan 26 18:15 ora_oc4j_type_grid
        drwxr-xr-t 2 root    root     4096 Jan 26 20:09 orarootagent_root
      drwxrwxr-t 6 root oinstall 4096 Dec  6 09:24 ohasd
        drwxr-xr-t 2 grid oinstall 4096 Jan 26 18:14 oraagent_grid
        drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdagent_root
        drwxr-xr-t 2 root   root     4096 Dec  6 09:24 oracssdmonitor_root
        drwxr-xr-t 2 root   root     4096 Jan 26 18:14 orarootagent_root     
    -rw-rw-r-- 1 root root      12931 Jan 26 21:30 alertrac1.log
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:44 client
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 crsd 
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:24 cssd 
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:24 ctssd
    drwxr-x--- 2 grid oinstall  4096 Jan 26 18:14 diskmon 
    drwxr-x--- 2 grid oinstall  4096 Dec  6 09:25 evmd      
    drwxr-x--- 2 grid oinstall  4096 Jan 26 21:20 gipcd      
    drwxr-x--- 2 root oinstall  4096 Dec  6 09:20 gnsd       
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:58 gpnpd     
    drwxr-x--- 2 grid oinstall  4096 Jan 26 21:19 mdnsd     
    drwxr-x--- 2 root oinstall  4096 Jan 26 21:20 ohasd      
    drwxrwxr-t 5 grid oinstall  4096 Dec  6 09:34 racg        
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgeut
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgevtf
      drwxrwxrwt 2 grid oinstall 4096 Dec  6 09:20 racgmain
    drwxr-x--- 2 grid oinstall  4096 Jan 26 20:57 srvm        

请注意，绝大部分的子目录都继承了父目录的属主和权限，以上仅作为一个参考，来判断 CRS HOME 中是否有一些递归的权限和属主改变，如果您已经有一个相同版本的正在运行的工作节点，您可以把该运行的节点作为参考。

在 Oracle Restart 的环境中:

这里显示了在 Oracle Restart 环境中 $GRID_HOME/log 目录下的权限和属主设置:

drwxrwxr-x 5 grid oinstall 4096 Oct 31  2009 log
  drwxr-xr-x  2 grid oinstall 4096 Oct 31  2009 crs
  drwxr-xr-x  3 grid oinstall 4096 Oct 31  2009 diag
  drwxr-xr-t 17 root   oinstall 4096 Oct 31  2009 rac1
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 admin
    drwxrwxr-t 4 root   oinstall  4096 Oct 31  2009 agent
      drwxrwxrwt 2 root oinstall 4096 Oct 31  2009 crsd
      drwxrwxr-t 8 root oinstall 4096 Jul 14 08:15 ohasd
        drwxr-xr-x 2 grid oinstall 4096 Aug  5 13:40 oraagent_grid
        drwxr-xr-x 2 grid oinstall 4096 Aug  2 07:11 oracssdagent_grid
        drwxr-xr-x 2 grid oinstall 4096 Aug  3 21:13 orarootagent_grid
    -rwxr-xr-x 1 grid oinstall  13782 Aug  1 17:23 alertrac1.log
    drwxr-x--- 2 grid oinstall  4096 Nov  2  2009 client
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 crsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 cssd
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 ctssd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 diskmon
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 evmd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gipcd
    drwxr-x--- 2 root   oinstall  4096 Oct 31  2009 gnsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 gpnpd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 mdnsd
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 ohasd
    drwxrwxr-t 5 grid oinstall  4096 Oct 31  2009 racg
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgeut
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgevtf
      drwxrwxrwt 2 grid oinstall 4096 Oct 31  2009 racgmain
    drwxr-x--- 2 grid oinstall  4096 Oct 31  2009 srvm

网络socket文件的位置，属主和权限

网络的 socket 文件可能位于目录： /tmp/.oracle, /var/tmp/.oracle or /usr/tmp/.oracle 中。

当网络的 socket 文件权限或者属主设置不正确的时候，我们通常会在守护进程的日志中看到以下类似的信息:

以下错误也有可能提示:

解决的办法：请使用 root 用户停掉 GI，删除这些 socket 文件，并重新启动 GI。


我们假设一个 Grid Infrastructure 环境，节点名为 rac1, CRS 的属主是 grid，以下是 socket 文件夹(../.oracle)正常的设置情况:

在 Grid Infrastructure cluster 环境中:

以下例子是集群环境中的例子：

在 Oracle Restart 环境中:

以下是 Oracle Restart 环境中的输出例子:

诊断文件收集

如果通过本文没有找到问题原因，请使用 root 用户，在所有的节点上执行 $GRID_HOME/bin/diagcollection.sh ，并上传在当前目录下生成所有的 .gz 压缩文件来做进一步诊断。

参考