执行switchover是计划性的主备库切换，主要应用场景是主库需要切换到备库模式，对主机做一些维护或者是硬件的维修和保养，但有要求业务不能停，因此临时性的将备库切换为主库承担业务系统请求。
一、切换前的条件检查
切换前要检查主备库的运行情况，必须满足切换条件才能成功切换主备库：
1、DG的当前运行模式和运行级别
maximum protection模式不能进行switchover，如果standby 数据库运行在maximum protection模式，在switchover转换之前必须先将最大保护模式修改成最高可用性或者最大性能模式
2、数据库的OPEN_MODE
正确情况下主库应该是read write模式，备库应该是READ ONLY
WITH APPLY模式。只有在DG切换前能够实现实时同步的前提下才能保证主备库切换后无数据丢失。备库的READ ONLY WITH APPLY状态说明当前standby db正处于实时同步的状态
3、数据库的角色
切换前一定要明确数据库的当前角色即主备库，不能乱切！！否则会导致整个DG瘫掉。
4、允许切换状态
执行主备库切换的sql指令前，一定要确认主备库当前的允许切换状态，如果不是理想的主备库切换状态说明DG环境有问题，此时不能执行主备库的切换指令。必须先解决该问题，才能执行后续的切换指令，否则会使整个DG瘫掉。
5、实例的状态
切换前要特别留意主备库当前实例的状态，正常情况下应该都是open状态。
6、执行如下sql查询切换前的条件检查：
select NAME,OPEN_MODE,DATABASE_ROLE,SWITCHOVER_STATUS,GUARD_STATUS,PROTECTION_MODE,PROTECTION_LEVELfrom v$database;
主库端查询结果：
DG当前运行模式：MAXIMUM PERFORMANCE（最大性能）
主库打开模式：READ WRITE
主库角色：PRIMARY
主库的允许切换状态：TOSTANDBY
备库端查询结果：
DG当前运行模式：MAXIMUM PERFORMANCE（最大性能）
备库打开模式：READ ONLYWITH APPLY
备库角色：PHYSICALSTANDBY
备库的允许切换状态：NOTALLOWED
主备库的instance状态：
SQL> select instance_name,status from v$instance;
主库：
二、尽可能多的把主库的redo data 传送到备库并实时应用，以减少数据的丢失
在主库多切换几次归档，尽量把当前redo中的事物尽可能多的切换到归档中，然后传递到standby 并实时应用。这样可以减少主备库切换过程中的数据丢失。
在主库端执行归档命令：
SQL> alter system archive log current;
连续切换三次归档，然后查看备库端的归档应用情况
备库端执行：
SQL> selectname,THREAD#,SEQUENCE#,FIRST_CHANGE#,NEXT_CHANGE#,APPLIED from v$archived_log;
结果显示主库的前一个redolog已经被应用，standby正在实时应用序列号为144的current redolog
除了当前redolog，所有的归档日志已经在standby db端应用。这样保证了尽可能多的redo data应用到了standby db，减少了主备库切换过程中可能的数据丢失。正常情况下的switchover是不会丢失数据的，只有在误操作时可能导致数据的丢失，如果是按照正常的操作流程是不会出现数据丢失的。failover属于故障切换不是正常的switchover，一旦面临DG的failover基本上就要做好丢失数据的准备了。
三、修改主备库的运行模式
maximum protection 模式不能进行switchover，如果standby db运行在maximum protection模式，在switchover转换之前必须先将最大保护模式修改成最高可用性或者最大性能模式
在备库端执行：
SQL> ALTER DATABASE SET STANDBY DATABASETO MAXIMIZE PERFORMANCE;
默认情况下物理standby都是运行在最大性能模式，除非有特殊的需求才会修改standby的运行模式。
上述指令只需要在备库端执行，但是在主备库切换之前最好要保证主备库运行在相同的模式下，这样可以减少切换过程中的不必要的麻烦，通常设置主备库都运行在最大性能模式下。
如果需要可以在主库端执行如下指令：
在主库端执行：
SQL> ALTER DATABASE SET STANDBY DATABASETO MAXIMIZE PERFORMANCE;
注：在完成主备库的切换之后，可以重新修改standbydb的运行模式为原来的模式。
四、切换主库到备库
1、验证主库能否切换成备库
在主库执行如下SQL查询
SQL> select switchover_status fromv$database;
如果是 TO STANDBY 或者 SESSION ACTIVE，表示主库可以切换成standby role。其他值就不能切换，因为其他值表明DG 的环境可能已经被破坏了。
2、将主库切换成备库
执行如下SQL，将主库切换成standby role
如下SQL 是把主库切换成物理standby。在switchover 之前，当前的控制文件会被备份到当前session 的trace file里。这样如果需要，我们还可以通过trace 重建控制文件。
SQL> oradebug setmypid
SQL> alter database commit to switchoverto physical standby with session shutdown;
SQL> oradebug tracefile_name ---显示控制文件的名称和路径
3、查看trace中的控制文件记录
[root@edsir1p8 ~]# more tracefile_name.trc
五、Shut down 原主库并重新启动到open状态
SQL> shutdown immediate
SQL> startup
查询原主库的角色、运行模式、允许切换的角色
执行如下sql：
selectNAME,OPEN_MODE,DATABASE_ROLE,SWITCHOVER_STATUS,GUARD_STATUS,PROTECTION_MODE,PROTECTION_LEVELfrom v$database;
主备库当前日志序列号相同
主库端手动切换归档：
SQL> alter system archive log current;
再次查询主备库端的当前日志序列号是否相同
结果显示主备库的当前日志序列号都是153，说明主备库能够同步切换归档。
3、查询主备库实时同步相关进程的信息
SQL> select process, status, thread#,sequence#, block#, blocks from v$managed_standby;
ARCH进程已经归档的日志序列号为152
RFS进程已经接收的redo data序列号为153
mrp进程已经实时应用的redo data的序列号为153
综上：说明主备库实时同步。
至此，完成主备库switchover的所有操作。