1.1 简介
Data Guard配置包括1个primary角色的数据库和1个或者多个standby角色的数据库，数据库的角色我们可以通过V$DATABASE中DATABASE_ROLE字段来获得。
另外，Data Guard配置中standby库的数量、位置、备库类型以及redo data从主库传到备库的方式，决定了主库发生停机故障时能采用的角色管理方案。
当数据库运行于Data Guard中primary或者standby这样互斥的角色时，可以通过SQL语句或者Data Guard broker图形界面来动态的更改它们的角色，Data Guard支持的角色转换有Switchover和Failover。
- Switchover
Switchover允许主库切换角色到它的某一个备库，在切换期间不会丢失数据，切换之后，每个数据库继续以其新的角色参与Data Guard 配置中。
- Failover
Failover用于更改备库到主库角色以响应原主库的故障，如果主库在故障之前没有运行在最大保护模式或最大可用性模式下，可能发生数据丢失。如果在主、备库都允许闪回数据库，只要故障解决了，原主库可恢复作为新主库的备库。
1.1.1 角色转换准备工作
角色转换前，需要做好以下工作：
1.确保主备库已经正确配置
关于Data Guard 配置的参数、归档模式、standby日志等的配置参详http://blog.csdn.net/u010257584/article/details/51140030，这里略过，standby库的LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n必须配置，这样角色转换后，才能接收从新的primary库传过来的REDO数据。
2.查询V$ARCHIVE_DEST_STATUS，确保standby库没有REDO传输错误以及REDO GAPS，比如查询LOG_ARCHIVE_DEST_2：
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID =2;
当STATUS的值为VALID、GAP_STATUS为NOGAP方可进行下一步。
3.确保主备库的临时文件一致。
4.删除重做应用的所有延迟，因为这可能会影响备库转为主库角色。
5.RAC主库转为物理备库，务必先只保留其中一个RAC实例为OPEN状态，其他的实例都关闭，其他关闭的实例待转换结束后可以重新联机。
6.即使在切换期间备数据库上只有一个RAC实例是打开的，所有其它备数据库实例在打开时，还将自动经历一个正确转换到它们的新角色的过程。
7.对于运行在real-time查询模式下的物理备库，执行角色转换之前，可以将备库的所有实例启动到mounted而不是open状态，这样可以实现最快的角色转换，并且能在角色转换之前完全终止所有连接到物理备库的用户会话。
1.1.2 选择角色转换的目标备库
对于多备库的Data Guard配置，角色转换时选择目标备库需要考虑诸多因素，包括：
1.备库的位置与备库类型
2.备库的能力（硬件规格，如CPU数目、可用I/O带宽等）
3.执行角色转换所需的时间，这受备库重做数据的应用快慢，以及数据丢失情况下应用程序的可用性。
角色转换目标备库的类型决定了转换后配置中其他备库的角色。对于physical备库，其中一个备库转为primary角色，配置中所有的其他的备库都将变成新primary角色的备库。而对于logical备库，其中一个备库转为primary角色，配置中所有的其他的备库都将变成新的primary角色的备库，但是该配置中的物理备库将继续作为旧的primary主库的备库而不保护新的主库。对于后一种情形，如果进行Switchover或者Failover切换回原始主库，那么当前新主库的所有备库将变回原始的角色状态。综上所述，对于包含物理与逻辑备库的配置中，物理备库是最佳的角色转换目标。
Data Guard提供了V$DATAGUARD_STATS视图，该视图包括每个备库的数据流量估值、执行角色转换所需的时间（当所有redo数据都已应用到备库）。
例如：
<pre dir="ltr">SQL> COLUMN NAME FORMAT A24
SQL> COLUMN VALUE FORMAT A16
SQL> COLUMN DATUM_TIME FORMAT A24
SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;
查询结果显示，备库接收并应用了主库传来的所有的redo数据。transport lag、apply lag的值是通过主库传来的redo数据估算的，如果主备库之间的连接出现过中断，那么这个值就没有意义。transport lag、apply lag对应的DATUM_TIME列的值如果没有变化，表明它们没有被更新，已经无意义，很可能是因为主备库之间的通信出现了中断。
1.1.3 Switchover
Switchover通常用于减少计划内的中断过程中主库的停机时间，比如操作系统或者软件的升级，以及Oracle数据库软件或者补丁的滚动升级。
Switchover分为2个阶段，第一阶段，现有的主库转换为备库角色；第二阶段，备库转为主库角色。
如下，主库为San Francisco，备库为Boston，转换前的data guard配置：
当原始主库已转换为备库，但原始备库还未转为新的主库，Data Guard环境如下：
当原始备库转换成新的主库，也就是主库变成了Boston，备库变成了San Francisco，Data Guard环境如下：
Switchover之前，以下2点必须满足：
- 对于物理备库的切换，确保主库是打开的，而且备库的REDO应用处于active状态的；
- 对于逻辑备库的切换，确保主备库的实例都是打开的，并且SQL应用时active状态。
1.1.4 Failovers
当主库不可用，并且不可能在一个合理的时间内恢复它，Failovers就派上了用场。Failover执行的具体操作取决于是否有逻辑与物理备库涉及的故障、故障转移时Data Guard的配置状态，以及启动Failover时具体的SQL语句。
Failover San Francisco主库到物理备库Boston，结果如下：
再进行failover之前，如果可以，尽可能将所有可用而未被应用的主库redo数据传至备库。
failover角色转换其他的前提条件如下：
- 如果备库运行在最大保护模式下，请先更改为最佳性能模式：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;转换结束后，可以根据需要重新设置备库运行模式。
转换备库的运行模式是因为备库运行在最大保护模式下不能进行failover操作，另外，如果主库运行在最大保护模式下，并且和备库还在通信的状态下，更改备库到最佳性能模式的SQL操作将不能成功。因为failover操作将主库移出了dataguard配置，这些特性意在保护运行在最大保护模式下的主库免受意料之外的failover操作。
1.1.5 角色转换触发器
当发生角色转换时，系统事件DB_ROLE_CHANGE将触发。如果角色转换时数据库在open状态或者角色转换时数据库是关闭的、那么下一次数据库open时，该系统事件都将被立即触发。
当角色变化发生时，DB_ROLE_CHANGE系统事件可以用来触发并执行一系列的操作。
本文参阅Oracle官方文档翻译，不足之处欢迎批评指正！
