crs启动失败故障的解决实例

crs启动失败故障的解决实例

接到一个客户的电话，crs启动失败。 登录客户的机器，对于crs的错误排查，从系统日志着手 在系统日志里有如下有关crs失败的信息 Jan 29 20:25:59 inthrac01 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.7004. Jan 29 20:25:59 inthrac01 su(pam_unix)[10765]: session closed for user oracle Jan 29 20:25:59 inthrac01 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.7199. Jan 29 20:25:59 inthrac01 su(pam_unix)[10769]: session closed for user oracle Jan 29 20:25:59 inthrac01 logger: Cluster Ready Services waiting on dependencies. Diagnostics in /tmp/crsctl.7574. 这里提示crs启动有故障，查看相应的日志信息 /tmp/crsctl.7004 /tmp/crsctl.7199 /tmp/crsctl.7574 都出现 OCR initialization failed accessing OCR device: PROC-26: Error while accessing the physical storage Operating System error [Permission denied] [13] 这里的错误时ocr的device的设备，没有权限访问。 既然如此，我们就看看这个裸设备的权限叻哟。 运行命令 [root@dxdb01 ~]# ocrcheck Status of Oracle Cluster Registry is as follows : Version : 2 Total space (kbytes) : 622080 Used space (kbytes) : 1932 Available space (kbytes) : 620148 ID : 1667883930 Device/File Name : /dev/raw/raw1 Device/File integrity check succeeded Device/File not configured Cluster registry integrity check succeeded ocr的设备是裸设备/dev/raw/raw1 [root@dxdb01 ~]#ls /dev/raw/raw1 -l crw-rw---- 1 root disk 162, 1 Jan 29 20:36 /dev/raw/raw1 裸设备的权限确实不正确 [root@dxdb01 ~]# chown root:oinstall /dev/raw/raw1 [root@dxdb01 ~]#ls /dev/raw/raw1 -l crw-rw---- 1 root oinstall 162, 1 Jan 29 20:36 /dev/raw/raw1 [root@dxdb01 ~]# crsctl check crs Failure 1 contacting CSS daemon Cannot communicate with CRS Cannot communicate with EVM 再等待一下。 [root@dxdb01 ~]# crsctl check crs CSS appears healthy CRS appears healthy EVM appears healthy CRS已经启动成功叻。 现在看看资源的状况 [root@dxdb01 ~]# crs_stat -t Name Type Target State Host ------------------------------------------------------------ ora....b01.gsd application ONLINE UNKNOWN dxdb01 ora....b01.ons application ONLINE UNKNOWN dxdb01 ora....b01.vip application ONLINE ONLINE dxdb01 ora....b02.vip application ONLINE ONLINE dxdb01 这里资源除了vip是UNKNOWN的 这里可以查看$CRS_HOME/log/dxdb01/alertdxdb01.log文件 可以发现一些线索叻 这里和上面一样同样是由权限导致的。 一样的方法解决，先查看vote disk的设备的权限 vote disk的权限应该是oracle:oinstall, 按照这样的权限就解决叻。 解决完了，就询问了一下是做了什么操作，客户说，也没有做什么操作，不过是共享储柜上次要换地方，就是关机，开机而已，就出现这个问题叻。 根据客户的描述，做了一下重启的动作，果然，这两个裸设备的权限又发生改变叻。 估计可以没有绑定raw device的处理 查看/etc/rc.d/rc.local确实没有 检查/etc/udev/permissions.d/50-udev.permissions文件，也是没有相关处理。 在/etc/rc.d/rc.local里加上了相关的处理 chown root:oinstall /dev/raw/raw1 chown oracle:oinstall /dev/raw/raw2 重启机器，CRS成功启动，数据库启动正常。 故障完全排除。

版权声明：本文内容由网络用户投稿，版权归原作者所有，本站不拥有其著作权，亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容，请联系我们jiasou666@gmail.com 处理，核实后本网站将在24小时内删除侵权内容。