dataguard碰到的奇怪情况

zhuqibs

主从库平台都是redhat linux  5.7 x64
数据库 11.2.0.1
日志大小：512m

原来的dataguard建立是好的，正常的，由于想验证某些想法。做了以下操作：
（1）shutdown了从库。
（2）在主库做大量的insert操作，产生了大量的日志；
（3）重新启动从库到read only with apply;
（4）发现，
         a、standby logfile没有传递完整，缺少了87,88,89；
         b、日志无法apply，90,91,92的applied都是no；
         c、select process,status from v$managed_standby;
               ARCH connected
              ARCH connected
              ARCH connected
             ARCH connect
             RFS  IDLE
             MRP0 applying_log   (不是 wait_for_gap)
         d、select * from v$archive_gap 为空，（居然没有gap）
         e、alert文件没有报错；
         f、切换日志，还是可以传递到从库，
（5）传递所有缺失的日志到从库
            没有apply，整个从库僵死，而 select switchover_status from database;   显示：unresolvable gap，但从库的
             gap，还是没有，alert还是没有任何报错。

这事，是不是太妖了啊，刘大

铁钉

把从库改从 read only with apply;  切换到 恢复模式，等日志应用完成后，再启动到 read only with apply.

F.k-Tao

把主库的参数提出来看看。
shutdown了从库是操作系统shutdown还是实例shutdown？
在你shutdown从库的时候看看主库的alert 是不是由告警日志？

zhuqibs

问题很偶然的发现原因了

ADG很奇怪，当用using current logfile时，从库是不监控和主库的gap的，我从v$managed_standby上看到在using current logfile时，MRP0的状态都是applying logfile，而从不wait_for_gap, 这样即使从库和主库有巨大明显的gap，FAL机制也不会起效果。

zhuqibs

read only with apply也是恢复模式啊，有可能不是实时恢复模式啊，

从 select RECOVERY_MODE from v$archive_dest_status才能看出来是 real time，还是一般的。