遭遇ORA-00600: internal error code, arguments: [kcrrrfswda.11], [4], [368], [], [], [], [], []

因為清理歷史資料需要，所以對一列老的RANGE分割槽直接做DROP操作，因為這些分割槽表上還有GLOBAL索引，而業務又不能停，所以DROP的時候使用了UPDATE GLOBAL INDEX引數，使得DROP分割槽的時候索引不會失效。在處理最大的一個1.7億的表（每個分割槽大概有4千萬資料）的時候，DROP第一個分割槽，沒問題，清除第二個分割槽過程中，收到系統監控的報警：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb1_lns1_28689.trc:
ORA-00272: error writing archive log
Thu May 8 22:23:26 2008
LGWR: I/O error 272 archiving log 2 to 'dgp'
DGP是PHYSICAL DATAGUARD，看來是往物理DATAGUARD上寫日誌的時候出現問題，於是登陸物理DATAGUARD機器檢查，卻發現DATAGUARD機器出現如標題所示的600錯誤，檢視TRACE檔案，一堆二進位制的天書。咋辦呢？[@more@]

看來這個問題不解決，生產上日誌是應用不過來了，所以在生產上先把往這裡寫的日誌關閉，然後繼續DROP分割槽，經過漫長的等待，終於刪除完了。想想難道是因為刪除分割槽的時候UPDATE GLOBAL INDEX使得生成的日誌過多，或者是DATAGUARD機器磁碟空間不夠了？磁碟空間足夠，歸檔缺失有點快，1G一個的日誌，7分鐘歸檔一次，可是相應的邏輯的DATAGUARD卻沒有這樣的問題啊，歸檔被成功的寫過去了。看來跟歸檔頻率也沒關係。

METALINK了一把，碰見這樣問題的人很少，而且碰見的問題很多都是SUSPEND中，只有幾個是Vendor OS Problem，難道是作業系統問題？檢查/VAR/LOG/MESSAGE，沒有任何異常。過了兩個小時，更狠的來了，凌晨2點有物理DATAGUARD上的資料備份，備到一半，機器直接掛了，PING不通，SSH連不上，徹底歇菜了。

第二天，直接衝到機房，接上顯示器，螢幕上一堆天書樣的字母，沒有什麼有價值的資訊，而且鍵盤也沒有任何反應，當機？只能重新啟動，啟動後，機器恢復正常。於是開始生產往這邊的歸檔日誌寫，一會功夫，開始報錯：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_mrp0_6966.trc:
ORA-00399: corrupt change description in redo log
ORA-00353: log corruption near block 1015371 change 4810221960 time 05/08/2008 22:22:46
ORA-00312: online log 9 thread 1: '/u02/stdlog/stdlog01.log'
最後直接導致:
MRP0: Background Media Recovery process shutdown (billdb)
而且，接著就又來了ORA 600了。

再接下來就是：
Errors in file /u01/app/oracle/admin/billdb/bdump/billdb_arc2_6961.trc:
ORA-00354: corrupt redo log block header
ORA-00353: log corruption near block 238564 change 4812352033 time 05/09/2008 03:41:51
ORA-00312: online log 11 thread 2: '/u02/stdlog/stdlog03.log'
ARC2: All Archive destinations made inactive due to error 354
直接關閉了歸檔路徑了，然後就不能歸檔了：
ORACLE Instance billdb - Archival Error
Fri May 9 13:30:09 2008
ORA-16014: log 10 sequence# 3535 not archived, no available destinations
ORA-00312: online log 10 thread 1: '/u02/stdlog/stdlog02.log'

看來是日誌壞了，而且是STANDBY REDO LOG，於是直接把STANDBY REDO LOG刪除，重新建了日誌上去。但是新的錯誤又來了：
ORA-27052: unable to flush file data
Linux-x86_64 Error: 30: Read-only file system
Additional information: 1
啊？？檔案系統出問題了？上去看了看許可權沒問題啊，正在這時，更糟糕的事情來了，機器又PING不通了，暈死！衝到機器前面一看，亮黃燈了都，ECC ERROR，十之八九是記憶體錯誤了。聯絡了廠商工程師，確認是記憶體錯誤，建議先把插槽中的記憶體位置對調下，重新開機，居然就可以了。然後立馬使用硬體檢查的工具檢查了一遍，居然記憶體檢查是OK的。

看來這一系列的問題估計都跟記憶體錯誤有關的，不過最初發現錯誤的時候伺服器居然顯示正常的綠燈，不可理解。重新進行資料庫操作，才發現存放資料檔案的磁碟都沒了，這下搞大了，FDISK看了下，分割槽還在，那就使用FSCK檢查下吧，發現一堆錯誤，到現在也只能亂投醫了，不管FSCK出現啥提示，一路YES下去。神奇的發現檢測完後，居然能mount上去了。

磁碟是認出來了，但是上面的未應用的歸檔日誌卻被損壞了：
ORA-00368: checksum error in redo log block
ORA-00353: log corruption near block 579728 change 4811213035 time 05/09/2008 02:59:53
ORA-00334: archived log: '/u02/arch/Arc_2_2575_592235202.arc'

經過漫長的RFS自動GAP這些歸檔日誌，總算應用成功了。看了看日誌應用正常，可是，故事卻沒有結束。。。

凌晨2點，資料庫備份開始，卻發現了新的錯誤：
Corrupt block relative dba: 0x01cac6ec (file 7, block 706284)
Fractured block found during backing up datafile
Data in bad block:
type: 6 format: 2 rdba: 0x01cac6ec
last change scn: 0x0001.033ab516 seq: 0x4 flg: 0x04
spare1: 0x0 spare2: 0x0 spare3: 0x0
consistency value in tail: 0x00130012
check value in block header: 0xd55f
computed block checksum: 0x11b1

壞塊？？看來這些檔案還是有問題啊，不管了，乾脆重建這個DATAGUARD吧，幾百G的庫啊，經過漫長的等待，終於搞定了，世界終於平靜了！