11G DataGuard 日志同步错误处理案例-20180821

接同事电话,ADG备库同步出了问题。
在备库查看,大量的redolog没有apply。
在备库查看GAP,竟然没有查到。

查看备库日志,当前只有1号、3号的日志不停的传了过来,唯独缺了2号的,如下:

看来是2号节点那边出了问题。

查看2号节点日志,果然是无法登陆adg节点,如下:

让同事协助重启2号节点,依然有问题,从1号节点拷贝来密码文件,命名为2号的密码文件,再次重启,查看备库的GAP,这次GAP信息对了,如下:

可见,2号节点的73164-73213共计50个redolog没有传过来,2号的redo只在备库应用到73163,并堵塞了1号、3号的日志应用。

只能从2号主库去找这些日志了,不幸的是,2号上的日志只保留到了73124开始往后的,如下:

可见,前面的日志已经在备份后删除了,只能从备份恢复出来,再搞到备库。

此处先暂停2号节点的自动备份与删除任务,恢复日志备份,如下:

耗时几个小时!
此时查看可见恢复了这些日志:
select name from v$archived_log where name like '+FRA/jkdb/archivelog/2018_08_21/thread_2%' order by sequence#;
此处显示结果略。

将这些短缺的redolog拷贝到备库,如下:

又耗费几个小时,汗。

然后再备库注册这些日志,如下:

需要注意的是,注册时提示已经注册了。但是备库并没有主动开始应用这些日志。

在备库关闭同步,再打开同步,让它自己慢慢apply吧!预计至少几个小时吧,因为截至此时,已经积攒了600多个日志待apply。

睡觉,第二天早上7点查看,备库已经完全同步了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注