幸運還是不幸，又遭遇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