今天碰到了一個dataguard在10gR2的bug,不管怎麼樣確實是在特定的時間做了特定的操作結果碰到了特定的問題。
這個問題是在10gR2的版本10.2.0.4.0的一個庫中出現的，在做巡檢的時候發現表空間使用率已經很高了，就準備加一些資料檔案把這個問題給修復了，按理說這也是一個常規操作，沒有什麼可圈圈點點的地方。
但是新增完資料檔案之後，過了一會，就收到報警說備庫出了點問題，自己還納悶到底是什麼原因導致的，帶著疑問使用dgmgrl來檢視了一下。
DGMGRL> show configuration;
Configuration
Name: test
Enabled: YES
Protection Mode: MaxPerformance
Fast-Start Failover: DISABLED
Databases:
test - Primary database
stest4 - Physical standby database
stest2 - Physical standby database
Current status for "test":
Warning: ORA-16607: one or more databases have failed

透過這個，確實發現備庫出了些問題，趕快連線到備庫中，結果檢視資料日誌就發現原來MRP程式給停掉了。
Fri Sep 11 17:58:53 2015
Errors in file /U01/app/oracle/admin/test/bdump/test_mrp0_10953.trc:
ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
Errors with log /U01/app/oracle/flash_recovery_area/STEST4/archivelog/2015_09_11/o1_mf_1_7414_bz598mqc_.arc
MRP0: Background Media Recovery terminated with error 600
Fri Sep 11 17:58:55 2015
Errors in file /U01/app/oracle/admin/test/bdump/test_mrp0_10953.trc:
ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []
Fri Sep 11 17:59:04 2015
Some recovered datafiles maybe left media fuzzy
Media recovery may continue but open resetlogs may fail
Fri Sep 11 17:59:04 2015

看到這個錯誤，發現問題似乎還是有些奇怪，因為關聯的ora錯誤是ora-600
帶著這個疑問，首先想到的就是自己之前碰到過MRP無法啟動的問題，dataguard中MRP無法啟動的問題分析和解決
感興趣可以參考這個連結http://blog.itpub.net/23718752/viewspace-1715472/
結果自己按照當時的問題思路也進行相似的分析，結果還真發現了問題。
使用下面的語句檢視資料檔案。
在備庫檢視：
select file#,df.name,df.ts#,ts.name,df.RFILE# from v$datafile df,v$tablespace ts
where df.ts#=ts.ts#;
FILE# NAME TS# NAME
---------- ------------------------------------------------------------ ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 9 TEST_NEW_DATA
主庫檢視

FILE# NAME TS# NAME
---------- ------------------------------------------------------------ ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 10 TEST_NEW_INDEX
透過這個可以發現表空間的資料檔案在兩個庫中不一致。
這個時候聯絡起來ora600其實在錯誤裡面已經暗示出了21的含義

ORA-00600: internal error code, arguments: [3689], [21], [], [], [], [], [], []

這個時候自己就恍然大悟了，自己在給表空間TEST_NEW_DATA新增資料檔案的時候，不小心新增成了test_new_index04.dbf，結果建立好之後發現了這個問題，
就使用alter tablespace test_new_data drop datafile 'xxxxx'的方式刪除了，然後又建立了一個新的資料檔案test_new_data04.dbf
這麼一個操作也沒有什麼非議之處，但是在10gR2 10.2.0.4.0裡就是不行，因為有一個bug
Bug 5623467 - Corrupt redo from ALTER TABLESPACE DROP DATAFILE (文件 ID 5623467.8)

這個bug，oracle也沒有給出其它可行的意見，除了升級打補丁外，建議就是不要使用drop datafile的命令，但是我已經執行了，你說怎麼辦，只能重建備庫了。
當然在重建備庫這個繁重的工作之外我還想做一些嘗試。
既然資料字典中不同步，對於drop的操作不支援，我就直接使用alter database datafile ‘xxxxxx' offline drop來搞定這個問題，上次的MRP的問題在11g中就可以這麼解決。
SQL> alter database datafile '/U01/app/oracle/oradata/test/test_new_index04.dbf' offline drop;
Database altered.

命令執行成功了，但是檢視datafile還是沒有發生變化。

FILE# NAME TS# NAME
---------- ------------------------------------------------------------ ---------- --------------------
20 /U01/app/oracle/oradata/test/test_new_data04.dbf 9 TEST_NEW_DATA
21 /U01/app/oracle/oradata/test/test_new_index04.dbf 9 TEST_NEW_DATA
再次嘗試recover managed standby database disconnect from session發現問題依舊，還是ora-600的錯誤。
這個時候想把database 啟動到read only時也出問題。
SQL> alter database open read only;
alter database open read only
*
ERROR at line 1:
ORA-16004: backup database requires recovery
ORA-01196: file 1 is inconsistent due to a failed media recovery session
ORA-01110: data file 1: '/U01/app/oracle/oradata/test/system01.dbf'

所以沒有辦法了，重建備庫了，真是讓人無奈的選擇。

由drop datafile導致的oracle bug

相關文章