oracle中一次dataguard壞塊的修複

客戶有個11g的active dataguard庫，mrp進程停了，看alertlog，可以看到有關ora-7445[kdxlin]的報錯：

cat alert*.log
....
Exception [type:SIGSEOV,Address not mapped to object] [ADDR:0xC] |PC：0x96504C7,kdxlin()+4153][flags: 0x0,count:1]
Errors in le /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/trace/partsm_pr18_21343.trc (incident=70353):
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
Incident details in: /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
Use ADRCI or Support Workbench to package the incident.
 
Exception [type: SIGSEGV, Address not mapped to object] [ADDR:0xC][PC:0x96504C7,kdxlin()+4153][flags:0XO,count:1]
Incidenl 70353 created, dump file/aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
ORA-07445: exception encountered: core dump (kdxlin()+4153) [SIGSEGV] [ADDR:0xC] |PC:0x96504C7][Address not mapped to object][]
...

cat /aabb/app/oracle/rdbms/diag/rdbms/rmydbsid/mydbsid/incident/incdir_70353/mydbsid_pr18_21343_i70353.trc
...
Error 607 in redo applicalion callback
Dump of change vector
Typ:2 CLS:1 APN:5 DBA0x2598d645 OBJ:3S3792 SCN:0x0960.99d2655e SEQ:1 OP:10.2 ENC:0 RBL:0
index redo(kdxlin):insert leaf row
KTB Redo
op:0x01 ver:0x01
compat bit:4(post-11) padding:1
op:F xid:0x0001.01a.010d8f34 uba:0x00dc8e3.6bf5.20
REDO: SINGLE/NONKEY/--
itl:3, sno:255, row size 23
insert key:(14):05 c4 02 4e 31 4f 07 78 74 0b 09 11 27 29
nonkey (length: 5):
fb: --H-FL-- lb:0x0 cc:1
(2).01 80
Block after image is corrupt:
buffer tsn: 5 rdba:0x2598d645(1024/630773317)
scn:0x960.99d10d33 seq:0x01 flg:0x04 tail:0x0d330601
frmt:0x02 chkval:0xa1ae type:0x06=trans data
Hex dump of currupt header 3=CHKVAL
...
從trace中，我們可以看到這個dataguard上有壞塊，壞塊是在（file#5, block# 630773319）中。

先說一下對於坏塊的處理：

1. 主庫：

■ 如果是在索引塊上，重建索引
■ 如果是在資料區塊上，且存在備份，用備份做blockrecover
■ 如果是在空塊上，建一個表，填充這個塊，填充時就會自動格式化對應的壞塊。可以參考我以前寫過的這裡。
■ 如果是11gADG，物理壞塊將觸發ABMR(Automatic Block Recover)，oracle將通過ABMR自動修複壞塊。
■ 如果是邏輯壞塊，且配置了DB_LOST_WRITE_PROTECT+DB_BLOCK_CHEKING，將自動修複。(參考Doc ID 1302539.1)
■ 如果ABMR和lost write protection沒有觸發，將dataguard的檔案rman備份，再restore到主庫，再recover。

2.備庫：

■ 首先考慮ABMR和DB_LOST_WRITE_PROTECT，是否自動修複
■ 利用備份，做blockrecover
■ 將主庫的檔案rman備份，再restore到主庫，再recover。

由於是邏輯壞塊，ABMR沒有被觸發。那麼我們常規的做法是上面的第2和第3，可是，問題來了。

嘗試第3條，將主庫的檔案拷貝到備庫，發現這個發生壞塊的庫是在上海，根據兩地三中心的架構，這個是個遠程dataguard。拷貝檔案和傳輸檔案需要比較多的時間。那麼究竟需要多少時間？我發現這個壞塊（file#5, block# 630773319）是在一個bigfile tablespace上，而這個tablespace的datafile，已經到達了7T的大小!orz 給跪了……

嘗試第2條，發現主庫和local dataguard都在深圳，這個庫在上海，而備份軟體是在深圳的dataguard上備份的。遠端機器上沒有agent，網路也沒有通。再次跪。

好了，傳統的方法都不行，開始思考非常規的方法，和同事進行頭腦風暴了：

1. 既然是備庫索引上的壞塊，那麼我主庫重建索引，備庫也就重建索引了。
>>可是現在mrp停在前面的一步，在沒有過去這個點之前，是一直卡在這裡，不會apply後續的日子，也就不會重複主庫上的重建索引的操作。

2.既然已經找到對應的壞塊，但是有不能進行blockrecover，那麼將好塊dd出來，再dd到壞塊中。
>>由於使用是asm，要做這種操作的話，需要將資料檔案先cp到檔案系統，再在檔案系統上做dd，在將塊傳輸到上海。可惜7T的asm檔案無法cp出來。

3.將這個壞塊dd成物理壞塊，利用ABMR恢複。
>>做dd也是有同2的問題，7T的asm檔案無法cp出來。

4. 用bbed來修改，也涉及到cp 7T的asm檔案。

這個時候，客戶提出了一種解決方案，用增量備份，然後在做recover datafile 5 noredo;

這種方案之前都沒有試過，我心裡也沒底，所以我在我自己的測試機器上測試了這種方案，發現還是無法修複壞塊。但是客戶堅持想嘗試一下，沒想到，成功了！

沒想到增量備份+recover datafile noredo，這種追dataguard缺少歸檔日誌的方式，也可以修複壞塊！（增量備份的大小隻有幾個G，傳輸很方便。）

把這個好訊息告訴了同事，同事指出，這個方法其實存在偶然性，因為這種方式，要求在mrp停掉的那個scn之後，壞塊對應的主庫上的塊，已經被修改過了。這樣才能包含在主庫增量備份中。

一語驚醒夢中人，我在測試機上測試失敗的原因，正是我在主庫上沒有修改對應的記錄，即備庫壞塊對應在主庫上的塊，沒有被修改過。所以也就不會包含在增量備份中了。

所以，多了這種方法之後，我們又可以頭腦風暴，如果後續還發生這種情況，怎麼樣使得主庫沒有修改的塊，發生變動……如update對應的塊，如rebuild index online……

另外，再說一下：珍惜生命，遠離bigfile tablespace。