Wed May 28 14:30:34 2014
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6152_9nv89fv0_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_15/o1_mf_1_6153_9nv89g10_.arc
......
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_21/o1_mf_1_6208_9o9mnqhc_.arc
Media Recovery Log /u01/app/oracle/fast_recovery_area/CRJNEW/archivelog/2014_04_21/o1_mf_1_6209_9obb1c7s_.arc
......
你会发现Oracle仍然会去检查，并跳过这部分差了1个多月的归档，这个过程很快的，不到10分钟完成了。
当然，这个case就算over了。
备注：oracle 11gR2（准确的说是11.2.0.2）开始，active dataguard引入了Automatic Block Repair 机制。然后该机制
需要满足的一定的条件，如下是官方文档的说明：
If ... Then ...
A corrupt data block is discovered on a primary database
A physical standby database operating in real-time query mode can be used to repair corrupt data blocks in a primary database. If possible, any corrupt data block encountered when a primary database is accessed will be automatically replaced with an uncorrupted copy of that block from a physical standby database operating in real-time query mode. An ORA-1578 error is returned when automatic repair is not possible.
A corrupt data block is discovered on a physical standby database
The server attempts to automatically repair the corruption by obtaining a copy of the block from the primary database if the following database initialization parameters are configured on the standby database:
Configure the LOG_ARCHIVE_CONFIG parameter with a DG_CONFIG list
Configure a LOG_ARCHIVE_DEST_n parameter for the primary database
实际上，可能还存在一些特殊的情况，当然客户这里是没有使用real-time模式。