LGWR SYNC AFFIRM也不能保证日志一定写到备机
昨天才给客户写了个删归档的脚本，今天就出问题了
最大可用模式，归档参数LGWR SYNC AFFIRM
我是按照V$ARCHIVE_DEST.LOG_SEQUENCE来判断已经传递到备库的归档号，小于这个号-1的归档就删除。结果今天查看，发现有GAP，检查发现掉了个日志。
通过v$archived_log检查，这个归档根本没归档到备机，而由于客户这几天导数据，有大量的归档没恢复，导致这个GAP发现的太迟了，主机的归档被我的脚本给干掉了。
一直以为远程归档一定会把每个归档都归过去，看来不是，出了问题就跳过了这个归档，接着归下一个
又是郁闷的使用RMAN来前滚数据库。。。郁闷啊。不过这次深刻理解了GAP，以前总觉得除非人为删除，不然那来的GAP啊
RMAN的DELETE命令真傻，不能判断哪些是备库还需要，而客户没打算做RMAN备份，用backup delete input觉得太傻。结果，我更傻...
PS：现在改用v$archived_log，看每个SEQ有几个归档，有2个的才删除，而且保留5天归档，安全第一！
最大可用模式，归档参数LGWR SYNC AFFIRM
我是按照V$ARCHIVE_DEST.LOG_SEQUENCE来判断已经传递到备库的归档号，小于这个号-1的归档就删除。结果今天查看，发现有GAP，检查发现掉了个日志。
通过v$archived_log检查，这个归档根本没归档到备机，而由于客户这几天导数据，有大量的归档没恢复，导致这个GAP发现的太迟了，主机的归档被我的脚本给干掉了。
一直以为远程归档一定会把每个归档都归过去，看来不是，出了问题就跳过了这个归档，接着归下一个
又是郁闷的使用RMAN来前滚数据库。。。郁闷啊。不过这次深刻理解了GAP，以前总觉得除非人为删除，不然那来的GAP啊
RMAN的DELETE命令真傻，不能判断哪些是备库还需要，而客户没打算做RMAN备份，用backup delete input觉得太傻。结果，我更傻...
PS：现在改用v$archived_log，看每个SEQ有几个归档，有2个的才删除，而且保留5天归档，安全第一！
来自 “ ITPUB博客 ” ，链接：https://blog.itpub.net/8242091/viewspace-668027/ ，如需转载，请注明出处，否则将追究法律责任。
下一篇：
recreate repos 卡住
请登录后发表评论
登录
全部评论
