發現 http action 所在 ora 資源 mage 時間 重建表

上午10:03分收到資源同步庫的宕機告警，登陸數據庫核實數據庫確實異常，第一反應手動重啟庫，但依舊失敗。

回過頭查看數據庫告警日誌，發現大量的600和7445報錯

查看trace文件，發現都是對同一個表T_PRODUCT_ADDR_6_8_TEMP_AREA的更新操作：

在連續的報錯後，數據庫自身有個壞塊recover的操作

從在線日誌恢復成功後，依然有類似的報錯信息，最後數據庫直接宕機

【分析過程】 1.根據數據庫報錯信息中涉及的兩個數據文件號信息，在數據庫啟動到mount狀態，通過以下腳本查詢對應的數據文件

2.用DBV工具查看是否存在邏輯壞塊

發現數據文件repgx11.dat確實存在壞塊 3.查看主機日誌，沒有IO相關報錯 4.登陸資源同步庫所連存儲EVA8100和EVA6400查看，也無異常報錯信息 5.剩下的就是考慮如何恢復的問題： 從上面的報錯信息可以看出是由於存在壞塊，導致事務異常而無法回滾，通過設置event=‘10513 trace name context forever,level 2‘內部事件後，SMON不再recover dead transaction ，數據庫能正常打開。至此數據庫正常恢復。

6.雖然數據庫正常打開，但壞塊問題依然存在，通過告警日誌的提示信息file 58 block 367365查找壞塊所在的對象

跟trace文件中提示的操作對象一致，通過重建該表，並rename互換解決該問題 互換後： 7.修改pfile，刪除event時間，使用spfile重啟數據庫，正常，數據庫無類似的異常報錯 8.通過DBV校驗問題文件 已恢復正常 【附屬說明】 1.如果在重建表後，壞塊依然存在，可以刪除原來的表，再使用CREATE TABLE命令將原存在邏輯壞塊的數據塊覆蓋，避免上述ORA-600問題再次發生。 create table LARGE_TABLE (t1 int) tablespace REP_GX; alter table LARGE_TABLE allocate extent (datafile ‘/dsgdata/zydata/repgx17.dat‘ size 10M); 2.如果數據庫處於歸檔模式，且有備份，可以通過RMAN來恢復 RMAN> blockrecover datafile 58 block 367365 from backupset;

數據庫壞塊觸發ora-00600和ora-07445