資料庫DG 備庫端應用中斷，報錯如下 ：

Corrupt block seq: 197835 blocknum=1.

Bad header found during deleting archived log

Data in bad block - flag:1. format:34. bno:1. seq:197835

beg:0 cks:35882

calculated check value: 35882

archivelog header validation failure for file /oradata/arch/1_197835_885747866.dbf

Reread of seq=197835, blocknum=1, file=/oradata/arch/1_197835_885747866.dbf, found same corrupt data

 

Errors in file /u01/app/oracle/diag/rdbms/orcldg/orcldg/trace/orcldg_pr00_26969.trc  (incident=160231):

ORA-00353: log corruption near block 2 change 13904140140 time 03/23/2021 09:53:26

ORA-00312: online log 9 thread 1: '/oradata/orcldg/std_redo09.log'

Incident details in: /u01/app/oracle/diag/rdbms/orcldg/orcldg/incident/incdir_160231/orcldg_pr00_26969_i160231.trc

Tue Mar 23 09:54:59 2021

Dumping diagnostic data in directory=[cdmp_20210323095459], requested by (instance=1, osid=26969 (PR00)), summary=[incident=160231].

Errors in file /u01/app/oracle/diag/rdbms/orcldg/orcldg/trace/orcldg_pr00_26969.trc  (incident=160232):

ORA-00355: change numbers out of order

ORA-00353: log corruption near block 2 change 13904140140 time 03/23/2021 09:53:26

ORA-00312: online log 9 thread 1: '/oradata/orcldg/std_redo09.log'

Incident details in: /u01/app/oracle/diag/rdbms/orcldg/orcldg/incident/incdir_160232/orcldg_pr00_26969_i160232.trc

MRP0: Background Media Recovery terminated with error 355

 

使用 sha256sum 運算日誌檔案大小，確實顯示與生產庫原始檔不同。

 

初步問題判斷為偶爾的歸檔日誌傳輸錯誤導致，將錯誤的日誌手工傳送到備庫後，重新應用日誌後， DG 同步恢復正常。

但第二天又出現相同錯誤。檢索 MOS 文件後，發現有如下文件與故障比較相似

Bug 6039415 - ORA-355 can occur during real time apply (Doc ID 6039415.8)

Bug 13840711 - ORA-353 in Standby / Streams Data Capture or ORA-272 in PRIMARY: Redo log corruption by ASYNC redo shipping (Doc ID 13840711.8)

troubleshooting corruption errors ORA-00353 ORA-00354 ORA-00355 ORA-00368 on standby database (Doc ID 2746179.1)

確實此資料庫版本為 11.2.0.3 ，並未打任何補丁，於是打上最後一個補丁，手工補全日誌後，重新同步。

 

未過多久，還是出現相同錯誤，故障並未解決。

 

進一步檢查發現 standby redo log 竟然有兩組同時為 acitve 狀態

正常情況下 standby redo log 應只有一組為 ACTIVE 狀態，對應生產庫的 current 那一組 redo log 。

 

懷疑導致此問題是否有如下可能：

1） 資料庫 BUG

2） 難道有另一個資料庫也將日誌發往此處？

 

針對資料庫 BUG 的情況，此處修改生產 redolog 日誌大小與原先不同（原先為 500M ，新新增一組 2048M ），並給 dg 端新增相同大小的 standby redo log 。結果還是有兩組同時為 ACTIVE 狀態。（正常情況下，只有與生產 redolog 大小完全一致的 standby redo log 才能被正常使用）

 

此時，第二種情況，有另一個資料庫也將日誌發往此處的可能性大大增加。

透過監聽日誌與 netstat -atnp 發現有另一個 IP 地址與 DG 端有通訊，登入到此主機後，發現為一臺虛擬機器克隆出來的生產庫，並未關閉 DG 同步。

 

解決辦法：停止克隆主機資料庫的 DG 傳送。

建議：

1） 開啟 DG 端防火牆，只放行生產主機 IP 地址，避免客戶再次克隆主機時出現此類問題。

 

補充：

Rac 下查詢 gv$standby_log 檢視時，結果中確實為會顯示有四組為 active 狀態。

需要注意的是其中 GROUP# 有一組是重複顯示的。實際上 ACTIVE 狀態的只有兩組。