Oracle介質恢復（一）

介質恢復是基於物理備份恢復資料，介質恢復技術是Oracle資料庫出現介質故障時恢復的重要保障。

1.        介質恢復的過程

介質恢復包括塊恢復、資料檔案恢復、表空間恢復和整個資料庫的恢復。介質恢復主要是針對錯誤型別中的介質失敗，如果是少量的塊失敗，可以使用介質恢復中的塊恢復來快速修復；但如果是其它情況的丟失，根據具體情況，可使用資料檔案恢復、表空間恢復甚至全庫恢復。

介質恢復過程包括還原（RESTORE）和恢復（RECOVER）兩個步驟：

還原是將某個時間點資料檔案的複製再複製回去，還原後的資料庫處於不一致性的狀態，或不是最新的狀態，還需要執行恢復操作。恢復就是使用歸檔Redo日誌檔案和聯機Redo日誌檔案將不一致的資料庫應用到一致性狀態。如果是完全恢復，資料庫就是最新的一致性狀態；如果是不完全恢復，資料庫是非最新的一致性狀態。

| 注意：還原只是建立在資料庫備份的基礎版本上，例如，如果資料庫備份包括0級備份和很多1級備份，還原只是應用0級備份，恢復過程會根據情況自動應用1級備份或Redo日誌將資料庫恢復到一致性的狀態。 |

資料庫的恢復過程又分為完全恢復和不完全恢復：

u  完全恢復

完全恢復是一種沒有資料庫丟失的恢復方式，能夠恢復到最新的聯機Redo日誌中已提交的資料。在傳統恢復方式中，因介質失敗破壞了資料檔案之後，可以在資料庫、表空間和資料檔案上執行完全介質恢復。

u  不完全恢復

不完全恢復是一種與完全恢復相反的恢復方式，是一種丟失資料的恢復方式，也稱為資料庫時間點恢復。通常情況下，若Flashback Database沒有啟用或者變得無效，可以執行不完全恢復撤銷一個使用者錯誤，不完全恢復不一定在原有的資料庫環境執行，可以在測試環境下執行不完全恢復，將找回的資料再重新匯入生產庫中。對於不完全恢復來說，只能執行整個資料庫的恢復，不能執行某個資料檔案或表空間的不完全恢復。

不完全恢復根據備份情況恢復到與指定時間、日誌序列號和SCN具有一致性的資料，之後的資料都將丟失。執行不完全恢復一方面是因為歸檔Redo日誌、聯機Redo日誌的丟失不得不執行不完全恢復，另一方面可能是因為在某個時刻錯誤地操作了資料，過了一段時間之後才發現問題，而其它的恢復手段都無法恢復資料，這時也不得不使用不完全恢復來找回資料。

執行不完全恢復必須從備份中還原所有的資料檔案，備份檔案必須是要恢復的時間點之前建立的。當恢復完成，使用RESTLOGS選項開啟資料庫，將重新初始化聯機Redo日誌，建立一個新的日誌序列號流，日誌序列號從1開始，RESETLOGS之後的SCN還是在遞增。

2.        物理壞塊和邏輯壞塊

Oracle資料檔案的壞塊可以分為物理壞塊和邏輯壞塊。物理壞塊指的是塊格式本身已經損壞，塊內的資料沒有任何意義。而邏輯壞塊，指的是塊內的資料在邏輯上存在問題，比如說索引塊的索引值沒有按從小到大排列導致的邏輯壞塊。物理壞塊一般是由於記憶體問題、OS問題、I/O子系統問題或硬體引起的，邏輯壞塊一般是有Oracle bug等原因引起的。

各種各樣的塊損壞通常是透過Oracle的ORA-1578錯誤報告出來的，詳細的損壞描述會在告警日誌中列印出來。

l   物理塊損壞

塊的物理損壞有很多種情況，例如塊頭（Cache Header）被一個不正確的值替換、塊被破壞或變得不完整、塊的頭和尾不匹配、塊的校驗和（CHECKSUM）不正確、塊錯位、塊被歸零。

n   破裂塊

一個破裂塊的意思即塊是不完整的，塊頭的資訊不能匹配塊尾的資訊。在告警日誌中可能出現如下的日誌資訊：

Corrupt block relative dba:0x0380e573(file 14,block 58739)

Fractured block found during buffer read

……

n   不正確的校驗和

塊的校驗和也是資料塊的一致性檢查的依據。塊的一致性檢查由DB_BLOCK_CHECKSUM和DB_BLOCK_CHECKING兩個初始化引數控制。DB_BLOCK_CHECKSUM是一種物理檢查，DB_CHECK_CHECKING是一種邏輯檢查。

 

引數1 DB_CHECK_CHECKSUM

DB_BLOCK_CHECKSUM只有在寫入（DBWn常規寫或使用者程式直接路徑寫入）時，根據一個CHECKSUM演算法計算資料塊的校驗和，然後寫入資料塊的一個特定位置（CACHE HEADER,具體是以0位元組算起，塊的第16~17位元組），在讀取塊時再進行檢驗。主要是防止I/O硬體和I/O子系統的錯誤。

CHECKSUM的演算法只是根據塊的位元組值計算一個校驗和，演算法比較簡單。該引數預設在所有表空間上都起作用。

DB_BLOCK_CHECKSUM引數屬性

屬性	描述
語法	DB_BLOCK_CHECKSUM={OFF|FALSE|TYPICAL|TURE|FULL}
預設值	TYPICAL
修改範圍	ALTER SESSION,ALTER SYSTEM

只有當引數值是TYPICAL或者FULL，並且塊的最後一次寫是儲存了一個校驗和時，讀取這個塊，校驗和才會被驗證。在FULL模式，Oracle用update/delete語句改變資料之前會驗證校驗和，改變被應用之後還會重新計算校驗和。

從Oracle Database 11g開始，大多數日誌校驗和都是透過前臺程式產生的，同時LGWR執行其餘的工作，這是為了更好地發揮CPU和快取的效率。當這個引數設定為FULL，寫日誌塊到磁碟之前，LGWR驗證透過前臺程式生成的每個日誌塊的校驗和。在Oracle Database 11g之前的版本中，LGWR獨自執行日誌塊校驗和。資料檔案塊的校驗和是由DBWR程式負責計算和管理的。

這個引數設定為OFF時，DBWn只為SYSTEM表空間計算校驗和，不為使用者表空間計算校驗和。另外，此時資料庫也不會執行日誌的校驗工作。

校驗和可以使Oracle資料庫察覺到磁碟、儲存系統或者I/O系統引起的損壞。如果設定為FULL,DB_BLOCK_CHECKSUM也會捕捉在記憶體中的損壞，並停止它們對磁碟的操作。設定這個引數為TYPICAL值只會引起系統額外的1%~2%的負載，設定為FULL會引起4%~5%的負載。Oracle推薦設定DB_BLOCK_CHECKSUM為TYPICAL。為了保持向後相容性，TRUE和FALSE值被保留，TRUE等同於TYPICAL，FALSE等同於OFF。

如果DB_BLOCK_CHECKSUM不等於FALSE值，每次讀取塊，Oracle計算校驗和，都與儲存在塊頭中的校驗和進行對比。如下例子：

Corrupt block relative dba: 0x0380a58f (file 14,block 42383)

Bad check value found during buffer read

……

引數2 DB_BLOCK_CHECKING

DB_BLOCK_CHECKING引數主要是用於資料塊的邏輯一致檢查，但只是在塊內，不包括塊間的邏輯檢查。主要用於防止在記憶體中損壞或資料損壞。

無論該引數如何設定，對SYSTEM表空間來說，邏輯一致檢查始終處於“開啟”狀態，在其他表空間該引數預設是關閉的。

DB_BLOCK_CHECKING引數的屬性

引數值	含義
OFF或者FALSE	對於使用者表空間沒有任何邏輯一致性檢查工作
LOW	塊的內容在記憶體中改變之後，執行基本的塊頭檢查，如UPDATE語句、INSERT語句、磁碟讀或者在RAC中內部例項之間的塊傳遞之後發生檢查工作
MEDIUM	除了索引以外的所有物件執行LOW檢查和完全語義檢查，由於索引能在遭遇損壞的情況下的重建，所以可以不考慮對它檢查
FULL或者TRUE	所有物件執行MEDIUM檢查和完全語義檢查

Oracle透過遍歷在塊中的資料來檢查一個塊，確保它在邏輯上手尾一致。根據系統負載和引數值，塊檢查通常一起1%~10%的負載。開啟塊檢查，大量的UPDATE或者INSERT將造成更大負載，對於一個繁忙的系統，特別有大量插入或者更新操作的系統來說，效能影響是比較明顯的。如果效能負載可以被接受，應該考慮設定DB_BLOCK_CHECKING為FULL。為了保持向後的相容性，TURE和FALSE引數值同樣可以使用，FALSE等同於OFF，TRUE等同於FULL。

如果啟用DB_BLOCK_CHECKING引數，在磁碟的塊發生邏輯損壞，下一次塊更新將作為軟損壞標記這個塊，之後讀取這個塊產生ORA-1578的錯誤。

n   塊錯位

當Oracle察覺讀取塊的內容屬於不同塊但是校驗和又是正確的時，會產生錯誤。

l   邏輯塊損壞

若塊包含一個正確的校驗和，塊頭以下的結構是損壞的（塊內容損壞），這可能引起不同的ORA-600錯誤。邏輯塊損壞的詳細損壞描述通常不會列印到告警日誌。DBV將報告塊具體的邏輯錯誤。

3.        壞塊的檢測工具

以下為損壞塊的檢測工具和使用方法：

l   DBVERIRY壞塊驗證工具

DBVERIRY不能驗證聯機Redo日誌、歸檔Redo日誌、控制檔案和RMAN備份集，只能用於資料檔案的塊驗證。

n   DBV驗證傳統資料檔案

下面是使用DBV工具驗證資料檔案塊的例子：

$ dbv file=/testdb/test01.dbf blocksize=8192

注意：DBV工具除了用於檢測資料檔案是否有壞塊外，也用於獲得壞塊的詳細資訊。

n   DBV驗證裸裝置資料檔案

DBV要求file後面跟的必須是一個包含副檔名的檔案，所以如果資料庫使用裸裝置作為儲存方式，就必須使用ln命令連線裸裝置一個帶副檔名的檔案，然後使用DBV工具透過對連結檔案的驗證實現對裸裝置資料檔案的驗證。

n   DBV驗證ASM儲存的資料檔案

如果是驗證儲存在ASM中的資料檔案則需要指定使用者名稱和密碼，如果不指定使用者名稱和密碼，將收到DBV-00008：USERID must bu specified for OSM files的報錯。下面是使用DBV工具驗證儲存在ASM中的資料檔案的塊的例子：

$ dbv file=+DATAFILE/testdb/datafile/test.234.648839 userid=sys/oracle

l   ANALYZE命令

Analyze命令的主要目的是透過分析資料庫物件，為最佳化器收集資料庫物件的統計量資訊，以便最佳化器生成準確的執行計劃。同時，它也能檢查某個表或索引是否存在損壞的情況。Analyze執行壞塊檢查，但是不會標記壞塊為corrupt，檢測結果儲存在USER_DUMP_DEST目錄下的使用者trace檔案中。Analyze語法：

Analyze table/index / validate structure ;

Analyze命令會驗證每個資料塊、每條記錄和索引的完整性。CASCADE關鍵字表示驗證表及其相關的所有索引。與DBVERIFY不同的是，analyze只驗證高水位線以下的資料塊，analyze不會對未使用的空間進行驗證。

SQL> analyze table fengpin.test validate structure;

l   RMAN工具

RMAN是一塊備份工具，就像一個過濾器，RMAN需要透過快取過濾每一個塊，其中一個特點就是檢查塊是否被損壞。如果備份的資料庫中包含有壞塊，將會收到錯誤

l   EXP工具

對於包含壞塊的表執行匯出操作，會收到相關的錯誤資訊。對於這種情況，在非歸檔模式無法透過塊恢復修復塊的情況下，有如下兩種處理方法：

方法1：啟用10231事件

透過設定10231診斷事件可以在匯出的時候讓Oracle忽略表損壞的塊，10231是Oracle的內部診斷事件，設定在全表掃描時跳過壞塊的資料塊，只匯出包含正確塊的資料，之後把表刪除，再把匯出的表資料匯入新表，從而修復該表。

1）   啟用10231診斷事件

SQL> alter system set events=’10231 trace name context forever,level 10’;

2）   禁用10231診斷事件：

SQL> alter system set events=’10231 trace name context forever,level 0’;

方法2：使用DBMS_REPAIR包標記損壞的塊。

可以使用DBMS_REPAIR包標記損壞的資料庫物件，這樣在對損壞的物件執行全表掃描的時候會跳過損壞的塊。語法如下：

SQL> exec dbms_repair.skip_corrupt_blocks(‘’,’tablename’);

EXP壞塊檢查有一定的侷限性，不會發現如下型別的壞塊：

ü   HWM（高水位線）以上的壞塊

ü   索引中存在的壞塊

ü   資料字典中存在的壞塊

l   Expdp工具

使用expdp工具不會給出壞塊的提示，只會將物件正確的資料匯出。