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
unknown怎么处理
CRS appears healthy
EVM appears healthy
CRS已经启动成功叻。
现在看看资源的状况
[root@dxdb01 ~]# crs_stat -t
Name Type Target State Host
------------------------------------------------------------
b01.gsd application ONLINE UNKNOWN dxdb01
s application ONLINE UNKNOWN dxdb01
b01.vip application ONLINE ONLINE dxdb01
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成功启动，数据库启动正常。
故障完全排除。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。