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进程，竟然会引起数据库无法启动的问题。