上午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;