[[196780]]

一、問題癥狀：

1. Rman 備份失敗，顯示 ORA-19566 錯誤，且被報告的壞塊不屬于任何對象

2. Dbverify 顯示存在壞塊

3. 壞塊不屬于任何對象

二、原因分析：

在重新使用和重新格式化壞塊之前，RMAN 和 DBV 仍會一直報告壞塊。

三、解決方案：

解決此類問題的一個可能的方法如下。請注意，它不能保證問題解決，但它已知解決了幾種案例的問題。如果在某個數據文件中報告有很多塊損壞，請在第六步提示輸入 blocknumber 中輸入已經報告的***的壞塊號碼。

當一個對象被重新創建，已經分配給它(甚至是損壞的塊)的塊將變成空閑空間(free space)。他們在那里等待重新分配到一個需要額外空間的對象。一旦它們被重新分配到用于一個對象上新的extent，只有當任何DML操作使用到這些塊(即使損壞的塊，處在空閑空間，現在需要被分配)，他們將在DML操作更改、使用這些塊之前，被重新格式化掉。

需要注意的是extent的簡單的分配不格式化塊。第7步分配的extent和第8步執行DML操作，使用在第七步中分配的塊，這樣的壞塊才被重用和格式化。

在本文檔中，我們嘗試手動重新格式化壞塊。

第 1 步 - 確定損壞的數據文件

損壞可以被報告在應用層，如DBV和RMAN，或alert.log。

例如，可以在您的RMAN備份過程中獲得以下信息：

RMAN-03009: failure of backup command on nm4501 channel at 04/29/2005 09:44:41

ORA-19566: exceeded limit of 0 corrupt blocks for file E:\xxxx\test.ORA.

壞塊位于文件 E:\xxxx\test.ORA 中。

第 2 步 - 在受影響的數據文件上運行 DBV/Rman 驗證并檢查壞塊

在報告壞塊的數據文件上運行 dbverify。

# dbv userid={system/password} file={full path filename} logfile={output filename} 

第 3 步 - 檢查塊是否是某個對象的一部分 - 適用于損壞的塊號小的情況

查詢 dba_extents，確認壞塊是否屬于任何對象。

SQL> select segment_name, segment_type, owner 
       from dba_extents 
      where file_id = <Absolute file number> 
        and <corrupted block number> between block_id 
            and block_id + blocks -1;  

如果塊不屬于任何對象，查詢dba_free_space 確認壞塊是否屬于數據文件的可用空間。

SQL> Select * from dba_free_space where file_id= <Absolute file number> 
     and <corrupted block number> between block_id and block_id + blocks -1;  

第 4 步 - 查找受影響的塊并驗證其是否屬于任何段的一種比較好的方法是使用 RMAN，這種方法既好用又便捷。

如果在第 2 步中已經運行了 rman 驗證，請直接轉到下面給出的 sqlplus 腳本，以確認對象。

$ rman target / nocatalog 
or 
$ rman target sys/ nocatalog 
 
 
run { 
allocate channel d1 type disk; 
allocate channel d2 type disk; 
---------------------------------------------------------------------- 
--  multiple channels may be allocated for parallelizing purposes 
--  depends: RMAN - Min ( MAXOPENFILES , FILESPERSET )  
--  Defaults: MAXOPENFILES =8, FILESPERSET =64  
---------------------------------------------------------------------- 
allocate channel dn type disk; 
backup check logical validate database; 

注意：如果RDBMS是小于11g并且處于非歸檔模式下，則數據庫必須處于 mounted 模式

*** 在進行進一步操作之前，*必須*運行并完成 RMAN 命令“backup check logical validate database”。

*** 此命令完成(基于文件)后將會填充“v$database_block_corruption”視圖。

*** 如果未完成，在接下來的步驟中您就有可能得到無效/不完整的信息。

第 5 步 - 以非 SYS 或 SYSTEM(用戶)的用戶身份創建一個虛擬表

SQL> connect scott/password 

在包含出現壞塊的數據文件的表空間中創建虛擬表，并使用 nologging 選項，以防止生成 redo記錄：

SQL> create table s ( 
       n number, 
       c varchar2(4000) 
     ) nologging tablespace <tablespace name having the corrupt block> ;   

不同的存儲參數可以被用來適應特定的環境。

我們使用 PCTFREE 99以加快該塊的格式化

確認表是被創建在正確的表空間中，通過查詢 user_segments：

QL> select segment_name,tablespace_name from user_segments 
      where segment_name='S' ;  

請注意，在11gR2中，由于延遲段創建概念，從上面提到的 user_segments 查詢可能不會報告。在這種情況下，查詢 USER_TABLES

SQL> select segment_name,tablespace_name from user_tables where segment_name='S' ; 

第 6 步 - 在虛擬表上創建觸發器，一旦重新使用壞塊，該觸發器便會引發異常

以 sysdba 身份連接，并創建以下觸發器：

請注意，在出現文件號提示時，輸入相關文件號(v$datafile 中的 rfile# 值)

CREATE OR REPLACE TRIGGER corrupt_trigger  
  AFTER INSERT ON scott.s  
  REFERENCING OLD AS p_old NEW AS new_p  
  FOR EACH ROW  
DECLARE  
  corrupt EXCEPTION;  
BEGIN  
  IF (dbms_rowid.rowid_block_number(:new_p.rowid)=&blocknumber) 
 and (dbms_rowid.rowid_relative_fno(:new_p.rowid)=&filenumber) THEN  
     RAISE corrupt;  
  END IF;  
EXCEPTION  
  WHEN corrupt THEN  
     RAISE_APPLICATION_ERROR(-20000, 'Corrupt block has been formatted');  
END;  
/  

出現塊編號提示時，輸入壞塊的塊編號。

出現文件號提示時，輸入損壞的數據文件的相關文件號(v$datafile 中的 rfile# 值)。

第 7 步 - 為受影響的數據文件中的表分配空間。

請注意：

1)如果這是一個ASSM表空間，你可能需要重復此步驟數次。也就是說，創建多個表和分配多個 extent。

并周期性地查看 dba_extents，以確保空閑空間現在分配給一個虛擬表。

這是因為ASSM將自動確定下一個 extent 的大小

2)建議確保數據文件 AUTOEXTEND 置為 OFF，以防止其增長。

首先通過查詢 dba_free_space 查找 extent 大小

SQL> Select BYTES from dba_free_space where file_id=<file no> and <corrupt block no> between block_id and block_id + blocks -1; 
 
BYTES 
---------------- ---------- ---------- ---------- ---------- ------------ 
 65536  

在本例中，它的大小是 64K。因此，按照以下方法分配 extent：

SQL> alter table scott.s 
 
allocate extent (DATAFILE 'E:\xxxx\test.ORA' SIZE 64K);  

如果在這個數據文件中有多個64K的空閑 extent，則可能需要使用這個循環：

BEGIN 
for i in 1..1000000 loop 
EXECUTE IMMEDIATE 'alter table scott.s allocate extent (DATAFILE '||'''E:\xxxx\test.ORA''' ||'SIZE 64K) '; 
end loop; 
end ; 
/  

繼續分配空間直到壞塊成為 scott.s 的一部分 — 使用以下查詢進行檢查：

SQL> select segment_name, segment_type, owner 
       from dba_extents  
      where file_id = <Absolute file number> 
        and <corrupt block number> between block_id  
            and block_id + blocks -1 ;  

第 8 步 - 向虛擬表中插入數據以格式化塊

示例代碼(取決于表空間的大小，循環的次數可能發生變化)：

BEGIN  
FOR i IN 1..1000000000 LOOP  
INSERT /*+ APPEND */ INTO scott.s select i, lpad('REFORMAT',3092, 'R') from dual;  
commit ;  
END LOOP;  
END;  

或者

BEGIN 
  FOR i IN 1..1000000000 LOOP 
    INSERT INTO scott.s VALUES(i,'x'); 
  END LOOP; 
END; 
/  

或使用以下包含 2 個循環的代碼：

Begin 
  FOR i IN 1..1000000000 loop 
    for j IN 1..1000 loop 
      Insert into scott.s VALUES(i,'x'); 
    end loop; 
    commit; 
  END LOOP; 
END;   

每向表中插入一行就會觸發觸發器，且一旦向壞塊中插入***行數據，就會產成 ORA-20000 異常。

第 9 步 - 通過運行 DBV 和 Rman 備份確定數據文件中的壞塊情況

運行 dbverify 或 RMAN 在損壞的數據文件(或整個數據庫)上再次驗證。它不會顯示塊損壞。

確保你做兩次手動日志切換或檢查點，使得在內存中的信息寫入到磁盤。

RMAN 備份不會報告此塊上的任何錯誤。

運行真實的備份操作之前，你可以在數據文件上重新運行 RMAN validate 命令，并檢查 v$database_block_corruption 不再顯示塊被標記為損壞。

對于數據庫版本 <=10gR2

Rman> Backup validate check logical datafile <fileno>,<fileno> ; 

對于數據庫版本>=11gR1

Rman> Backup validate check logical datafile <fileno> ; 

或

Rman> validate datafile <fileno> block <blockno reported corrupt>, <blockno reported corrupt> ; 

一旦完成

SQL> SELECT * FROM V $ DATABASE_BLOCK_CORRUPTION; 

第 10 步 - 刪除第 4 步中創建的虛擬表

SQL> DROP TABLE scott.s ; 

如果版本為 10gr1 及以上，同時使用purge選項以清空回收站

第 11 步 – 執行手動日志切換和檢查點

執行兩次日志切換和檢查點，以便將在內存中格式化的塊寫入到磁盤并使 dbverify 不再報告錯誤

SQL>Alter system switch logfile ; --> Do this couple of time 
 
SQL>Alter system checkpoint ;  

第 12 步 - 刪除第 6 步中創建的觸發器

SQL> DROP triggercorrupt_trigger ;