Oracle] 解析在沒有備份的情況下undo損壞怎麼辦

Oracle在運行中很不幸遇到undo損壞，當然最好的方法是完全恢復，但如果是在沒有備份的情況下undo損壞怎麼辦？以下就為大家介紹出現這種情況的解決辦法，需要的朋友參考下  

如果Oracle在運行中很不幸遇到undo損壞，當然最好的方法是完全恢復，不過如果沒有備份，可以采用一種非常規的手段（利用Oracle的隱藏參數），如果此時undo包含未提交的事務，會造成一點點的數據丟失（一般都是可忍受的），如果沒有未提交的事務，則不會有數據丟失。其主要步驟有：

1. 修改undo表空間管理為手動；
2. 設置隱藏參數(_offline_rollback_segments或_corrupted_rollback_segments)標識受影響的回滾段，使Oracle忽略其上的未提交事務；
3. 手動刪除受影響的回滾段和undo表空間，然後重建新的undo表空間；
4. 還原undo表空間管理為自動。

實驗如下：
Step 1.
如果undo數據文件損壞，數據庫只能到mount狀態，open時會出現以下錯誤：
ORA-01157: cannot identify/lock data file 14 - see DBWR trace file
ORA-01110: data file 14: 'I:INTEL_DATAO06DMS0UNDO1.O06DMS0'
說明該undo文件已經損壞或丟失，把該文件offline之後就可以打開數據庫了：
SQL> alter database datafile 'I:INTEL_DATAO06DMS0UNDO1.O06DMS0' offline drop;
SQL> alter database open;
打開數據庫的目的是為了找出受影響的回滾段：
SQL> select segment_name,status from dba_rollback_segs;

SEGMENT_NAME                   STATUS
------------------------------ ----------------
SYSTEM                         ONLINE
_SYSSMU10_1201331463$          OFFLINE
_SYSSMU9_2926456744$           OFFLINE
_SYSSMU8_640224757$            OFFLINE
_SYSSMU7_3984293596$           OFFLINE
_SYSSMU6_3694658906$           OFFLINE
_SYSSMU5_3475919656$           OFFLINE
_SYSSMU4_168502732$            OFFLINE
_SYSSMU3_1987193959$           OFFLINE
_SYSSMU2_3908286755$           OFFLINE
_SYSSMU1_3281912951$           OFFLINE

SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      undo1
關閉數據庫：
SQL> shutdown immediate;

Step 2.
創建一個臨時的pfile：
SQL> create pfile='H:initO06DMS0.ora' from spfile;
修改pfile如下：
*.undo_management='manual'   -- undo表空間管理方式修改為手動
*.undo_tablespace='undo2'     --指定一個新的undo表空間
*._offline_rollback_segments=('_SYSSMU10_1201331463$','_SYSSMU9_2926456744$','_SYSSMU8_640224757$','_SYSSMU7_3984293596$','_SYSSMU6_3694658906$','_SYSSMU5_3475919656$','_SYSSMU4_168502732$','_SYSSMU3_1987193959$','_SYSSMU2_3908286755$','_SYSSMU1_3281912951$')  --把所有受影響的回滾段都列在這裡
並以改pfile重新啟動數據庫：
SQL> startup pfile='H:initO06DMS0.ora'

Step 3.
手動刪除受影響的回滾段：
SQL>drop rollback segment "_SYSSMU10_1201331463$";
SQL>drop rollback segment "_SYSSMU9_2926456744$";
SQL>drop rollback segment "_SYSSMU8_640224757$";
SQL>drop rollback segment "_SYSSMU7_3984293596$";
SQL>drop rollback segment "_SYSSMU6_3694658906$";
SQL>drop rollback segment "_SYSSMU5_3475919656$";
SQL>drop rollback segment "_SYSSMU4_168502732$";
SQL>drop rollback segment "_SYSSMU3_1987193959$";
SQL>drop rollback segment "_SYSSMU2_3908286755$";
SQL>drop rollback segment "_SYSSMU1_3281912951$";
手動刪除舊的undo表空間：
SQL> drop tablespace undo1 including contents;
重建新的undo表空間：
SQL> create undo tablespace undo2 datafile 'I:INTEL_DATAO06DMS0UNDO2.O06DMS0' size 100m;
創建新的spfile，覆蓋舊的spfile：
SQL> create spfile from pfile='H:initO06DMS0.ora';
關閉數據庫：
SQL> shutdown immediate;

Step 4.
以原來的spfile啟動數據庫：
SQL> startup;
還原undo表空間管理為自動：
SQL> alter system set undo_management='auto' scope=spfile;
取消隱藏參數的設置：
SQL> alter system reset "_offline_rollback_segments" scope=spfile;
重啟使其生效：
SQL> shutdown immediate;
SQL> startup
SQL> show parameter undo

NAME                                 TYPE        VALUE
------------------------------------ ----------- -------------------
undo_management                      string      AUTO
undo_retention                       integer     900
undo_tablespace                      string      undo2

最終檢查一下：
SQL> select segment_name,status from dba_rollback_segs;

SEGMENT_NAME                   STATUS
------------------------------ ----------------
SYSTEM                      &