Backup And Recovery User's Guide-決定是否允許恢復標誌損壞的塊：階段3

當介質恢復遇到了問題，則預警日誌可能會表明，如果允許將引起問題的塊標記為損壞的塊，則恢復是可以繼續的。

預警日誌包含塊的資訊：塊的型別、塊的地址、塊屬於的表空間。對於包含使用者資料的塊，預警日誌也可以報告資料物件號。

在這種情況下如果允許標記有問題的塊為損壞的，則資料庫可以繼續恢復。然而這種方式不總是建議的。

如果這個塊是SYSTEM表空間中的重要的塊，把這個塊標記為損壞可能會最終阻止你開啟恢復的資料庫。

另一個考慮是這個恢復問題是否是獨立的。

如果這個問題在後面立即跟了redo流中的許多其它問題，則可能想使用RESETLOGS選項開啟資料庫。

對於使用者資料的塊，可以查詢資料庫來發現哪個物件或表擁有這個塊。

如果資料庫沒有開啟，你可以使用只讀方式開啟，即使你正在恢復整個資料庫備份。

下面的程式碼中斷了恢復，以只讀方式開啟資料庫：

CANCEL

ALTER DATABASE OPEN READ ONLY;

假設在alert_SID.log中報告的資料物件的編號為8031，則可以通過下面的查詢確定所有者、物件名和物件型別。

SELECT OWNER, OBJECT_NAME, SUBOBJECT_NAME, OBJECT_TYPE

FROM DBA_OBJECTS WHERE DATA_OBJECT_ID = 8031;

判斷一個恢復問題是否是獨立的，可以執行一個診斷的試驗恢復，這個試驗恢復會掃描redo流，

但不會對恢復的資料庫進行任何改變。如果試驗恢復發現了任何恢復問題，則會在alert_SID.log中報告這些問題。

使用RECOVER…TEST開始一個試驗恢復過程。

在已經做了上述調查之後可以遵循表 29.6中的指導來決定是否允許恢復允許損壞塊。

表 29.6 允許對允許損壞的資料塊的恢復

如果問題是…	如果塊是…	則…
不獨立		應該能夠使用RESETLOGS選項開啟資料庫。這個響應對於stuck恢復問題是非常重要的。因為stuck恢復問題可以被作業系統或儲存系統丟失寫操作而引起。如果作業系統或儲存系統突然失敗，則可以在多個塊上引起stuck恢復問題。
獨立	在SYSTEM表空間中	不損壞塊，因為它可能會最終阻止你開啟資料庫。然而，有些時候在SYSTEM表空間的資料是不重要的。如果你必須損壞SYSTEM塊並恢復所有的改變，則聯絡Oracle Support Service
獨立	索引資料	考慮破壞索引，因為索引可以在資料庫被恢復之後被重建。
獨立	使用者資料	根據的資料的重要性來決定。如果繼續資料檔案恢復並且損壞了一個資料塊，則會丟失在資料塊中的資料。然而後面可以使用RMAN來執行快介質恢復，即在恢復完成之後。
獨立	回滾或undo資料	如果所有的事務都被提交了，則可以考慮損壞回滾或undo資料塊。如果產生這些undo資訊的事務永遠不被回滾，則資料庫是不會受到傷害的。然而如果那些事務被回滾，則損壞undo資料塊可能會引起問題。如果不確定，則聯絡Oracle Support Service

來自 “ ITPUB部落格 ” ，連結：http://blog.itpub.net/17013648/viewspace-1101388/，如需轉載，請註明出處，否則將追究法律責任。

相關文章