专家们好：

          客户打算在11月份左右进行一场灾备演练，涉及两个ADG的核心库需要switchover，请专家帮我确认一些和OGG相关的步骤和问题。环境架构类似如下：

OS版本:aix7.1      oracle版本：全部都是11.2.0.4    ogg版本:  Version 11.2.1.0.33

测试库:test --ADG环境 

主库demo(rac)：demo1(实例)  demo2(实例)

备库come(rac)：come1(实例)  come2(实例)

报表库:rpt--非ADG环境

rpt（rac）:rpt1(实例) rpt2（实例）

OGG链路:源端在demo2上，目标端在rpt1上，从demo2->rpt1的单向DML链路

本次灾备演练客户需求：

进行测试库test的switchover，待应用测试可用性之后，当晚再switchover回来，在整个的switchover过程中，不改变OGG软件的安装位置，仍旧保持在demo2上。

我在自己电脑上做了如下的测试：（我的电脑的环境以及软件版本和客户的环境基本一致，只不过我的ogg目标端是单实例，客户的是rpt(rac)）

1. 在第一次switchover之前，停源端和目标端的OGG进程（保险起见可以记录OGG源端此刻抽取的时间和位置）

   

   
   

2. 在第一次switchover之后，主库变成了come，备库变成了demo，OGG所在的demo2就变成了备库的实例

   当我启动尝试启动demo2上的ogg的抽取和传输进程时，抽取进程不能启动，仍为stopped状态，传输进程可以running，自己推测原因可能是因为此时onlinelog为不可用状态，因为是备库，所以活跃的应该是standbylog，经过查询，无论主库备库role是否发生改变，该库的归档仍然是顺序写入的，sequence#也是连续的

3. 此时在come库进行DML并commit;

4. 进行第二次的switchover

5. 再次尝试启动demo2上的ogg和rpt1上的ogg，发现进程可以正常启动，且跟踪了一下，etbb抽取的位置

6. 待OGG数据追平之后，再次观察OGG的位置

7. 在rpt1实例上观察步骤3的dml的结果，可以成功看到数据的变化

   所以我的结论是:在我以上软件版本和环境的条件下，对于switchover而言，在switchover之前stop掉ogg，等待两次switchover都结束之后，ogg仍然可以从online和archivelog中抽取数据的变化并传输到目标端rpt1，在保持归档的完整性的条件下，只需在两次switchover结束之后，再次启动ogg，就可以了

请专家帮我鉴定，在以上的测试中，我的步骤是否有问题，是否还有疏漏的地方或者是我需要注意的地方，谢谢大家。