减少Data Guard做Failover时的数据损失

如果我们的DG的主库发生了当库,我们怎么样做failover,才能保证最少数据的丢失?

我们把数据分成3类:

1.是已经arch传到备库,并且已经apply的数据——ok,这些数据是正常传输的数据,平时数据就是在这么做的。

2.是还未传输到备库的日志,此时这部分日志还没被apply,但是arch已经在主库上产生,但是由于网络的原因,还没传输到备库。

3.是还在redo中的日志,这些记录已经commit,但是还未被切换到arch,即只在主库的redolog上,连主库上的arch都不存在。

我们通过一个小实验来模拟数据的恢复:

插入一条正常的数据,并且arch正常传输到备机apply:

现在我们中断网络,模拟arch无法正常传输到备机:

最后,我们模拟插入记录3后,当完成commit后,突然宕机(shutdown abort):

ok,我们假设主库已经宕机,不能再起到primary的作用,而我们现在有3条记录:
xxx表中的三行记录:

ID
———-
1<-----正常传输到备机且apply。 2<-----因为网络中断,只是在主库生成arch但未传输到备机,未被apply。 3<-----记录commit后,主库宕机,存在在redolog中,连主库的arch都没到。 那么在备机中,我们如何将这些数据恢复呢? 主要的步骤有以下几步: 1.传输主库和备库差异的archlog 2.传输主库的redolog 3.alter database recover managed standby database cancel; 3.recover standby database; 4.做failover: alter database recover managed standby database finish; or alter database recover managed standby database finish skip standby logfile; alter database commit to switchover to primary; shutdown immediate; startup; 其他的步骤不多说了,这里主要演示下恢复上述的三行记录: 在备库: 我们看到最开始,备库只有一条记录,即正常传输arch的记录

开始进行恢复,先恢复arch中的记录,此时主库的arch和redo已经通过ftp传输到'D:\oracle\from_primary\'目录:

进行redolog的恢复,接着刚刚的步骤不要退出,提示输入filename的时候输入redolog的位置,由于之前我已经知道在shutdown abort之前,redo 2是current的redo,所以我们直接代入redo2,如果不知道是那个redolog是current的,可以逐个代入:

在failover到主库前,我们可以看看这次实验的3条数据是否都转移到备库上来了:

我们看到,三种情况的数据都已经在备库中恢复,这下可以放心的将备库failover成主库了。当然failover之后,还有重建DG等工作,这些可以参照我之前的用rman在线重建DG的文章

相关文章

2条评论

  1. 关键字与online redo logfile的保护,最好在存储和主机本地硬盘都有至少一个member,这样不管存储挂还是主机挂,至少还有一份可用的redo,就不会丢数据

发表评论

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

此站点使用Akismet来减少垃圾评论。了解我们如何处理您的评论数据