作者介绍：老苏，10余年DBA工作运维经验，擅长Oracle、MySQL、PG数据库运维（如安装迁移，性能优化、故障应急处理等）
公众号：老苏畅谈运维
欢迎关注本人公众号，更多精彩与您分享。

dataguard 切换方式有两种方式：switchover 和 failover。
（1）Switchover ：无损转换，通常是用户手动触发或者有计划的让其自动触发，比如硬件升级、软件升级之类的。switchover是有计划的，正常的切换，不会破坏数据库DG关系。
通常它给你带来的工作量非常小并且都是可预计的。其执行分两个阶段，第一步，primary 数据库转换为standby 角色，第二步，standby 数据库转换为 primary 角色，primary 和 standby 只是简单的角色互换。

• 切换过程：主库->切换->备库->检查状态->原备库->切换->主库->再检查状态
• 应用场合：主库需要调整升级，主库性能不佳，这时可以切换后用新主库对外提供服务
• 是否丢失数据：不会丢失数据

（2）Failover ：不可预知原因导致 primary 数据库故障并且短期内不能恢复就需要 failover，failover是非计划的，破坏性的切换，切换之后要重建DG。
所谓failover，它是一种丢弃切换，直接把备库切换成主库，原主库自动丢弃，也就是不在属于DG架构的一部分了。

• 切换过程：备库->切换->主库->检查状态，原主库脱离DG架构
• 是否丢失数据：极有可能丢失数据，我们的目标就是损失降到最低
• 如果在failure之前是maximum protection or maximum availability模式，会丢失数据
• 挽救措施：重建主库使用原来备份恢复主库

一、Switchover操作步骤

大致步骤为主库先转换为备库，在此阶段可能看到原先的主备皆为备库状态，然后再将原备库设置为主库

1.主库操作

注意事项：

• 生产环境切换时间会长，考虑执行alter system flush buffer_cache，将内存数据刷到磁盘
• 写检查点alter system checkpoint
• 考虑先关闭应用，无用户连接可以减少切换的时间

–检查是否已经添加standby redo log
–standby redo log数量应等于redo数量 +1
select * from v$standby_log

–检查主库状态
–SWITCHOVER_STATUS转换状态：to standby和session active（有会话连接），这两种状态可以转换
select name,open_mode, database_role, switchover_status, force_logging, dataguard_broker, guard_status from v$database;

–检查主备之间是否有GAP
–dest_id:1主库 2备库
select STATUS, GAP_STATUS from v$archive_dest_status t where DEST_ID = 2;

–swithover切换（主库执行完毕实例会自动关闭）
alter database commit to switchover to physical standby;

–当有会话连接的情况下，执行上面命令会失败，需要用这一条
alter database commit to switchover to physical standby with session shutdown;

–启动数据库
startup;

–检查当前数据库状态，此时应看到已经是read only，且是PHYSICAL STANDBY状态
select open_mode,database_role from v$database;

–开启实时应用
alter database recover managed standby database using current logfile disconnect;

2.备库操作

–检查状态
–同主库一样，SWITCHOVER_STATUS是to primary或session active就可以切换
select name,open_mode, database_role, switchover_status, force_logging, dataguard_broker, guard_status from v$database;

–执行切换（执行后为mounted状态）
alter database commit to switchover to primary;
或
alter database commit to switchover to primary with session shutdown;

–打开数据库
alter database open;

3.测试同步

测试主备切换的数据同步情况。

二、Failover操作步骤

注意事项：
1.failover操作之后，会自动丢弃原主库不在是DG一部分
2.如果你有多个备库，其他备库也会自动脱离DG，也不需要做shutdown 和 restart 动作。当有了新主库之后可以根据需要重新创建所有备库
3.我们推荐使用命令行的方式进行failover操作
4.不能在备库接收日志情况下进行failover操作
5.如果你的备库是在maximum protection mode or maximum availability mode并且使用LGWR方式传送日志，那么归档日志号是不会有缺口的必须是连续的，
这时可以直接停止接收日志，马上进行failover切换
6.在进行切换之前检查归档日志号不能有缺口gap

操作步骤：

1.如果备库是maximum protection 必须先修改成maximum performance之后才能切换
修改语句：Alter database set standby database to maximize performance；
注：切换之后你可以在改回maximum protection mode

2.如果主库与备库之间有日志传输的话，如上语句修改备库从maximum protection->maximum performance不会成功的。因为failover操作会删除原主库的DG配置，这也是为了保护主库操作。

3.检查备库归档日志号是否都是连续的，不能有缺口，否则需要补救，可以检查VKaTeX parse error: Expected 'EOF', got '#' at position 38: …口 SELECT THREAD#̲, LOW_SEQUENCE#…ARCHIVE_GAP;
如果备库归档日志号是连续的，就不用在拷贝归档日志了

如下面的：
SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD#LOW_SEQUENCE# HIGH_SEQUENCE#

---

1 90 92

说明缺少90、91、92号归档日志，可以从主库->copy->备库，必须保证归档日志齐全，否则会在failover时导致数据丢失

加载copy归档日志信息至控制文件
ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘filespec1’;

对比主备库归档日志列表的完整性
select sequence#,ARCHIVED,APPLIED from v$archived_log;主库归档日志列表

–停止备库日志应用
alter database recover managed standby database cancel;

–关闭备库的日志传输，备库会置于mount状态。
alter database recover managed standby database finish force;

force关键字：终止了RFS进程，以便停止接收日志
finish关键字：后面还可以跟随FORCE WAIT NOWAIT

–若主备之间有gap的情况下，使用上一条语句可能会不成功，则需要执行这条语句
alter database active physical standby database;

–切换到primary
alter database commit to switchover to primary with session shutdown;

–重启数据库
shutdown immediate;
startup;

–查询数据库状态
select open_mode,database_role from v$database;
OPEN_MODE DATABASE_ROLE

---

READ WRITE PRIMARY