oracle block corrupt 壞塊

標籤：rdb   ora-00600   ada   fse   error   data-   basic   vsp   rom   

    整體上來講，oracle的壞塊能夠分為兩種情景：物理損壞和邏輯損壞。物理損壞是因為儲存等原因造成的，致使oracle在處理資料區塊時發現塊的checksum不一致。邏輯損壞多是因為oracle的bug或者記憶體錯誤引起，通過檢測資料區塊的checksum並不會發現什麼問題，可是在邏輯上這些塊已經發生了損壞。

oracle通過兩個參數來控制對物理損壞和邏輯損壞的檢測：

SQL> show parameter db_block_checkNAME     TYPE VALUE------------------------------------ ----------- ------------------------------db_block_checking     string FALSEdb_block_checksum     string TRUE

     db_block_checking 是當block發生不論什麼變化的時候進行邏輯上的完整性和正確性檢查。

該參數可以避免記憶體中資料區塊的損壞。

塊的檢查將對系統會有1%到10%的效能影響。取決於對db_block_checking參數的設定。頻繁的DML將使得塊檢查帶來很多其它的開銷。

在系統負荷同意的情形下建議設定為full。

該參數對SYSTEM資料表空間始終是處於“開啟”狀態。而無論該參數是否設定為OFF。以下是該參數的設定參考。

FALSE和TRUE是為了老版本號碼的相容。

        Property             Description

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

        Parameter type         String

        Syntax                         DB_BLOCK_CHECKING = { FALSE| OFF| LOW | MEDIUM | TRUE| FULL}  -->OFF(=FALSE),FULL(=TRUE)

        Defaultvalue              FALSE

        Modifiable                  ALTER SYSTEM

        Basic                          No

      這裡有一點須要注意，即僅僅有在對資料區塊發生改動時。db_block_checking才會發生作用。如

SQL> show parameter db_block_checkNAME     TYPE VALUE------------------------------------ ----------- ------------------------------db_block_checking     string FALSEdb_block_checksum     string TRUESQL> alter system flush buffer_cache;System altered.SQL> select * from scott.s2;//查詢時沒有問題T1   T2---------- --------------------51809   lllll51888   SC51574   PK_DEPT51573   DEPT1575EMP,  551576   PK_EMP51578   SALGRADE7 rows selected.SQL> update scott.s2 set t2=‘aaaa‘ where t1=‘51809‘;//改動也沒有問題1 row updated.SQL> commit;Commit complete.SQL> alter system flush buffer_cache;System altered.SQL> alter system set db_block_checking=true;System altered.SQL> select * from scott.s2;//查詢是沒有問題的T1   T2---------- --------------------51809   aaaa51888   SC51574   PK_DEPT51573   DEPT1575EMP,  551576   PK_EMP51578   SALGRADE7 rows selected.SQL> update scott.s2 set t2=‘bbbb‘ where t1 = ‘51809‘;//改動時觸發了邏輯檢測update scott.s2 set t2=‘bbbb‘ where t1 = ‘51809‘             *ERROR at line 1:ORA-00607: Internal error occurred while making a change to a data blockORA-00600: internal error code, arguments: [kddummy_blkchk], [5], [20], [6113],[], [], [], []SQL> select * from scott.s2;//發現邏輯錯誤後，oracle將塊標記為壞塊。此時資料區塊無法訪問了select * from scott.s2*ERROR at line 1:ORA-01578: ORACLE data block corrupted (file # 5, block # 20)ORA-01110: data file 5: ‘/home/app/oraten/oradata/oraten/tbs201.dbf‘

db_block_checksum 用於DBWn和direct loader資料區塊寫入到磁碟時。基於塊內的全部位元組計算得出一個校正值並將其寫入塊頭。在該參數設定為typical和full時，當讀入時候又一次計算校正和寫出時候的校正對照。假設不同則覺得是塊損壞。

假設設定為FULL模式，則基於update/delete應用程式語句層級的改變發生後，校正值會被又一次計算並寫入。同一時候對於日誌塊。在寫入之前。相同會生產校驗值並寫入到塊頭。

該參數主要是防止IO硬體和IO子系統的錯誤。假設設定為OFF則僅僅對系統資料表空間有效。

以下是該參數的設定參考。FALSE和TRUE是為了老版本號碼的相容。

        Property             Description

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

        Parameter type         String

        Syntax                         DB_BLOCK_CHECKSUM = { OFF| FALSE| TYPICAL | TRUE| FULL}  -->OFF(=FALSE),FULL(=TRUE)

        Defaultvalue              TYPICAL

       Modifiable                   ALTER SESSION,ALTER SYSTEM

        Basic                          No

對於效能上的差異而言，當設定兩個block參數設定為true時，將須要很多其它的CPU資源來產生校正值以及進行記憶體塊的驗證。

同一時候。該操作easy引起redo copy latch的持有時間添加和引起這個latch的競爭。

無論db_block_checking和db_block_checksum這兩個參數的值為何值，SYSTEM資料表空間都會進行做checking和checksum，能夠通過隱含參數_db_always_check_system_ts設定為FALSE，但為了SYSTEM資料表空間資料安全。不建議將這個隱含參數值設定為FALSE。

我們已經知道。oracle 將壞塊分為物理和邏輯損壞兩種，那麼當oracle發現物理或者邏輯損壞之後是怎樣標記資料區塊從而使之後的操作知道該塊是損壞塊的那？

對於物理損壞。oracle不會進行不論什麼的處理，在進行興許處理時oracle會又一次計算checksum，僅僅要發現checksum不一致則覺得該塊時物理損壞，並拋出01578錯誤。

對於邏輯損壞，當oracle第一次對資料區塊進行邏輯檢測時，會拋出ora 600等錯誤。並改動資料區塊中的標記位，當下次訪問該資料區塊時，oracle檢測標誌位。假設發現標誌位以置為邏輯損壞。則拋出ora 01578錯誤。當使用DBMS_REPAIR對壞塊進行改動時，假設時物理損壞不作不論什麼處理。假設時邏輯損壞，改動資料區塊的標誌位。

在資料區塊中存在兩個位置表示資料區塊為邏輯損壞（不標示物理損壞）,例如以下：

BBED> map /v File: /home/app/oraten/oradata/oraten/tbs201.dbf (5) Block: 20                                    Dba:0x01400014------------------------------------------------------------ KTB Data Block (Table/Cluster) struct kcbh, 20 bytes                      @0           ub1 type_kcbh                           @0           ub1 frmt_kcbh                           @1           ub1 spare1_kcbh                         @2           ub1 spare2_kcbh                         @3           ub4 rdba_kcbh                           @4           ub4 bas_kcbh                            @8           ub2 wrp_kcbh                            @12          <strong>ub1 seq_kcbh                            @14  </strong>        ub1 flg_kcbh                            @15          ub2 chkval_kcbh                         @16          ub2 spare3_kcbh                         @18       struct ktbbh, 96 bytes                     @20          ub1 ktbbhtyp                            @20          union ktbbhsid, 4 bytes                 @24          struct ktbbhcsc, 8 bytes                @28          b2 ktbbhict                             @36          ub1 ktbbhflg                            @38          ub1 ktbbhfsl                            @39          ub4 ktbbhfnx                            @40          struct ktbbhitl[3], 72 bytes            @44       struct kdbh, 14 bytes                      @124         ub1 kdbhflag                            @124         b1 kdbhntab                             @125         b2 kdbhnrow                             @126         sb2 kdbhfrre                            @128         sb2 kdbhfsbo                            @130         sb2 kdbhfseo                            @132         b2 kdbhavsp                             @134         b2 kdbhtosp                             @136      struct kdbt[1], 4 bytes                    @138         b2 kdbtoffs                             @138         b2 kdbtnrow                             @140      sb2 kdbr[7]                                @142      ub1 freespace[7905]                        @156      ub1 rowdata[127]                           @8061    <strong> ub4 tailchk                                @8188</strong>

BBED> set offset 14OFFSET         14BBED> dump /v count 12 File: /home/app/oraten/oradata/oraten/tbs201.dbf (5) Block: 20      Offsets:   14 to   25  Dba:0x01400014------------------------------------------------------- <strong>ff</strong>0425fe 00000100 0000fcca          l ..%......... <16 bytes per line>BBED> set offset 8188OFFSET         8188BBED> dump /v count 12 File: /home/app/oraten/oradata/oraten/tbs201.dbf (5) Block: 20      Offsets: 8188 to 8191  Dba:0x01400014------------------------------------------------------- <strong>ff</strong>060000                            l ....

這裡的ff即標示資料區塊位邏輯損壞塊，我們能夠將其手工改動位01 或者 02 從而取消邏輯損壞標示。

對於已經標示為邏輯損壞的資料區塊，dbv等工具的檢測結果例如以下：

Total Blocks Examined         : 1Total Blocks Processed (Data) : 1Total Blocks Failing   (Data) : 0Total Blocks Processed (Index): 0Total Blocks Failing   (Index): 0Total Blocks Empty            : 0Total Blocks Marked Corrupt   : 0Total Blocks Influx           : 0

而對於沒有標示的邏輯損壞，dbv等工具檢測結果例如以下：

Total Blocks Examined         : 1Total Blocks Processed (Data) : 1Total Blocks Failing   (Data) : 1Total Blocks Processed (Index): 0Total Blocks Failing   (Index): 0Total Blocks Empty            : 0Total Blocks Marked Corrupt   : 0Total Blocks Influx           : 0

對於物理損壞。dbv檢測結果例如以下

DBVERIFY - Verification completeTotal Blocks Examined         : 1Total Blocks Processed (Data) : 0Total Blocks Failing   (Data) : 0Total Blocks Processed (Index): 0Total Blocks Failing   (Index): 0Total Blocks Empty            : 0Total Blocks Marked Corrupt   : 1Total Blocks Influx           : 0

對於dbms_repair包，假設是物理損壞，則REPAIR_TABLE的marked_corrupt列始終為true。fix方法並不會發生作用。對於邏輯損壞，首先repair_table 的marked_corrupt列為false，fix方法修正後。marked_corrupt改動為true，此時資料區塊的標誌位已發生改動。

oracle block corrupt 壞塊