RAC无法启动,报错terminating instance due to error 304

今天在做一个change的时候,change的内容本身比较简单,就是将控制文件冗余到不同的mount point去,当alter system control_file scope=spfile之后,关闭RAC,mv控制文件,将之再次启动,使得spfile中指向的新路径的控制文件生效。问题出在了关闭RAC之后,数据库就启动不了了。

我们从关闭RAC开始,看看当时的场景。

同时我们tail -f节点1和节点2上的alertlog,发现节点2是很快很顺利的关闭了,但是节点1迟迟未关闭。

节点2的alertlog:

在14:07左右节点2就关闭了。

节点1的alertlog:

我们发现节点1是在14:13分,被RAC以shutdown abort的方式关闭的。

至此,关闭RAC的命令以以下报错结束:

虽然oracle提示了节点1无法关闭,但是检查了oracle的进程都已经消失了。确认节点1已经关闭,因此开始重新启动数据库。没想到启动的时候,起不来了:

发现此时节点是是启动到nomount状态,即有进程存在但是无法启动,节点2是没启动。
对应的alertlog为:
节点1:

节点2的alertlog为:

我们看到节点2其实也尝试启动过,但是遭遇了error 304,所以被自动关闭了。

手工shutdown abort节点1之后,尝试再次重启,还是同样的问题,节点1能启动进程,但是挂死,节点2启动之后被关闭。
不过报错信息稍有不同,只有节点2无法启动的错误了。

多次尝试都是该错误,因此,RAC起不来的原因,应该是节点2无法启动,而节点2无法启动,应该是遭遇304的错误。

我们来查一下error 304是什么:

根据alertlog,发现节点2的instance_number是2:

尝试修改pfile中的instance_number,改为:

尝试再次重启,还是报错:

此时在节点1的alertlog情况和原来相同,也是到MMNL started with pid=xxx这一步就挂住了,但是在节点2的alertlog完全没有新的内容写出来,也就是节点2根本没尝试启动。

由于改instance_number没效果,只好把instance_number再改回去。

尝试手工启动节点2:

此时,同事也在一起看这个问题,他发现了故障原因所在:虽然数据库已经被shutdown了,但是在操作系统中,还仍然存在不少LOCAL=NO的进程。

通过ps -ef看到,确实存在很多没有down下去的LOCAL=N的进程。也因为是这个原因,让oracle认为节点2还是在活动的,因此不能重新启动该实例。

而该系统的架构是2台服务器上跑2个RAC,我们目前只down下去了1个RAC,另外一个RAC还在跑,服务器上还有不少LOCAL=NO的进程,因此当时我也没太注意竟然还有down掉的那个RAC的LOCAL=NO的进程。

ok,问题已经找到,用

杀掉进程之后,再次重启数据库,成功。

唉,关于杀LOCAL=NO的进程的问题,其实我在很早的时候就写过一篇文章讲停数据库的技巧,没想到在RAC环境中,还是一样适用,没杀掉LOCAL=N进程,竟然会引起数据库无法启动的问题。

相关文章

发表评论

电子邮件地址不会被公开。 必填项已用*标注

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据