資料庫壞塊典型案例擴充

1 、 物理壞塊

物理壞塊指的是塊格式本身已經損壞，塊內的資料沒有任何意義。物理壞塊一般是由於記憶體問題、 OS 問題、 I/O 子系統問題或硬體引起的，邏輯壞塊一般是由 Oracle Bug 等原因引起的。物理塊損壞也可以稱為介質塊損壞（ Media Corrupt Block ）。物理壞塊可以分為以下幾類：

（1）  壞頭（ Bad header ）：資料塊頭（ Cache Header ）被無效值損壞

（2）  塊有裂縫 / 不完整（ Fractured/Incompleted Block ）：資料塊頭和塊尾不匹配，其 trace 檔案內容如下所示：

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

Fractured block found during buffer read

Data in bad block -

type: 6 format: 2 rdba: 0x0380e573

last change scn: 0x0288.8e5a2f78 seq: 0x1 flg: 0x04

consistency value in tail: 0x00780601

check value in block header: 0x8739, computed block checksum: 0x2f00

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380e573 (file 14, block 58739) found same corrupted data

（3）  塊的塊校驗和（ checksum ）無效，其 trace 內容如下所示：

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

Bad check value found during buffer read

Data in bad block -

type: 6 format: 2 rdba: 0x0380a58f

last change scn: 0x0288.7784c5ee seq: 0x1 flg: 0x06

consistency value in tail: 0xc5ee0601

check value in block header: 0x68a7, computed block checksum: 0x2f00

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

Reread of rdba: 0x0380a58f (file 14, block 42383) found same corrupted data

（4）  塊的位置錯誤（ Block Misplaced ）：檢驗和正確，但是正在被讀取的資料塊的內容屬於另外一個塊

Corrupt block relative dba: 0x0d805a89 (file 54, block 23177)

Bad header found during buffer read

Data in bad block -

type: 6 format: 2 rdba: 0x0d805b08 ----> Block is different than expected 0x0d805a89

last change scn: 0x0692.86dc08e3 seq: 0x1 flg: 0x04

consistency value in tail: 0x08e30601

check value in block header: 0x2a6e, computed block checksum: 0x0

spare1: 0x0, spare2: 0x0, spare3: 0x0

***

（5）  歸零的塊（ Zeroed out blocks ）（ Note 1545366.1 ）

Corrupt block relative dba: <rdba> (file <file#>, block <block#>)

Completely zero block found during buffer read

Reading datafile 'datafile' for corruption at rdba: <rdba> (file <file#>, block <block#>)

Reread (file <file#>, block <block#>) found same corrupt data (no logical check)

 

2、  邏輯壞塊

邏輯壞塊指的是塊內的資料在邏輯上存在問題，比如說索引塊的索引值沒有按順序排列導致的邏輯壞塊。邏輯壞塊通常包含一個正確的 checksum 和結構，但是塊頭以下的部分（塊的內容）被損壞，可能引起不同的 ORA-600 錯誤。邏輯損壞詳細的損壞資訊通常不列印在 alert 告警日誌中，但是 DBV 將報告邏輯損壞的塊。

3、  壞塊校驗

3.1 DBVERIFY （ D BV ）

dbv 工具不能驗證聯機 Redo 日誌、歸檔日誌、控制檔案和 R MAN 備份集，只能用於資料檔案的塊驗證。 D BV 有兩種命令列介面，一是驗證資料檔案的資料庫，二是驗證段（在驗證段時需要查詢的檢視包括： S YS.SYS_DBA_SEG 和 S YS.SYS_USER_SEGS ）。

DBV 要求 file 引數後面跟的必須是一個包含副檔名的檔案，所以如果資料庫使用裸裝置作為儲存方式，那麼就必須使用 ln 命令連線裸裝置一個帶副檔名的檔案，然後使用 D BV 工具透過對連結檔案的驗證實現對裸裝置資料檔案的驗證。如果是驗證儲存在 A SM 中的資料檔案，那麼需要指定使用者名稱和密碼，如果不指定使用者名稱和密碼，那麼將收到 D BV-00008:USERID must   bu  SPECIFIED FOR OSM files 的報錯。

（ 1 ） F S 中： dbv   file= /oradata/test01.dbf blocksize=8192

（ 2 ） A SM 中： dbv file=+DATA/orcl/datafile/user.dbf userid=sys/mc

（ 3 ）驗證段，其中 segment _id 引數格式為：表空間 I D ，段頭所在資料檔案號，段頭資料塊號：

select tablespace_id,header_file,header_block from

sys.sys_dba_segs where owner='MC' and segment_name='TAB1'

 

dbv userid=sys/mc segment_id=36.12.130

 

3.2 ANALYZE

A nalyze 命令透過分析資料庫物件，為最佳化器收集資料庫物件的統計資訊，以便最佳化器生成準確的執行計劃。同時，他也能檢查某個表或索引是否存在損壞的情況。 A NALYZE 執行壞塊檢查，但是不會標記壞塊為 C ORRUPT ，檢測結果儲存在 U SER_DUMP _ DEST 目錄下的使用者 T RACE 檔案中。

ANALYZE TABLE/INDEX  XXX VALIDATE STRUCTURE;

 

3.3 EXP

對於包含壞塊的表執行匯出操作，會收到相關的錯誤資訊（ O RA-01578 ）。 E xp 壞塊檢查不會發現的壞塊型別包括： H WM （高水位線）以上的壞塊、索引中存在的壞塊、資料字典中存在的壞塊。對於這種情況，在非歸檔模式無法透過塊恢復修復塊的情況下，有如下兩種處理方法：

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

-- （ 1 ）啟用 1 0231 診斷事件

S QL> alter system set events='10231 trace name context forever,level 10';

- - （ 2 ）禁用 1 0231 診斷事件

S QL> alter  system set events='10231 trace name context forever,level 0';

方法 2 ：使用 D BMS_REPAIR 包標記損壞的塊。可以使用 D BMS_REPAIR 包標記損壞的資料庫物件，這樣 Oracle 在對損壞的物件執行全表掃描的時候會跳過損壞的塊。

SQL> exec dbms_repair.skip_corrupt_blocks(user,'table name ');

3.4 RMAN

RMAN 可以檢查塊是否被損壞，如果備份資料資料庫中包含有壞塊，那麼將會收到錯誤。

RMAN> backup validate datafile 6;

RMAN> backup validate database;

RMAN> backup validate check logical database archivelog all;

 

4、  查詢壞塊對應的物件

-- 確定壞塊對應的物件

SELECT TABLESPACE_NAME,

       SEGMENT_TYPE,

       OWNER,

       SEGMENT_NAME,

       PARTITION_NAME

FROM   DBA_EXTENTS

WHERE  FILE_ID = &FILE_ID

AND    &BLOCK_ID BETWEEN BLOCK_ID AND BLOCK_ID + BLOCKS - 1;

 

SEGMENT_TYPE       OWNER                          SEGMENT_NAME

------------------ ----------------- ------------------------------------

INDEX              LC1019999                      PK_ZJTEMPMXCXHJ19291