部署dataguard时遇到的怪异情况

zhuqibs

os: redhat linux AS 5.8
oracle 11.2.0.2


（1）备库建完后，发现无法打开，报system01.dbf文件需要恢复？当然由于是read only库，recover database 是不行的啊。
（2） alter database recover managed standby database disconnect; 恢复；  发现了非常妖孽的事：
          select * from v$arechive_gap； 都是为空，没有gap
          但是，alert一直在报缺371-384的日志；这还不算
          select sequence#,applied from v$archived_log; 发现317-384日志没有，这也好解释，我是LGWR ASYNC传的，lgwr已经传了，归档就不过来了，但是：
             370    yes
             385    yes
             386    yes
             。。。。
             415   yes
             416   no
             417   no
   （3） 天啊，这是什么世道，dg发现了416号日志，但死活不应用，我可是在recover managed standby database模式啊，不是在mount啊
   （4） 继续查看： select process,status from v$managed_standby; 发现该死的MRP进程始终处在 wait_for_gap模式，天啊，它一直在等不需要的371-384的日志，而这个日志，我已经在主库上删除，这确实也是不需要的啊
             当前数据库已经恢复到415啊！

事情就是这样，备库mrp在等不需要的gap，而v$archive_gap中没有gap，从库有416号归档日志，但由于mrp根本不工作，而无法恢复。

select.简单

v$datafile_header 查看你的文件头的检查点，看看是不是有文件落后很多，另外看你的控制文件是不是不是最新的

zhuqibs

数据文件的header必然是落后的，control文件是新从主库生成的，我的问题是，既然recover managed状态了，过去的归档日志（371-384）虽然没有了，但我的archivelog已经应用到415了，为什么mrp0还会处于wait for gap状态，为什么不应用416号日志