故障描述
数据库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 状态的只有两组。
