切换分为switchover和failover，前者是无损切换，不会丢失数据，而后者则有可能会丢失数据，并且切换后原primary 数据库也不再是该data guard 配置的一部分了.针对不同standby(逻辑或物理)的处理方式也不尽相同
角色转换前的准备工作
检查各数据库的初始化参数，主要确认对不同角色相关的初始化参数都进行了正确的配置。
确保可能成为primary 数据库的standby 服务器已经处于archivelog 模式。
确保standby 数据库的临时文件存在并匹配primary 数据库的临时文件
确保standby 数据库的RAC 实例只有一个处于open 状态。（对于rac 结构的standby 数据库，在角
色转换时只能有一个实例startup。其它rac 实例必须统统shutdown，待角色转换结束后再startup）
Switchover：
无损转换，通常是用户手动触发或者有计划的让其自动触发，比如硬件升级啦，软件升级啦之类的。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段，第一步， primary 数据库转换为
standby 角色，第二步，standby 数据库(之一)转换为primary 角色，primary 和standby 只是简单的角色互换.
Failover：
不可预知原因导致primary 数据库故障并且短期内不能恢复就需要failover。
在执行failover 之前，尽可能将原primary 数据库的可用redo 都复制到standby 数据库。
注意，如果要转换角色的standby 处于maximum protection 模式，需要你首先将其切换为maximum
performance模式.转换standby 数据库到MAXIMIZE PERFORMANCE 执行下列SQL 即可：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
等standby 切换为新的primary 之后，你可以再随意更改数据库的保护模式。
maximum protection 模式需要确保绝无数据丢失，因此其对于提交事务对应的redo 数据一致性要求非常高，
另外，如果处于maximum protection 模式下primary 数据库仍然与standby 数据库有数据传输，此时alter
database 语句更改standby 数据库保护模式会失败，这也是由maximum protection 模式特性决定的。
下面演示failover的过程：
一物理standby的failover
注意几点：
failover 之后，原primary 数据库默认不再是data guard 配置的一部分。
多数情况下，其它逻辑/物理standby 数据库不直接参与failover 的过程，
因此这些数据库不需要做任何操作。
某些情况下，新的primary 数据库配置之后，需要重新创建其它所有的standby 数据库。
另外，如果待转换角色的standby 处于maximum protection 或maximum availability 模式的话，
归档日志应该是连续存在的.
一般情况下failover 都是表示primary 数据库瘫痪，因此这种类型的切换基本上不需
要primary数据库做什么操作。
1、检查归档文件是否连续
查询待转换standby 数据库的V$ARCHIVE_GAP 视图，确认归档文件是否连接：
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
未选定行
如果返回的有记录，按照列出的记录号复制对应的归档文件到待转换的standby 服务器。这一步非常重
要，必须确保所有已生成的归档文件均已存在于standby 服务器，不然可能会数据不一致造成转换时报错。
文件复制之后，通过下列命令将其加入数据字典：
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filejytest1';
2、检查归档文件是否完整
分别在primary/standby 执行下列语句：
SQL> select distinct thread#,max(sequence#) over(partition by thread#) a from v$archived_log;
该语句取得当前数据库各线程已归档文件最大序号，如果primary 与standby 最大序号不相同，必须将
多出的序号对应的归档文件复制到待转换的standby 服务器。不过既然是failover，有可能primary 数据库此时已经无法打开，甚至无法访问.
3、启动failover执行下列语句：
SQL> alter database recover managed standby database finish force;
数据库已更改。
FORCE 关键字将会停止当前活动的RFS 进程，以便立刻执行failover。
剩下的步骤就与前面switchover 很相似了
4、切换物理standby 角色为primary
SQL> alter database commit to switchover to primary;
数据库已更改。
5、启动新的primary 数据库。
如果当前数据库已mount,直接open 即可，如果处于read-only 模式，需要首先shutdown immediate，然
后再直接startup。
SQL> alter database open;
数据库已更改
角色转换工作完成。剩下的是补救措施(针对原primary 数据库)，由于此时primary 数据库已经不再是
data guard配置的一部分，我们需要做的就是尝试看看能否恢复原primary数据库，将其改造为新的standby
服务器。
