如何處理Oracle中的壞塊問題

2024-08-29 13:50:18

字體：大中小

來源：轉載

供稿：網友

　　一：什么是數據庫的壞塊

    首先我們來大概看一下數據庫塊的格式和結構

    數據庫的數據塊有固定的格式和結構，分三層：cache layer，transaction layer，data layer。在我們對數據塊進行讀取寫入操作的時候，數據庫會對要讀寫的數據塊做一致性的檢查，其中包括：數據塊的類型、數據塊的地址信息、數據塊的SCN號以及數據塊的頭部和尾部。假如發現其中有不一致的信息，那數據庫就會標記這個數據塊為壞塊了。數據庫的壞塊分為兩種，邏輯壞塊和物理壞塊。

    二：壞塊對數據庫產生的影響

    假如數據庫出現壞塊，數據庫的告警日志文件里面會存在有如下的一些報錯信息：Ora-1578以及Ora-600 and trace file in bdump Directory，其中Ora-600錯誤的第一個參數值的范圍是[2000]-[8000]，不同的值代表著數據塊的不同的層出現問題，具體的如下表所示：
    Range block layer
    Cache layer 2000 – 4000
    Transaction layer 4000 – 6000
    Data layer 6000 - 8000
    壞塊產生影響的對象可能是數據字典表、回滾段表、臨時段、用戶數據表和索引等。不同的對象產生壞塊后的處理方法不盡相同。

    三：壞塊產生的原因

    Oracle調用標準C的系統函數，對數據塊進行讀寫操作，因此，壞塊是有可能由以下幾種原因產生：
    硬件的I/O錯誤
    操作系統的I/O錯誤或緩沖問題
    內存或paging問題
    磁盤修復工具
    一個數據文件的一部分正在被覆蓋
    Oracle試圖訪問一個未被格式化的系統塊失敗
    數據文件部分溢出
    Oracle或者操作系統的bug 　　四：壞塊的處理方法

    1．先收集相應的關于壞快的信息，從AlertSID.log文件或者從trace文件中查找，找到例如以下的一些信息：
    Ora-1578 file# (RFN) block#
    Ora-1110 file# (AFN) block#
    Ora-600 file# (AFN) block#
    其中RFN表示的是relative_fno
    AFN表示的是file_id    Select file_name,tablespace_name,file_id “AFN”,relative_fno “RFN”    From dba_data_files;    Select file_name,tablespace_name,file_id, relative_fno“RFN”    From dba_temp_files;    2．確定存在壞塊的對象是什么：SELECT tablespace_name, segment_type, owner, segment_name, partition_name FROM dba_extents WHERE file_id = <AFN> and <BL> between block_id AND block_id + blocks – 1；    通過上面這個查詢語句就可以查出當前存在壞塊的對象是什么，是什么類型的對象。需要注重的是假如是temp文件中出現壞塊，是沒有記錄返回的。

    3．根據2中查詢出來的對象類型，確定相應的處理方法
    出現壞塊的常見對象有：
    Sys用戶下的對象
    回滾段
    臨時段
    索引或者分區索引
    表
    常用的處理方法有：
    恢復數據文件
    只恢復壞的block（9i以上版本可用）
    通過ROWID RANGE SCAN 保存數據
    使用DBMS_REPAIR
    使用EVENT　　4．具體處理方法的介紹

    恢復數據文件方法：
    假如數據庫是歸檔方式下，并且有完整的物理備份，就可以使用此方法來恢復。
    步驟如下：

    1) 先offline受影響的數據文件，執行以下的語句：
    ALTER DATABASE DATAFILE 'name_file' OFFLINE；

    2) 保留有壞塊的數據文件，然后拷貝備份的數據文件。假如恢復的數據文件要求路徑不同，執行以下的語句：
    ALTER DATABASE RENAME FILE 'old_name' TO 'new_name';

    3) 恢復數據文件，執行以下語句：
    RECOVER DATAFILE 'name_of_file';

    4) Online恢復后的數據文件，執行以下的語句：
    ALTER DATABASE DATAFILE 'name_of_file' ONLINE;
    只恢復壞的block（9i以上版本可用）
    使用這種方法要求數據庫版本是9.2.0以上，要求配置了Rman的catalog數據庫，數據庫為歸檔方式，并且有完整的物理備份。
    步驟如下：
    使用RMAN的BLOCKRECOVER命令：
    Rman>run{blockrecover datafile 5 block 11,16;}
    也可以強制使用某個SCN號之前的備份，恢復數據塊。
    Rman>run{blockrecover datafile 5 block 11,16 restore until sequence 8505;}
    通過ROWID RANGE SCAN 保存數據

    1) 先取得壞塊中ROW ID的最小值，執行以下的語句：
    SELECT dbms_rowid.rowid_create(1,,,,0) from DUAL;

    2）取得壞塊中的ROW ID的最大值，執行以下的語句：
    SELECT dbms_rowid.rowid_create(1,,,+1,0) from DUAL;

    3）建立一個臨時表存儲那些沒有壞塊的數據，執行以下的語句：
    CREATE TABLE salvage_table AS SELECT * FROM corrupt_tab Where 1=2;

    4）保存那些不存在壞塊的數據到臨時表中，執行以下的語句：
    INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A WHERE rowid < ''；
    INSERT INTO salvage_table SELECT /*+ ROWID(A) */ * FROM A WHERE rowid >= '‘;

    5) 根據臨時表中的數據重建表，重建表上的索引，限制。
    使用10231診斷事件，在做全表掃描的時候跳過壞塊
    可以在session級別設定：
    ALTER SESSION SET EVENTS '10231 TRACE NAME CONTEXT FOREVER, LEVEL 10';
    也可以在數據庫級別上設定，在初始化參數中加入：event="10231 trace name context forever, level 10" ，然后重啟數據庫。
    然后從存在壞塊的表中取出不存在壞塊的數據，執行以下的語句：
    CREATE TABLE salvage_emp AS SELECT * FROM corrupt_table;
    最后rename生成的corrupt_table為原來表的名字，并重建表上的索引和限制。
    使用dbms_repair包進行恢復
    使用dbms_repair標記有壞塊的表，在做全表掃描的時候跳過壞塊，執行以下的語句：
    Execute DBMS_REPAIR.SKip_CORRUPT_BLOCKS('','');
    然后使用eXP工具或者createtable as select的方法取出沒有壞塊數據，然后重建表，表上的索引和限制。　　五：壞塊的預先發現的方法

    1．假如要檢測數據庫中所有的表，可以利用exp工具導出整個數據庫可以檢測壞塊。不過這個工具有一些缺陷，對以下情況的壞塊是檢測不出來的：
    HWM以上的壞塊是不會發現的
    索引中存在的壞塊是不會發現的
    數據字典中的壞塊是不會發現的
    2．假如只是對數據庫中比較重要的表進行壞塊檢查，可以使用ANALYZE TABLE tablename VALIDATE STRUCTURE CASCADE 的方法來檢測壞塊，它執行壞塊的檢查，但是不會標記壞塊為corrupt，檢測的結果保存在USER_DUMP_DEST目錄下的用戶trace文件中。
    3．使用Oracle的專門工具dbv來檢查壞塊，具體的語法如下：
    要害字說明 (默認)
    ----------------------------------------------------
    FILE 要驗證的文件 (無)
    START 起始塊 (文件的第一個塊)
    END 結束塊 (文件的最后一個塊)
    BLOCKSIZE 邏輯塊大小 (2048)
    LOGFILE 輸出日志 (無)
    FEEDBACK 顯示進度 (0)
    PARFILE 參數文件 (無)
    USERID 用戶名/口令 (無)
    SEGMENT_ID 段 ID (tsn.relfile.block) (無)
    例如：
    Dbv file=system01.dbf blocksize=8192
    DBVERIFY: Release 9.2.0.5.0 - PRoduction on 星期六 11月 27 15:29:13 2004
    Copyright (c) 1982, 2002, Oracle Corporation. All rights reserved.
    DBVERIFY - 驗證正在開始 : FILE = system01.dbf
    DBVERIFY - 驗證完成
    檢查的頁總數：32000
    處理的頁總數（數據）：13261
    失敗的頁總數（數據）：0
    處理的頁總數（索引）：2184
    失敗的頁總數（索引）：0
    處理的頁總數（其它）：1369
    處理的總頁數 (段) : 0
    失敗的總頁數 (段) : 0
    空的頁總數：15186
    標記為損壞的總頁數：0
    匯入的頁總數：0
    注：因為dbv要求file后面跟的必須是一個文件擴展名，所以假如用裸設備存儲的，就必須使用ln鏈接裸設備到一個文件，然后再用dbv對這個鏈接文件進行檢查。

上一篇：oracle使用命令行導入導出方案

下一篇：[Oracle]減少臨時表使用空間的幾種方法