導讀：本文主要介紹了如何從一個不能正常打開的數(shù)據(jù)庫(由于一個/多個數(shù)據(jù)庫文件與其他文件不一致)中提取數(shù)據(jù)的具體示例，然后通過這個例子來給大家詳細分析丟失歸檔日志文件的恢復。

　　具體案例：

　　一個磁盤損壞了并且丟失了一個數(shù)據(jù)庫文件。從一周前的熱備轉儲數(shù)據(jù)文件，可是丟失了幾個歸檔日志文件。但是有問題的數(shù)據(jù)文件包含了最重要的表，采用什么辦法才能挽救數(shù)據(jù)呢?

　　解決方法：

　　每個數(shù)據(jù)庫管理員都知道這是有問題的，一定會丟失數(shù)據(jù)，因為某些事務丟失了，問題是會丟失多少數(shù)據(jù)?Oracle使用硬線路位置并且由于存在完整性約束問題，因此不允許正常打開數(shù)據(jù)。但是如果使用非常規(guī)的方法讓Oracle刪除其硬線路屬性，那么應該能夠提取盡可能多的數(shù)據(jù)。而通常這會比損失全部數(shù)據(jù)要好很多。

　　通常假如僅僅丟失了堆表的索引，或者某些能夠很容易重建的數(shù)據(jù)，那么最好的方法應該是刪除表空間并重建這些對象然后重新輸入。但是如果丟失的數(shù)據(jù)文件包含了重要數(shù)據(jù)并且很難恢復，而且只有前一次的備份卻又丟失了某些歸檔日志，那么用戶可能希望能夠盡可能多的從有問題的表空間恢復數(shù)據(jù)并且刪除和重建表空間。

　　具體步驟如下：

　　1.對當前擁有的數(shù)據(jù)進行一個冷備;

　　2.轉儲丟失的數(shù)據(jù)庫文件備份并應用可以應用的日志;

　　3.設置未文檔化的初始化參數(shù)，其允許你在當前狀態(tài)打開數(shù)據(jù)庫;

　　4.執(zhí)行exp并提取全部可以從有問題的表空間提取的數(shù)據(jù);

　　5.從先前的冷備轉儲數(shù)據(jù)庫;

　　6.使毀壞的數(shù)據(jù)文件offline;

　　7.執(zhí)行exp并提取第4步?jīng)]有提取的額外數(shù)據(jù);

　　8.在一次從冷備轉儲;

　　9.刪除有問題的表空間;

　　10.重建有問題的表空間;

　　11.使用第四步和第七步提取的數(shù)據(jù)重建數(shù)據(jù);

　　使用案例描述：ORDTAB表空間的一個數(shù)據(jù)文件ordtab03.dbf毀壞，其包含很多

　　ORDERS表的分區(qū)，數(shù)據(jù)文件熱備于July 4, 2004，July 4—至今的某些歸檔日志丟失。

#p#

　　第1步：備份數(shù)據(jù)庫

　　第1步的任務是冷備當前擁有的任何數(shù)據(jù)文件，在線重做日志，和控制文件。如果丟失了一個/多個數(shù)據(jù)文件但是數(shù)據(jù)庫仍然是open的，那么對每個剩余的數(shù)據(jù)文件進行熱備并確保備份期間/之后的歸檔被安全保存。

　　創(chuàng)建備份后，在關閉數(shù)據(jù)庫之前，備份一下控制文件：

　　ALTER DATABASE BACKUP CONTROLFILE TO TRACE RESETLOGS;

　　然后打開備份的控制文件，刪除第一個#之上的所有行，并刪除“RECOVER DATABASE…”到文件結尾的全部。

　　第2步：轉儲丟失的數(shù)據(jù)庫文件備份并應用日志;

　　這一步應該轉儲備份，并應用日志到直到無法在前向滾動，此時如果嘗試正常打開數(shù)據(jù)庫，將會得到ORA-01589: must use RESETLOGS or NORESETLOGS option for database open錯誤。

　　如果嘗試執(zhí)行ALTER DATABASE OPEN RESETLOGS，將會得到ORA-01195錯誤：ORA-01195: online backup of file %s needs more recovery to be consistent。

這里是Oracle使用其硬線路的位置。由于轉儲的數(shù)據(jù)文件不能恢復到與其他文件一致的位置，所以可能存在中斷的數(shù)據(jù)并且Oracle不允許正常打開數(shù)據(jù)庫。

　　第3步：設置未文檔化的實例參數(shù)并打開數(shù)據(jù)庫

　　在初始化參數(shù)文件中首先需要將job_queue_processes設置為0，然后設置_allow_resetlogs_corruption=TRUE，更改該參數(shù)后，切換到保存新控制文件的目錄，第一步創(chuàng)建的位置。然后以 SYSDBA連接并運行新的控制文件創(chuàng)建腳本。

　　此時數(shù)據(jù)庫可以打開了。

　　SQL> SELECT COUNT(*) FROM OE.orders;

　　第4步：執(zhí)行導出并提取數(shù)據(jù)

　　在這一步可以很容易的看到那些表導出了全部的數(shù)據(jù)。

　　第5步：轉儲備份的數(shù)據(jù)庫

　　這一步，以及下面兩步可選。這三步結合在一起允許提取更多的數(shù)據(jù)，這一步從備份的數(shù)據(jù)庫轉儲可以高效的撤銷任何由于使用_allow_resetlogs_corruption參數(shù)造成的毀壞。因此，這一步不會恢復任何丟失的數(shù)據(jù)文件。

　　第6步：使毀壞的數(shù)據(jù)文件offline

　　ALTER DATABASE DATAFILE '/u07/oradata/PRD/ordtab03.dbf' OFFLINE;

　　這一步得到數(shù)據(jù)庫的完全一致性狀態(tài)。

　　第7步：執(zhí)行導出并提取額外的數(shù)據(jù)

　　這一步可能能夠提取從第四步不能提取的額外數(shù)據(jù)，如索引中的數(shù)據(jù)。

　　第8步 ：轉儲數(shù)據(jù)庫

　　這是最后一次轉儲數(shù)據(jù)庫，這一步正式回滾數(shù)據(jù)庫到使用隱含參數(shù)前那一刻，然后將數(shù)據(jù)庫返回到正常狀態(tài)，如果從第五步轉儲以來沒有更新任何數(shù)據(jù)，可以跳過這一步。

　　第9步：刪除有問題的表空間

　　首先需要查看是否有完整性約束限制，使用以下查詢：

　　SELECT CR.constraint_name
　　FROM dba_constraints CR, dba_constraints CP, dba_tables TP, dba_tables TR
　　WHERE CR.r_owner = CP.owner
　　AND CR.r_constraint_name = CP.constraint_name
　　AND CR.constraint_type = 'R'
　　AND CP.constraint_type IN ('P', 'U')
　　AND CP.table_name = TP.table_name
　　AND CP.owner = TP.owner
　　AND CR.table_name = TR.table_name
　　AND CR.owner = TR.owner
　　AND TR.tablespace_name <> 'ORDTAB'
　　AND TP.tablespace_name = 'ORDTAB';

　　如果有約束，可能需要創(chuàng)建重建腳本。如果使用export dump重建數(shù)據(jù)，約束可以從導出文件轉儲。

　　DROP TABLESPACE ordtab INCLUDING CONTENTS CASCADE CONSTRAINTS;

　　第10步：重建表空間

       第11步：重建數(shù)據(jù)

　　執(zhí)行導入后，結束。

上文中深入講解了丟失歸檔日志文件的丟失的恢復方法，相信大家在以后遇到類似的問題，自己就能輕松解決，大家都要熟練掌握哦，希望能夠對大家有所幫助。

【編輯推薦】

1. 數(shù)據(jù)庫中利用角色增強應用系統(tǒng)安全
2. 講解Oracle數(shù)據(jù)庫提供的多種安全性措施
3. 如何恢復數(shù)據(jù)庫的內容