幸运还是不幸，又遭遇ORA-00600 [kfgFinalize_2]，导致业务宕机20分钟

为生产系统扩容，准备把两台rac的机器的内存全部从8G升级到16G，凌晨3点开始实施，方案如下：首先应用全部切换到节点1，然后停节点2，加内存，然后节点2起来，不幸发生，节点2的ASM实例启不来，本来实例是自动启动的，手工去启动也启不来，磁盘不能被MOUNT，报错如下：
Errors in file /u01/app/oracle/admin/+ASM/udump/+asm2_ora_11560.trc:
ORA-00600: internal error code, arguments: [kfgFinalize_2], [], [], [], [], [], [], [][@more@]

打开trace文件，错误如下：
ksedmp: internal or fatal error
ORA-00600: internal error code, arguments: [kfgFinalize_2], [], [], [], [], [], [], []
Current SQL statement for this session:
ALTER DISKGROUP ALL MOUNT
后面就是一堆天书的二进制码，看来是磁盘组mount的时候出现问题。难道是加内存出现了问题，内存拔掉，问题依旧。网上搜索了半天，发现是oracle的一个bug。
解决的办法有三个：
1、升级到10.2.0.3
2、打一个patch上去
3、把活着的那个节点的PMON进行kill掉，然后重新启动活着的节点的实例，使得强制对数据库进行恢复

评估一下，方案1动作太大，而且这个版本没有测试使用过。方案2的readme文件里明确写着这个patch可能会造成数据丢失，要在oracle support的支持下做，俺们没有support，看来方案三比较可行，可问题是现在至少有一个节点活着，如果强行kill pmon进程后，节点1也起不来了，那就全玩完了，只有准备好切dataguard的方案先了。后来在oracle的论坛上看见说不用kill pmon的，只要把两个节点都宕下来，然后启动就ok。这个方案最安全，到现在无论哪种方案都是要停业务的，估计最少要影响20分钟业务，向上级汇报，得到批准。
把节点1也宕下来，干脆把内存也插上去。很多资料说这个bug下至少有一个节点能正常mount上来的，既然节点2不能mount上来，那干脆先起节点2，能成功mount了再起节点1。节点2启动后，mount正常，启动节点1，看见SUCCESS: diskgroup DATA was mounted提示出来了，放心了。

数据库全部起来后，业务恢复正常，内存也成功的从8G升级到了16G

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25016/viewspace-984622/，如需转载，请注明出处，否则将追究法律责任。