1.什麼是塊損壞：
所謂損壞的數據塊，是指塊沒有采用可識別的 Oracle 格式，或者其內容在內部不一致。通常情況下，損壞是由硬件故障或操作系統問題引起的。Oracle 數據庫將損壞的塊標識為“邏輯損壞”或“介質損壞”。如果是邏輯損壞，則是 Oracle 內部錯誤。Oracle 數據庫檢測到不一致之後，就將邏輯損壞的塊標記為損壞。如果是介質損壞，則是塊格式不正確；從磁盤讀取的塊不包含有意義的信息。
通過恢復塊，或者刪除包含損壞塊的數據庫對象（或同時采用這兩種方式），可以修復介質損壞的塊。如果介質損壞是由硬件故障引起的，則只有修復了硬件故障後，才能徹底解決問題。
只要對塊執行讀或寫操作，就會執行下列一致性檢查：
--塊版本
--高速緩存中的 DBA（數據塊地址）值與塊緩沖區中的 DBA 值比較的結果
--塊校驗和（如果啟用）
損壞的塊被標識為以下類別：
--介質損壞
--邏輯（或軟件）損壞
2.塊損壞故障現象：ORA-01578
ORA-01578 錯誤：“ORACLE data block corrupted (file # %s, block # %s)”：
--發現損壞的數據塊時生成此信息
--始終返回相對文件號和塊號
--返回到發出查詢的會話（該查詢在發現損壞時執行）
--顯示在 alert.log 文件中
一般情況下，ORA-01578 錯誤是由硬件問題引起的。如果 ORA-01578 錯誤始終返回相同的參數，則最可能的原因是塊介質損壞。
如果返回的參數每次都有變化，則可能存在硬件問題。應檢查內存和頁面空間，並檢查 I/O 子系統，以便查找有問題的控制器。
注：ORA-01578 會返回相對文件號，但隨之出現的 ORA-01110 錯誤會顯示絕對文件號。
3.如何處理損壞
--檢查預警日志和操作系統日志文件。
--使用可用的診斷工具，找出損壞的類型。
--多次運行檢查功能，確定錯誤是否持續存在。
--根據需要，從損壞的對象中恢復數據。
--解決硬件問題：
內存條、
磁盤控制器、
磁盤
--根據需要，從損壞的對象中恢復或還原數據。
始終嘗試確定錯誤是否持續出現。多次運行 ANALYZE 命令；如果可能，可執行關閉再啟動操作，然後再次嘗試早先發生故障的操作。查找是否有其它損壞。如果發現一個損壞的塊，則可能還存在其它損壞的塊。
硬件故障必須立即解決。遇到硬件問題時，應與供應商取得聯系，在檢查並修復了計算機後再繼續工作。此時應運行一次全面的硬件診斷會話。
硬件故障的類型可能會有很多種：
--I/O 硬件或固件故障
--操作系統
--I/O 或高速緩存問題
--內存或分頁問題
--磁盤修復實用程序
4.實時驗證塊完整性：DB_BLOCK_CHECKING ：
可通過將 DB_BLOCK_CHECKING 初始化參數設置為 TRUE 啟用數據庫塊檢查。只要修改了數據塊或索引塊，此項檢查就會檢查數據塊和索引塊的內部一致性。DB_BLOCK_CHECKING 是一個動態參數，可使用 ALTER SYSTEM SET 語句修改此參數。對於系統表空間，將始終啟用塊檢查。塊檢查通常會產生 1% 到 10% 的開銷，具體取決於工作量。正在執行的更新或插入操作越多，執行塊檢查的開銷就會越高。DB_BLOCK_CHECKING 有以下四個可能的值：
--OFF：除 SYSTEM 之外的所有表空間都不執行塊檢查。
--LOW：在內存中塊的內容發生更改之後（例如，在執行 UPDATE 或 INSERT 語句以及在執行磁盤上讀取後），執行基本的塊頭檢查。
--MEDIUM：執行所有 LOW 檢查， 對所有不是按索引組織的表塊執行語義塊檢查。
--FULL：執行所有 LOW 和 MEDIUM 檢查， 對索引塊執行語義檢查。
初始化參數 DB_BLOCK_CHECKING：
--在對每個塊執行自我一致性檢查時，控制檢查的處理程度
--可防止內存和數據損壞
--可使用 ALTER SESSION 命令或 ALTER SYSTEM DEFERRED 命令進行設置
5.塊介質恢復
大多數情況下，第一次遇到損壞時，數據庫會將塊標記為介質損壞，然後將其寫到磁盤上。在該塊得到恢復之前，不能對其執行任何後續讀取操作。只能對標記為損壞或者未通過損壞檢查的塊執行塊恢復。可使用 RMAN RECOVER...BLOCK 命令執行塊介質恢復。默認情況下，RMAN 會在閃回日志中搜索好的塊副本，然後在完全備份或 0 級增量備份中搜索塊。如果 RMAN 找到了好的副本，則會還原這些副本，並對塊執行介質恢復。塊介質恢復只能將重做日志用於介質恢復，不能使用增量備份。
V$DATABASE_BLOCK_CORRUPTION 視圖顯示由數據庫組件（如 RMAN 命令、ANALYZE、dbv、SQL 查詢等）標記為損壞的塊。對於以下類型的損壞此視圖會增加相應的行：
--物理/介質損壞：數據庫無法識別塊：校驗和無效、塊內容全部為零或者塊頭不完整。默認情況下，物理損壞檢查處於啟用狀態。
--邏輯損壞：塊的校驗和有效，塊頭和塊尾也匹配，但是內容不一致。塊介質恢復不能修復邏輯塊損壞。默認情況下，邏輯損壞檢查處於禁用狀態。通過指定 BACKUP、RESTORE、RECOVER 和 VALIDATE 命令的 CHECK LOGICAL 選項，可以啟用邏輯損壞檢查。
塊介質恢復：
--降低平均恢復時間 (MTTR)
--提高介質恢復期間的可用性
--恢復期間數據文件保持聯機狀態
--只有正在恢復的塊是不可訪問的
--使用 RMAN RECOVER...BLOCK 命令調用
--使用閃回日志以及完全備份或 0 級備份還原塊
--使用重做日志執行介質恢復
--V$DATABASE_BLOCK_CORRUPTION 視圖顯示標記為損壞的塊
6.塊介質恢復的先決條件
--目標數據庫必須處於 ARCHIVELOG 模式
--包含損壞塊的數據文件的備份必須是完全備份或 0 級備份。
--要使用代理副本，必須先將它們還原到非默認位置
--RMAN 只能使用歸檔的重做日志進行恢復
--要使用閃回日志，必須啟用閃回數據庫
以下先決條件適用於 RECOVER ... BLOCK 命令：
--目標數據庫必須以 ARCHIVELOG 模式運行，並且必須是打開的，或是使用當前控制文件裝載的。
--包含損壞塊的數據文件備份必須是完全備份或 0 級備份，不能是代理副本。如果只存在代理副本備份，則可將它們還原到磁盤上的非默認位置；在這種情況下，RMAN 會認為它們是數據文件副本，在塊介質恢復過程中會在其中搜索塊。
--RMAN 只能使用歸檔的重做日志進行恢復。RMAN 不能使用 1 級增量備份。塊介質恢復不能恢復丟失或無法訪問的歸檔重做日志，但有時可以恢復丟失的重做記錄。
--必須在目標數據庫上啟用閃回數據庫，這樣 RMAN 才能在閃回日志中搜索損壞塊的好副本。如果啟用了閃回事件記錄，並且此事件記錄包含損壞塊的較舊但未損壞的版本，則 RMAN 可以使用這些塊，因而可能會提高恢復的速度。
7.RECOVER...BLOCK 命令
--確定包含要進行恢復的塊的備份
--讀取備份並將請求的塊累積到內存緩沖區
--必要時，通過從備份中讀取歸檔日志來管理塊介質恢復會話
RECOVER DATAFILE 6 BLOCK 3; Recover a single block
RECOVER Recover multiple blocks
DATAFILE 2 BLOCK 43 in multiple data files
DATAFILE 2 BLOCK 79
DATAFILE 6 BLOCK 183;
RECOVER CORRUPTION LIST; Recover all blocks logged in V$DATABASE_BLOCK_CORRUPTION
恢復單個塊：
在進行塊恢復之前，必須確定損壞的塊。一般情況下，會在以下位置中報告塊損壞：
--LIST FAILURE、VALIDATE 或 BACKUP ...VALIDATE 命令的結果
--V$DATABASE_BLOCK_CORRUPTION 視圖
--標准輸出中的錯誤消息
--預警日志文件和用戶跟蹤文件（在 V$DIAG_INFO 視圖中標識）
--SQL ANALYZE TABLE 和 ANALYZE INDEX 命令的結果
--DBVERIFY 實用程序的結果
例如，可能會在用戶跟蹤文件中發現以下消息：
ORA-01578: ORACLE data block corrupted (file # 7, block # 3)
ORA-01110: data file 7: '/oracle/oradata/orcl/tools01.dbf'
ORA-01578: ORACLE data block corrupted (file # 2, block # 235)
ORA-01110: data file 2: '/oracle/oradata/orcl/undotbs01.dbf'
--確定了塊以後，在 RMAN 提示符下運行 RECOVER ...BLOCK 命令，指定損壞塊的文件號和塊編號。
RECOVER
DATAFILE 7 BLOCK 3
DATAFILE 2 BLOCK 235;
8.使用10231事件進行處理：
（塊損壞但沒有備份，沒辦法回復的情況下）
在sqlplus中執行如下命令：
ALTER SYSTEM SET EVENTS='10231 trace name context forever,level 10';
然後導出該表：
exp test/test file=t.dmp tables=t;
在數據庫中刪除該表
drop table t；
然後導入
imp test/test file=t.dmp tables=t;
最後關閉10231事件：
ALTER SYSTEM SET EVENTS='10231 trace name context off';
