一次ORACLE資料庫undo壞塊處理

接到客戶電話，資料庫delete 資料一直卡住。

2021-02-10 10:00

客戶提供堡壘機遠端方式，登入作業系統，發現資料庫異常卡頓，後臺有大量等待事件，磁碟io 已經達到峰值

2021-02-11 23:00

資料庫重新起停時間需要2 小時以上，且磁碟io 一直處於寫滿狀態，且再最後一次啟動資料庫後，undo 出現壞塊，需要客戶進行排查磁碟是否損壞

2021-02-19 09:00

接到客戶通知，磁碟修復成功。重新連入資料庫，修復壞塊，重新開啟資料庫

 

undo 段壞塊處理

在磁碟修復成功後，美創工程師重新啟動資料庫，但是smon 程式監控到#116 資料檔案存在壞塊，也就是undo 段仍然存在壞塊，無法進行回滾，為了保持資料庫的一致性讀，smon 程式直接關閉資料庫了

   需要新建undotbs2 表空間替換掉已經壞掉的undotbs1 表空間。但是資料庫只有在open 的狀態下才能建立新的undo 表空間。為了防止SMON 程式再次檢測到壞塊關閉資料庫，美創工程師將有壞塊的#116 資料檔案進行offline drop 處理。

startup mount

alter database datafile 116 offline drop;

        

也可以通過設定10531event ，禁止smon 程式進行回滾

startup mount

alter system set events '10513 trace name context forever,level 2';

       

以上兩種方法皆可以使資料庫處於open 狀態，不被smon 程式強制關閉

開啟資料庫，建立新的undo 表空間，並設定為預設表空間

create undo tablespace undotbs2 datafile '/oradata/ETL/UNDOTBS2.dbf' size 1G autoextend on;

alter system set undo_tablespace=undotbs2 scope=both;

 

      刪除舊的表空間，但是原undo 表空間仍然存在活躍的undo 段

drop tablespace undotbs1 including contents and datafiles;

 

查詢相關檢視，獲取所有原undo 表空間仍活躍的undo 段

select status,segment_name from dba_rollback_segs where status not in ('OFFLINE') and tablespace_name='UNDOTBS1';

   

新增隱含引數至pfile 引數檔案中，跳過以上查出的所有undo 段

*._allow_resetlogs_corruption=true

*._allow_terminal_recovery_corruption=true

*._corrupted_rollback_segments=(_SYSSMU10_1197734989$,_SYSSMU20_1050586925$,_SYSSMU26_3131552754$,_SYSSMU28_1349284785$,_SYSSMU32_980979620$,_SYSSMU34_3070439537$,_SYSSMU47_2705532003$,_SYSSMU50_602588002$,_SYSSMU51_201410034$,_SYSSMU58_3524391680$,_SYSSMU59_773718799$,_SYSSMU60_1941620517$,_SYSSMU61_1757677461$,_SYSSMU64_3091325918$,_SYSSMU65_2877150887$,_SYSSMU66_2848890605$)

 

       關閉資料庫，以修改後的pfile 檔案進行啟動資料庫

 

startup  pfile=/oracle/product/11.2.0/db_1/dbs/initETL.ora;

  

 

       刪除舊的表空間及其的所有資料，成功！

 

drop tablespace undotbs1 including contents and datafiles;

 

 

至此，新的undo 表空間替換成功！資料庫正常執行！

 

注意 : 將引數檔案中新增的隱含引數註釋掉，重新啟動資料庫

 

1 、確認資料庫儲存存在故障後，最好不要再對資料庫進行讀寫或者啟停操作，避免發生資料檔案損壞。