一、 概述
Oracle数据库以主/备角色之一运行，可以通过以下方法更改数据库角色：
- SwitchOver：在主库正常运行、主从正常同步时进行，可翻转数据库主备角色。SwitchOver没有数据丢失，通常在预期的主库维护前进行。
- Failover：在主库故障时进行，可把备库强行提升为主库。Failover后主从关系不会自动恢复，可以使用代理的恢复功能或闪回恢复主从关系。Failover可能有数据丢失，丢不丢取决于保护模式设置。
- Activate：激活从库使其变为独立主库，此后与原主库主从关系中断，只能重搭。
本篇先介绍利用sql操作的方法，下一篇介绍利用DG Broker操作的方法。
二、 SwitchOver
1. 架构图
切换前
切换中（同步恢复前）
切换后
只要有可能，就应该切换到物理备库：
- 如果 切换将物理备库转换为主库，那么：
- 原主库将切换为物理备库。
- redo log将从新主库归档到配置中的所有备库。
- 原主库将作为切换操作的一部分重启。请注意，不需要重启新主库。
- 切换中不涉及的备库（称为旁观者备库）
- 如果 切换将逻辑备库转换为主库，那么：
- 当配置在最大保护模式下运行时，不允许切换到逻辑备用数据库。
- 原主库将切换为逻辑备库。
- 切换完成后，无需重启主库或逻辑备库。
- 切换后，代理配置中的其他逻辑旁观者备库将保持可用，无需重新启动任何数据库。
- 在切换到逻辑备库后，所有物理和快照备库都将被禁用，必须从新主库的副本中重新创建。
2. 切换前准备
- 若有多个备库，确保各节点间数据库端口是通的
- 确保主库的状态为TRANSPORT-ON，备库的状态为APPLY-ON。任何旁观者备库发生错误均不会妨碍切换。
- 确保主数据库正确设置了备库log_archive目标
- 确保在主数据库上添加了Standby redo logfiles (SRLs)
- 如果主库是rac，只留待切换实例启动，其他实例全部关闭
3. 执行切换
步骤1：在主库上，检查switchover_status
状态为TO STANDBY 或 SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话
SQL> select switchover_status from v$database;
SWITCHOVER_STATUS
--------------------
TO STANDBY步骤2：将主库转为物理备库
with session shutdow用于强制关闭活动会话。
SQL> alter database commit to switchover to standby with session shutdown;
Database altered.步骤3：重启并进行日志应用
如果是rac，只有一个实例能运行MRP进程，其他实例只能运行RFS进程接收日志。
SQL> shutdown immediate
SQL> startup
SQL> alter database recover managed standby database using current logfile disconnect from session parallel 4;步骤4：检查状态，可以看到已变为从库
SQL> select name, LOG_MODE, OPEN_MODE, database_role, SWITCHOVER_STATUS, db_unique_name from v$database;
NAME LOG_MODE OPEN_MODE DATABASE_ROLE SWITCHOVER_STATUS DB_UNIQUE_NAME
------------------------- ------------ -------------------- ---------------- -------------------- ------------------------------
ORCL ARCHIVELOG READ ONLY PHYSICAL STANDBY SESSIONS ACTIVE orcl至此对原主库操作已完成，下面是对目标从库的操作。
步骤5：检查目标备库状态
状态为TO PRIMARY 或 SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO_PRIMARY步骤6：将备库切为主库
SQL> alter database commit to switchover to primary with session shutdown;步骤7：OPEN新主库
检查数据库的打开模式，可以看到已变为主数据库角色
SQL> ALTER DATABASE OPEN;
SQL> select name,open_mode,database_role from v$database;
NAME OPEN_MODE DATABASE_ROLE
--------- --------------------
MYTEST READ WRITE PRIMARY步骤8：若其他备库的日志应用停止了，需要启动
SQL> alter database recover managed standby database using current logfile disconnect from session parallel 4;三、 Failover
failover与switchover最大的区别在于此时主库故障，切换可能丢数据（丢不丢取决于保护模式设置），并且Failover后主从关系不会自动恢复，可以使用代理的恢复功能或闪回恢复主从关系。
1. Failover的类型
① 手动failover
需要DBA手动干预，可以再细分为Complete Failover和Immediate Failover。
- Complete Failover（默认方法）：尝试先将在主库所有重做日志应用到备库，最大程度地减少数据丢失。
- Immediate Failover ：不再对备库进行数据应用，立刻进行切换。
如果满足以下任一条件，请使用立即故障转移：
- 备库遇到
ORA-752错误 - 备库遇到
ORA-600[3020]错误，并且Oracle support已确定它是由于在主库中lost write造成的 - 不可能进行完全故障转移
如果在故障转移目标上发生ORA-752或ORA-600 [3020]错误，请不要尝试恢复旧主库，因为这样做可能会导致数据丢失。必须从新主库的备份中重新创建旧主库作为备库（就是要重搭DG了）。
② Fast-Start FailOver（FSFO，自动故障转移）
需要在Data Guard Broker中进行配置。当主数据库不可用时，DG Broker会将主库自动故障转移到预设的备库。
2. 注意事项
- 如果主库崩溃并且生成的归档日志还未复制到备库，则可能会丢失数据。
- Failover仅应在主库确实无法恢复或紧急情况下使用。
- 应将主库Failover到最新的备库（lag最小）
3. 故障转移前准备
以手动Failover为例，FSFO配置相对复杂，单独在后面文章介绍。
故障转移前建议处理主库尚未传送的日志，如果不介意丢数据，可以跳过这一步。
步骤1：如果主库还能到mount状态，执行以下命令将未发送redo全部发送到目标备库。如果不能，跳过该步。执行完后等待从库应用完所有redo日志，如果期间没有报错，直接跳到第4部分开始failover。
alter system flush redo to target_db_name;步骤2：检查目标备库接收到的最新归档日志号
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
THREAD LAST
---------- ----------
1 100如果主库服务器没有宕机，检查这个归档是不是主库最新的，如果不是，拷贝还未发送的归档日志到从库。
步骤3：检查目标备库是否有gap
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92如上示例缺少sequence numbers为90, 91, 92 for thread 1的归档，如果主库服务器没有宕机，建议拷贝到目标备库。
步骤4：在目标备库注册缺失的归档日志
alter database register physical logfile 'filespec1';4. 故障转移步骤
步骤1：停止目标备库日志应用
SQL> alter database recover managed standby database cancel;步骤2：完成备库日志应用
alter database recover managed standby database finish;
-- force选项，个人理解相当于前面提到的Immediate Failover
alter database recover managed standby database finish force;RECOVER MANAGED STANDBY DATABASE FINISH [FORCE][NOWAIT|WAIT] ]
- FINISH子句在目标备库上启动故障转移并恢复当前standby redo log files。仅在主数据库发生故障时使用FINISH子句，此子句覆盖任何延迟间隔。
- FORCE子句 终止 RFS 进程并允许立即执行故障转移，无需等待RFS进程退出。
- NOWAIT子句，立即返回控制，而不是在恢复过程完成后返回。
如果没有报错，执行下一步。
如果报错，可能归档存在gap，需要重新检查准备工作中归档日志是否都已拷贝到从库并进行注册。如果情况紧急来不及处理、或者主服务器已宕机、或者不介意丢数据，可以直接激活当前备库（ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;），但是此后主从关系将断开，需要重搭。
步骤3：检查备库状态
状态为TO PRIMARY或SESSIONS ACTIVE均可切换，SESSIONS ACTIVE说明还有活跃会话
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY步骤4：将备库切为主库
这个命令跟前面switchover其实是一样的，二者的差距在于failover前面多执行了一个 alter database recover managed standby database finish [force];
ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;步骤5：OPEN新主库
ALTER DATABASE OPEN;步骤6：检查新主库状态
SQL> select name,open_mode,database_role from v$database;
NAME OPEN_MODE DATABASE_ROLE
--------- -------------------- ----------------
MYTEST READ WRITE PRIMARY四、 Failover后恢复主从关系
这里介绍Failover后利用闪回恢复主从同步的方法，要求原主库（Failover后的备库）闪回功能必须打开并且闪回日志还在。利用DG Broker操作的方法放在下一篇介绍，其实原理是一样的，只是Oracle帮你做了。
假设当前failover已完成，新主库已打开。
在新主库上执行：
select to_char(standby_became_primary_scn) from v$database;
在原主库上，也就是现在的备库执行：
startup mount
flashback database to scn 9978113; --这个值为在新主库上查询到的SCN值
alter database convert to physical standby;
shutdown immediate
startup
alter database recover managed standby database using current logfile disconnect from session parallel 4;
至此，failover和其后的主从同步恢复已经完成，下一篇来看如何利用DG Broker来简化这些操作。
参考
Switchover and Failover Operations
SQL Statements Relevant to Data Guard
How To Open Physical Standby For Read Write Testing and Flashback (文档 ID 805438.1)
