日期: 2009 年 5 月 26 日

Oracle惊魂

今天中午,上演了一场Oracle数据库惊魂。

我们生产环境使用Oracle RAC,Oracle有两个节点,在中午11点30左右的时候,发现节点1故障,SSH不能连接,应用反映出来数据库连接不正常,此时节点2正常,由于SSH不能连接,也无法判断节点1服务器到底出现什么故障,所以,我让IT支持同事通知IDC重起节点1的机子,谁知噩梦开始发生,IDC工作人员竟然重起了节点2,导致两个节点都瘫痪,也不知道使我们机子的标签贴的有问题还是中国电信的工作水平是如此这般,无奈之下,只能等待,并通知IDC还是要重起节点1的机子,非常诡异的是节点2这台本来正常的机子,在重起后竟然SSH不能连接,真是祸不单行啊,在节点1的机子启动后,它上面的Oracle服务也恢复了正常,接下来只能再通知IDC重起节点2,此时只能保佑不要连不上,还算幸运,在几分钟的等待之后,节点2终于启动了,也能SSH上了,其Oracle服务器也在启动,我同时用crs_stat -t在观察节点状态,发现只有ora.ordb2.gsd处于UNKNOWN 状态,其他的都已经ONLINE了,用crs_stop ora.ordb2.gsd不行将其停掉,出现错误

Attempting to stop `ora.ordb2.gsd` on member `ordb2`
`ora.ordb2.gsd` on member `ordb2` has experienced an unrecoverable failure.
Human intervention required to resume its availability.
CRS-0216: Could not stop resource ‘ora.ordb2.gsd’.

crs_start ora.ordb2.gsd也不行

CRS-1028: Dependency analysis failed because of:
‘Resource in UNKNOWN state: ora.ordb2.gsd’
CRS-0223: Resource ‘ora.ordb2.gsd’ has placement error.

这是又急坏了我和远程支持我们的DBA,最后通过命令crs_stop ora.ordb2.gsd -f停止了ora.ordb2.gsd,再crs_start ora.ordb2.gsd,终于好了,Oracle恢复了正常。