三、对open resetlogs的primary数据库standby的恢复
    当primary数据库被以resetlogs打开之后，dg提供了一些方案，能够让你快速的恢复物理standby，当然这是有条件的，不可能所有的情况都可以快速恢复。我们都知道alter database open resetlogs之后，数据库的scn被重置，也就是此时其redo数据也会从头开始。当物理standby接收到新的redo数据时，redo应用会自动获取这部分redo数据。对于物理standby而言，只要数据库没有应用resetlogs之后的redo数据，那么这个过程是不需要dba手工参与的。

下表描述其它情况下如何同步standby与primary数据库。

Standby数据库状态	Standby服务器操作	解决方案
没有应用resetlog之前的redo数据	自动应用新的redo数据	无须手工介入
应用了resetlog之后的redo数据，不过standby打开了flashback。	可以应用，不过需要dba手工介入	1.手工flashback到应用之前 2.重启redo应用，以重新接收新的redo数据。
应用了resetlog之后的redo数据，而且没有flashback。	完全无法应用	重建物理standby是唯一的选择

很绕是吧，举个例子你就明白了：
    假设primary数据库当前生成的archive sequence#如下：...26,27,28，然后在28的时候执行了resetlogs，又生成了新的1,2,3.....，那么standby能够正常接收并应用26,27,28及新产生的1,2,3....

    如果primary数据库在28的时候发生数据出现故障，recover到27，然后resetlogs，又生成了新的1,2,3.....，这个时候(大家注意，招子放亮点)：如果standby还没有应用28，刚刚应用到27，则standby还可以继续接收新的redo数据1,2,3.....并应用。
如果此时不幸，standby由于是实时应用，已经应用了28的redo数据，那么如果standby打开了flashback，不幸中的万幸啊，这时候只需要dba手工介绍先flashback到27,然后再接收并应用新的1,2,3....

    如果此时非常不幸，standby由于是实时应用，已经应用了28的redo数据，并且standby也没有打开flashback，那么，重建物理standby是你唯一的选择。

    这下大家都明白了吧，赶紧起立鼓掌感谢yangtingkun大大的形象示例及其友情客串:)。