合 一次Oracle RAC故障处理过程
【故障处理】一次RAC故障处理过程
故障环境介绍
项目 | source db |
---|---|
db 类型 | 2节点RAC |
db version | 11.2.0.1.0 |
db 存储 | ASM |
OS版本及kernel版本 | RHEL 6.6 |
故障处理过程
晚上10点多,一个网友喊我帮忙处理RAC宕机不能启动的问题,并且告知涉及到多路径和存储的事。小麦苗对存储一向不太懂,多路径也没怎么接触,自己也没研究过这个东西。既然找到了我,那就不能不管啊,硬着头皮上去看看。结果悲催了,搞了N个小时,求助了N个人,搞到第二天中午,终于搞定了,幸运的是第二天是周末,不用上班。小麦苗把处理过程记录一下,希望我的处理过程可以帮到更多人。
刚开始上去看的时候,节点1的css不能启动,报了一大堆的错误,节点2的ha也不能正常启动。错误我忘记记录了,反正是各种研究日志,各种查MOS,各种百度,各种Google,包括OCR的还原都试了,最后没办法了,只有使用个人常用的绝招了,那就是。。。。。重新执行root.sh脚本。
关于该脚本的执行,我在个人博客中有多次提到。不过还是得多练练,因为注意事项很多。首先,如果要保持磁盘组不被删除,那么执行卸载命令(\$ORACLE_HOME/crs/install/rootcrs.pl -deconfig -force -verbose)可以加上-keepdg选项,但是11.2.0.1没有该选项。在第二个节点上执行卸载的时候可以不用加-lastnode,尽可能多的保留信息。
很幸运,小麦苗第一次执行后,集群可以正常启动了,一切安好,从10点熬到1点了吧。结果在准备导入OCR的备份的时候,需要以exec模式启动CRS,结果又悲催了,集群坏掉了。没办法,只得重启,重启更悲催,OCR的盘找不到了。小麦苗想放弃了。盘找不到,我更没办法了。只得找找懂存储的人来弄了。差不多2点了。好吧,该休息了。
早上8点多,睁眼就赶紧登teamviewer,继续处理。首先捣鼓了半天的多路径。原来第二个节点的多路径软件有问题,自己就重新安装了一下。安装后期望能看到磁盘,结果还是不行。无奈,在leshami的群里找找懂存储的高手来。肖总帮我上去看了看弄好了存储,找到了磁盘,万分感谢。
接下来就继续进行恢复操作,继续deconfig,然后root.sh。执行完root.sh后发现集群正常,自己尝试重启了一下主机,一切正常,看来就是存储搞得鬼。那就继续恢复数据库,这个是重点。由于整个操作过程都小心翼翼不敢动非OCR的盘,生怕数据搞丢了,因为10T的数据什么备份都没有,我也是醉了。用kfod看了一下磁盘,一切正常,好吧,那就接下来直接MOUNT磁盘组。重新执行root.sh后只要磁盘组的磁盘文件没有损坏,那么就可以直接MOUNT起来的。这也是在无备份情况下恢复OCR的一种办法。
接下来一切都很顺利,例如配置监听,添加DB到srvctl管理器等,真是佛祖保佑。很多处理日志并没有记录,所以这里只能给出一些脚本了。
处理过程中用到的一些脚本
重新执行root.sh脚本特别需要注意的是数据库的数据是否放在OCR磁盘组上。若放在OCR磁盘组上切记不能随意执行该脚本。
1、2个节点分别执行deconfig:
1 2 3 | export ORACLE_HOME=/u01/app/11.2.0/grid export PATH=$PATH:$ORACLE_HOME/bin $ORACLE_HOME/crs/install/rootcrs.pl -deconfig -force -verbose |
- 执行完后,需要对OCR盘进行dd,2个节点都执行:
1 2 | dd if=/dev/zero of=/dev/oracleasm/disks/OCR_VOL2 bs=1024k count=1024 dd if=/dev/zero of=/dev/oracleasm/disks/OCR_VOL1 bs=1024k count=1024 |
- 节点1执行完后再在节点2执行:
1 2 | export ORACLE_HOME=/u01/app/11.2.0/grid $ORACLE_HOME/root.sh |
另外,对于11.2.0.1版本执行root.sh有一个常见的bug错误: