今天一生产库狂报错，查看alert.log，发现大量传输redo data失败的信息，登到stanfby 上查看，原来磁盘空间达到了100%， 新的日志无法创建了。近1TB的磁盘都被写满了？？！！ 仔细查看原来MPR0死掉了 日志无法应用，删除日志的脚本就没起作用。重起MPR0 ，select * from v$archive_gap，存在大量gap, 而对应的archivelog在primary已经被干掉了 -。- 只有重建了 （估计还有其他办法 ，但当时时间紧加上某BOSS脸色难看，就没多想 直接重建了）。
拿上primary的全备和standby controlfile，restore,没问题，再recover ，找不到某archivelog,从primary上手工弄过来，recover。 这次报错SCN不一致 FT ！
难道是手工考的无法识别？ 背后某BOSS突然咳嗽一声。。。。 无法多想，重新restore,这次先注册该archivelog，再recover。 还是报错！
无奈，抽时间上个WC~~ 清醒一下，换个思路，要不干脆不recover了，直接restore后就打开redo 应用，靠DG自己传输REDO DATA来恢复一致。照做，成了！ STANDBY 恢复正常。 上坛子发贴问了一下，看来果然有这个问题，standby 可能不会认为recover后是一致的，只有利用STANDBY自己的REDO应用来恢复才是最稳当的。
至此已经下班了， 太累~~不想深入研究 明天再来继续吧~~~~~~~~~~~~~
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/13351439/viewspace-437334/ ，如需转载，请注明出处，否则将追究法律责任。
