ORACLE復原段資料表空間資料檔案丟失或損壞處理方法

問題描述：
這是一個復原段資料表空間資料檔案丟失或損壞的情景，這時oracle不能識別相應的資料檔案。當你試圖startup資料檔案時會報ORA-1157，ORA-1110，並且可能會伴隨著標識作業系統層級的錯誤，比如ORA-7360。當你試圖以shutdown normal或shutdown immediate模式關閉資料庫時會導至ORA-1116,ORA-1110,並可能伴隨標識作業系統層級的錯誤，比如ORA-7368，有時以正常方式shutdown資料庫根本shutdown不下來。

警告：
文章中所提及的步驟是供oracle的全球支援人員使用的。特別是步驟6中的_corrupted_rollback_segments參數，使用後需要重建資料庫，在使用這個參前請觀察一下所有其它的選項。

解決方案解釋：

如下的解決方案取於檢測問題出現時資料庫所處於狀態:

I. 資料庫是處於關閉狀態的。
試圖開啟資料庫時報ORA-1157和ORA-1110錯誤，這時的解決方案取於資料庫是否是正常shutdown的(使用normal或immediate選項。

I.A.資料庫是正常shutdown的

如果資料資料庫是正常shutdown的，最簡單的解決方案是以offline drop選項刪除丟失或損壞的資料檔案，以restriceted模式打個資料庫，刪除並重建這個資料檔案所屬的那個復原資料表空間。如果資料庫是以shutdown abort或自己崩潰掉的則不要遵循這個過程。

步驟如下：

1、確認資料庫是正常shutdown的。可以檢查alter.log這個檔案，定位到最後幾行看是否可以看到如下的資訊：
  "alter database  dismount
   Completed: alter database  dismount"

這當然也包括以正常方式shutdown,接然試圖啟動資料庫確失敗的狀況。如果最近一次你是以shutdown abort方式關閉資料庫的或資料庫是自己crashed掉的，你應用使用下面的I.B的方法。

2、在init<sid>.ora中把屬於遺失資料檔案的復原段從ROLLBACK_SEGMENTS參數中去掉。如果你不能確信是哪個復原段，可以簡單的把ROLLBACK_SEGMENTS這個參數注釋掉。

3、以restricted模式mount資料庫
  STARTUP RESTRICT MOUNT;
 
4、Offline drop丟失或損壞的那個資料檔案。
  ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE DROP;
   
5、開啟資料庫
  ALTER DATABASE OPEN；
  如果返回"Statement processed"這條資訊，轉到第7步.
  如果得到ORA-604,ORA-376,和ORA-1110錯誤，轉到第6步。

6、因為開啟資料庫失敗，shutdown掉資料庫並且編輯int<SID>.ora這個檔案。注釋掉ROLLBACK_SEGMENTS這個參數，並且在init<SID>.ora檔案中加入如下一行：
  _corrupted_rollback_segments = (<rollback1>,...,<rollbackN>)
  這個參數應當包含ROLLBACK_SEGMENTS中所有的復原段。

需要注意的是這個參數只能在指定的情況下或在oracle的全球持術支援的指導下才應使用，然後以restricted模式開啟資料庫：
 

  STARTUP RESTRICT
 
7、刪除掉那個檔案所屬的復原段資料表空間。
  DROP TABLESPACE <tablespace name> INCLUDING CONTENTS;
 
8、重建復原段資料表空間及復原段，建立完後使它們online.

9、使資料庫所有使用者都可用。
  ALTER SYSTEM DISABLE RESTRICTED SESSION;

10、在init<SID>.ora中把你重新建立的復原段再一次包括進來，如果你使用了第6步則移除掉CORRUPTED_ROLLBACK_SEGMENTS這個參數。

I.B.資料庫不是正常shutdown的

這種情況，資料庫最近一次是用shutdown abort或crashed掉關閉，復原段中幾乎一定包含著活動的事務。因此，壞的那個資料檔案不能離線(offline)或是drop掉，你必需從備份恢複這個檔案。如果資料為是處於非歸檔模式的，只有最近的一些交易記錄還沒有被重寫掉的情況你才能成功恢複這個檔案。如果這個檔案的備份也是無效的，聯絡一下oracle的支援人員吧。

步驟如下：

1、從備份中恢複丟失的那個資料檔案.

2、mount 上資料庫

3、執行如下的查詢：
  SELECT FILE#,NAME,STATUS FROM V$DATAFILE;
  如果資料檔案的狀態是offline的，你必需先把它聯機了：
  ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;
 
4、執行如下的查詢：

  SELECT V1.GROUP#, MEMBER, SEQUENCE#, FIRST_CHANGE#
    FROM V$LOG V1, V$LOGFILE V2
   WHERE V1.GROUP# = V2.GROUP# ;
  
  這將列出所有的聯機的重做日誌和他們的序號及首次改變號(first change numbers).
 
5、如果這個資料庫是非歸檔模式的，執行如下的查詢： 
  SELECT FILE#, CHANGE# FROM V$RECOVER_FILE;
  如果其中的CHANG#比4中的最小的那個FIRST_CHANGE#大的話，用聯機日誌就可以完成恢複。
 
6、如果CHANG#比4中的最小的那個FIRST_CHANGE#小，則資料庫是不能恢複的，可以聯絡一下oracle的支援人員。  

譯者插入：如果你真是非歸檔方式且這個檔案的備份也是無效的，如果你認為可以丟失復原段中的那事務，你可以用I.A中從第6步的方法，這時可以開啟資料庫，應立即做一個備份，因為庫中的資料有些不一致。

  RECOVER DATAFILE '<full_path_file_name>'

7、確認所有的日誌都被恢複，只到你收到"Media recovery complete"資訊。

8、開啟資料庫

II. 資料庫是啟動著的

如果你檢測到丟失或損壞了復原段資料表空間的資料檔案，並且資料庫是運行著的，不要把它down掉。在很多情況下，資料庫是啟著的比關閉著解決問題更容易些。

這種情況的兩種可能的解決方案:

A)使丟失的那個資料檔案offline,並從備份中恢複它，這種情況適用於資料庫是處于歸檔方式的。

B)另一個方法是offline掉所有的那個檔案所屬資料表空間的復原段，drop那個資料表空間,然後得建它們。你可能不得不殺掉那些使用著復原段的進程，以便使它offline.

方法II.A:從備份恢複那個資料檔案

這個方法只有你的庫是在歸檔方式下才能使用。

1、離線(offline)那個丟失的資料檔案。
  ALTER DATABASE DATAFILE '<full_path_file_name>' OFFLINE;
 
提示：其於目前資料庫的事務量，你可能需要建一個臨時的復原資料表空間和一些臨時的復原段以備正常業務運行。

2、從備份中恢複(restore)那個資料檔案。

3、執行如下命令

   SELECT V1.GROUP#, MEMBER, SEQUENCE#
     FROM V$LOG V1, V$LOGFILE V2
    WHERE V1.GROUP# = V2.GROUP# ;
  這將列出所有的聯機的重做日誌和他們的序號及首次改變號(first change numbers).

4、得用聯機日誌及歸檔日誌恢複那個檔案
  RECOVER DATAFILE '<full_path_file_name>'
 
5、確認所有的日誌都被恢複，只到你收到"Media recovery complete"資訊。

6、使這個資料檔案online
  ALTER DATABASE DATAFILE '<full_path_file_name>' ONLINE;
 

方法II.B:重建復原資料表空間

這種方法不必考慮資料庫是否是歸檔模式的。

步驟如下：

1、試圖離線所有的丟失或損壞資料檔案所在復原資料表空間中所包含的復原段。
  ALTER ROLLBACK SEGMENT <rollback_segment> OFFLINE;
  重複執行這個命令直到所包含的復原段都離線.
 
2、檢查復原段的狀態。
  在drop掉它們之前它們必需是offline狀態的。 
  SELECT SEGMENT_NAME, STATUS FROM DBA_ROLLBACK_SEGS
   WHERE TABLESPACE_NAME = '<TABLESPACE_NAME>';

3、刪除掉所有離線的c。
   DROP ROLLBACK SEGMENT <rollback_segment>;
  
4、處理那些保持online狀態的復原段
   重複執行2一下的命令，如果復原段在執行1中命令仍保扭虧為盈"ONLINE"狀態，意味著它之中有活動的事務，你可以用如下的查詢來確認一下：
   SELECT SEGMENT_NAME, XACTS ACTIVE_TX, V.STATUS
     FROM V$ROLLSTAT V, DBA_ROLLBACK_SEGS
    WHERE TABLESPACE_NAME = '<TABLESPACE_NAME>' AND SEGMENT_ID = USN;
   如果這個查詢沒有結果返回，意味著沒有事務在這些復原段中了。哪果有結果返回，那些不能offline的復原段的狀態應為"PENDING OFFLINE"。可以用5中的方法把這些事務殺掉。
  
5、強制使有活動事務的復原段離線
 執行如下查詢，看這些"PENDING OFFLINE"的復原段包含哪些事務。
 SELECT S.SID, S.SERIAL#, S.USERNAME, R.NAME "ROLLBACK"
   FROM V$SESSION S, V$TRANSACTION T, V$ROLLNAME R
  WHERE R.NAME IN ('<PENDING_ROLLBACK_1>', ... , '<PENDING_ROLLBACK_N>')
 AND S.TADDR = T.ADDR AND T.XIDUSN = R.USN;         

 用ALTER SYSTEM KILL SESSION '<SID>, <SERIAL#>';語句殺掉這些事務，重複執行上面的查詢，直到沒有事務存在，這時運行一下2中的查詢，確認這些復原段己經處於offline狀態,並用3中的語句把它們drop掉。

6、刪除這個復原資料表空間。
 DROP TABLESPACE <tablespace_name> INCLUDING CONTENTS;
 如果語句執行失敗，請與oracle支援人員聯絡，否則轉向7

7、重建復原段資料表空間。

8、重建復原段，並使它們聯機(online)。

譯者按：

  復原段資料表空間的資料檔案丟失或損壞在實際中是比較棘手和常見的，產生這種問題 的原回很多的，比如介質的損壞、人為的誤操作、機器的突然的斷電等等。

  建議沒實踐過這種操作的oracle的愛好者可以類比一下這種故障，實際實測一下，注意一定要在測試庫，我類比的方法如下：

1、單獨建了一個rbs資料表空間，並在這個資料表空間建了一個復原段rbs_test。

2、指定一個transaction 用這個復原段

  sql>set transaction use rollback segment rbs_test;

   sql>insert into test values ('2');

   sql>insert into test values('3');

3、另開一個telnet視窗telnet至主機，執行如下命令:

   sqlplus /nolog

   sql>conn / as sysdba

   sql>shutdown abort

4、把新加的那個復原段資料表空間的資料檔案更個名。