Oracle 11.2.0.1 如何进行物理备用数据库角色切换及数据库故障转移

此文章根据Oracle官方Data Guard的翻译并进行了一些表述语言的调整，干货满满~

先少说两句，为什么需要主数据库与备用数据库角色的切换，例如需要对数据库进行升级操作。

根据需求需要手动切换（switchover）数据库的数据是不会丢失的。还有一种是failover，也就是主服务器挂挂了，这种情况就需要角色切换一下了。现在开始看看如何切换吧

1.    Data Guard配置由一个主要角色的数据库和一个或多个备用角色的数据库组成。 要查看数据库的当前角色，请查询V$DATABASE视图中的DATABASE_ROLE列。
在主数据库：
SQL>SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;
在物理备用数据库：
SQL>SELECT OPEN_MODE, DATABASE_ROLE, SWITCHOVER_STATUS FROM V$DATABASE;
2.    Data Guard配置中备用数据库的数量，位置和类型，以及将重做数据从主数据库传播到每个备用数据库的方式，决定了响应主数据库中断而可用的角色管理选项。
为角色过渡做准备
1.    开始角色转换前，请检查针对要承担的备用服务器角色的DG相关参数是否配置正确，并配置了ARCHIVELOG模式，以便能够正确的快速切换角色。
2.    查询主数据库的V$ARCHIVE_DEST_STATUS动态视图，以便验证备用数据库上没有重做传输错误或重做间隙。
例如，假设主服务器和备用服务器的配置是以LOG_ARCHIVE_DEST_2传输重做日志，以下查询将用于检查与LOG_ARCHIVE_DEST_2关联的备用数据库的状态：
在主数据库：
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
在备用数据库：
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;(在只读打开模式下，才会查询到结果)
    对于与备用数据库相对应的行，请直到STATUS列的值为VALID且GAP_STATUS列的值为NOGAP之后再继续。
    必须让主数据库和将要承担的备用服务器之间没有间隙（NO GAP）
    消除在重做数据库上应用重做上的任何延迟，这些重做将成为新的主数据库。
    在执行以实时查询模式切换到物理备用数据库之前，请考虑使该备用数据库的所有实例都处于已mount但未打开的状态，以实现尽可能快的角色转换并彻底终止与之连接的任何用户会话。角色过渡之前的物理备用数据库。
选择目标备用数据库以进行角色转换
1.    对于具有多个备用数据库的DG环境，在选择目标备用数据库进行角色转换的时需要考虑诸多条件因素，其中包括
    备用数据的位置
    备用数据的性能（包括硬件的规格，CPU数量，可用的I/O等）
    执行角色所需的时间，转换快慢受到重做数据落后多远以及权衡应用程序的可用性和数据丢失方面具有多少灵活性的影响
2.    查询V$DATAGUARD_STATS视图，该视图可用于根据备用数据库中数据的流通性以及如果将所有可用重做数据都应用于备用数据库中的角色转换所需的时间来评估每个备用数据库。 备用数据库。 例如：
在备用数据库：
SQL>SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;
NAME                   VALUE           DATUM_TIME
------------------------ ---------------- ------------------------
transport lag             +00 00:00:00      08/13/2020 19:56:25
apply lag                    +00 00:00:00      08/13/2020 19:56:25
apply finish time          +00 00:00:00.000
estimated startup time     6
该查询输出显示备用数据库已接收并应用了主数据库生成的所有重做（主数据库必需要open）。这些统计数据是使用截至08/13/2020 19:56:25从主数据库接收的数据计算得出的。
应用延迟和传输延迟度量是根据从主数据库接收的数据计算的。 如果主数据库和备用数据库之间的通信中断，这些指标将变得过时。 DATUM_TIME列中的“应用延迟”和“传输延迟”度量标准的不变值表示这些度量标准未更新且已过时，这可能是由于主数据库和备用数据库之间的通信故障所致。
切换（SWITCHOVER_STATUS）
1)    切换通常用于减少计划内停机期间的主数据库停机时间，如操作系统或硬件升级，或Oracle数据库软件和修补程序集的滚动升级
2)    切换分为两个阶段。 在第一阶段，现有的主数据库将过渡到备用角色。 在第二阶段，备用数据库将过渡到主要角色。
3)    涉及物理备用数据库的切换，请确认主数据库已打开，并且备用数据库上的“重做应用”处于活动状态。
SQL>ALTER DATABASE MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECTION FROM SESSION; --激活重做应用
故障转移（Failover）
如果可能，在执行故障转移之前，应将尽可能多的可用和未应用的主数据库重做数据传输到备用数据库。
故障转移通常仅在主数据库不可用时使用，并且不可能在合理的时间内将其恢复为服务状态。故障转移期间执行的特定操作会根据故障转移中涉及的是逻辑数据库还是物理备用数据库，故障转移时Data Guard配置的状态以及用于启动故障转移的特定SQL语句而有所不同。
如果故障转移涉及当前正在以最大保护模式运行的备用数据库，请通过在备用数据库上发出以下语句，首先将其置于最大性能模式：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
然后，如果有适当的备用数据库可用，则可以在故障转移完成之后在新的主数据库上重置所需的保护模式。
这是必需的，因为您无法故障转移到处于最大保护模式的备用数据库。
1.    物理备用数据库执行切换
在主数据库执行以下SQL
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
查询结果为TO STANDBY或SESSIONS ACTIVE的值表示可以将主数据库切换为备用角色。
2.    在主数据库上启动切换
在主数据库执行以下SQL：
SQL>ALTER DATABASE COMMIT TO SWITCHOVER TO PHYSICAL STANDBY WITH SESSION SHUTDOWN;
该语句将主数据库转换为物理备用数据库。切换之前，当前控制文件已备份到当前SQL会话跟踪文件。如果需要，这使得可以重建当前的控制文件。
3.    关闭并mount之前的主数据库，在Oracle数据库11g第2版（11.2.0.4）无需以下操作
SQL>SHUTDOWN ABORT;
SQL>STARTUP MOUNT;
4.    在备用数据库上验证是否已准备好将切换目标切换到主要角色。
SQL>SELECT SWITCHOVER_STATUS FROM V$DATABASE;
如果这两个值均未返回，请确认“重做应用”处于活动状态，并且重做传输已配置且工作正常。 继续查询此列，直到返回的值是TO PRIMARY或SESSIONS ACTIVE。
5.    将目标物理备用数据库角色切换为主角色。
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
6.    打开新的主数据库
SQL>ALTER DATABASE OPEN;
7.    在新的物理备用数据库上启动“重做应用”
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;-- 如果该命令执行失败请检查备用日志组是否创建
8.    如果它已在Data Guard配置中的任何其他物理备用数据库中停止，重新启动重做应用。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;--如果该命令执行失败请检查备用日志组是否创建
对物理备用服务器执行故障转移
1.    在新的备用数据库上开始重做应用，然后重新发出ALTER SYSTEM FLUSH REDO TO STANDBY语句，或者使用NO CONFIRM APPLY子句重新发出ALTER SYSTEM FLUSH REDO TO STANDBY语句。
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
2.    将所有未发送的重做从主数据库刷新到目标备用数据库
mount但不要打开主数据库，在主数据库上发送以下SQL语句
SQL>ALTER SYSTEM FLUSH REDO TO target_db_name;
对于target_db_name,指定备用数据库的DB_UNIQUE_NAME，该备用数据库从主数据库中清除重做。
该语句将所有未发送的重做从主数据库刷新到备用数据库，并等待将该重做应用于备用数据库。
3.    验证备用数据库具有每个主数据库重做线程的最新存档的重做日志文件
在目标备用数据库上查询V$ARCHIVED_LOG视图，以获取每个重做线程的最高日志序列号。
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#)OVER (PARTITION BY thread#) AS LAST from V$ARCHIVED_LOG;
如果可能，请将每个主数据库重做线程的最新存档重做日志文件复制到备用数据库（如果那里不存在），然后注册它。必须对每个重做线程执行此操作。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
4.    识别并解决所有存档的重做日志空白。
在目标备用数据库上查询V$ARCHIVE_GAP视图，以确定目标备用数据库上是否存在任何重做间隔。
SQL>SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
如果可能，请将所有丢失的已归档重做日志文件从主数据库复制到目标备用数据库，然后在目标备用数据库中注册它们。必须对每个重做线程执行此操作。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE 'filespec1';
5.    停止重做应用
在目标备用数据库上发出以下SQL语句
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
6.    完成应用所有收到的重做数据
SQL>ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
如果发生错误，则未应用某些接收到的重做数据。 尝试解决错误的原因，然后在继续下一步之前重新发出该语句。
中没有解决重做间隙，您将收到一条错误消息，指出存在重做间隙。
如果无法解决错误情况，则仍然可以通过在目标备用数据库上发出以下SQL语句来执行故障转移（有一些数据丢失）：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
7.    验证目标备用数据库已准备好成为主数据库。
在目标备用数据库上查询V$DATABASE视图的SWITCHOVER_STATUS列。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
TO PRIMARY或SESSIONS ACTIVE的值表示备用数据库已准备好切换到主要角色。 如果未返回这两个值，请确认“重做应用”处于活动状态，并继续查询该视图，直到返回“ TO PRIMARY”或“ SESSIONS ACTIVE”。
8.    将物理备用数据库切换为主要角色。
在目标备用数据库上发出以下SQL语句
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY WITH SESSION SHUTDOWN;
9.    打开新的主数据库
SQL>ALTER DATABASE OPEN;
10.    备份新的主数据库
Oracle建议对新的主数据库进行完整备份。
11.    SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE USING CURRENT LOGFILE DISCONNECT FROM SESSION;