减少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的文章。