查询视图V$DATABASE的DATABASE_ROLE列可以看到数据库当前的角色。
1．角色转换介绍
Oracle Data Guard让你可以使用SQL语句或者通过Oracle Data Guard broker界面来动态更改数据库的角色，Oracle Data Guard支持以下的角色转换：
1）Switchover
允许主数据库与其中一个备数据库转换角色。在正常切换过程中没有数据丢失。在正常切换后，每个数据库继续以新的角色参与Oracle Data Guard配置。
2）Failover
当主数据库出现故障时改变备数据库到主数据库的角色。如果主数据库在故障前不是运行在最大保护模式或最大可用模式，就会出现数据丢失。如果主数据库的闪回数据库功能被启用，故障的原因被纠正后，原主数据库可以重新以一个新主数据库的备数据库运行。
1.1. 准备角色转换
在角色转换之前，必须确认每个数据库已经正确地配置，备数据库上没有redo传输错误或redo gap。
1）确认每个数据库已经为将获得的角色正确地配置数据库初始化参数，归档模式，备redo日志，在线redo日志等。
注：在每个备数据库上定义LOG_ARCHIVE_DEST_n和LOG_ARCHIVE_DEST_STATE_n参数，这样当switchover或failover发生时，所有的备站点都继续从新的主数据库上接收redo数据。
2）在主数据库上查询视图V$ARCHIVE_DEST_STATUS确认备数据库没有redo传输错误或redo gap。
SQL> SELECT STATUS, GAP_STATUS FROM V$ARCHIVE_DEST_STATUS WHERE DEST_ID = 2;
STATUS GAP_STATUS
--------- ------------------------
VALID NO GAP
3）确认备数据库上的临时文件与主数据库上的匹配。
SQL> select FILE#,TS#,NAME,STATUS from v$tempfile;
4）移除将成为新主数据库的备数据库上可能在生效的应用redo的时间延迟。不移除这些延迟会导致更长的switchover时间，甚至会不允许进行switchover。
5）在执行switchover切换到在实时查询模式的物理备数据库前，考虑将备数据库的所有实例更改到mount而不是open状态来获得尽可能快的角色转换和干净地终止所有连接到物理备数据库的用户进程。
6）当从Oracle RAC主数据库执行switchover到物理备数据库时，不需要关闭其他只保留一个主数据库实例（it is not necessary to shut down all but one primary database instance）。
1.2. 选择一个角色转换的目标备数据库
对于配置了多个备数据库的Oracle Data Guard，在选择目标备数据库作为角色转换时有以下几方面的因素需要考虑：
1） 备数据库的位置
2） 备数据库的性能（硬件特性—例如CPU，IO带宽等）
3） 执行角色转换需要花费的时间。这受到备数据库在应用redo数据时的延后时间和平衡应用的可用性和数据丢失之间的灵活性等影响。
4） 备数据库类型
作为角色转换的目标数据库的类型决定了配置中其他的备数据库在角色转换之后是如何运行的。如果新的主数据库在角色转换前是物理备数据库，那么配置中所有其他备数据库将成为新主数据库的备数据库。如果新的主数据库在角色转换前是逻辑备数据库，那么配置中所有其他逻辑备数据库将成为新主数据库的备数据库，但是配置中的物理备数据库将继续是旧主数据库的备数据库，因此对新主数据库不提供保护。在后面这种状况中，将来switchover或failover回到原来的主数据库时将所有备数据库返回到最初的角色，作为当前主数据库的备数据库。由于以上所述的原因，物理备数据库通常是同时包含物理和逻辑备数据库配置中最佳的角色转换目标。
注：快照备数据库不能作为角色转换的目标。如果要使用快照备数据库作为角色转换的目标，首先要将它转换为物理备数据库，允许所有从主数据库接收到的redo应用到备数据库。
Oracle Data Guard提供视图V$DATAGUARD_STATS，可以评估每个备数据库的数据的现时性和如果所有可用的redo数据应用到备数据库，执行角色转换需要的时间。
SQL> COLUMN NAME FORMAT A24
SQL> COLUMN VALUE FORMAT A16
SQL> COLUMN DATUM_TIME FORMAT A24
SQL> SELECT NAME, VALUE, DATUM_TIME FROM V$DATAGUARD_STATS;
NAME VALUE DATUM_TIME
------------------------ ---------------- ------------------------
transport lag +00 00:00:00 02/21/2022 17:29:54
apply lag +00 00:00:00 02/21/2022 17:29:54
apply finish time +00 00:00:00.000
estimated startup time 30
1.3. Switchover（计划内切换）
Switchover主要用来在计划内停机时减少主数据库的关闭时间。计划内停机是操作系统或硬件升级，或数据库软件和补丁滚动式升级等事件。
Switchover分两个步骤进行。在第一个步骤中，当前的主数据库转换为备数据库角色；在第二个步骤中，备数据库转换为主数据库。
图9-1显示包含2个站点的Oracle Data Guard在数据库角色转换前的配置，主数据库是San Francisco，备数据库是Boston。
图9-2显示原主数据库转换为备数据库而原备数据库在成为新主数据库之前的Oracle Data Guard环境。在这个阶段，Oracle Data Guard配置临时拥有2个备数据库。
图9-3显示在发生切换后的Oracle Data Guard环境，原备数据库成为了新的主数据库，主数据库现在是Boston，备数据库是San Francisco。
为Switchover准备
确认“准备角色转换”章节的前提条件都已经满足，另外，以下switchover前提条件也必须符合：
1） 对于物理备数据库的切换，确认主数据库是打开状态，备数据库的Redo Apply是Active。
2） 对于逻辑备数据库的切换，确认主备数据库都处于打开状态，SQL Apply是Active。
1.4. Failover（故障切换）
Failover主要用于主数据库不可用时进行切换，而且不可能在合理的时间范围内恢复服务。
图9-4显示从主数据库San Franciso failover到备数据库Boston的结果。
为Failover准备
在执行failover前，尽可能地传输更多可用还未应用的主数据库redo数据到备数据库。
确认“准备角色转换”章节的前提条件都已经满足，另外，以下failover的前提条件也必须符合：
如果备数据库运行在最大保护模式，在备数据库上更改为最大性能模式：
SQL> ALTER DATABASE SET STANDBY DATABASE TO MAXIMIZE PERFORMANCE;
如果有合适的备数据库可用，可以在failover完成以后在新的主数据库上再重新设置需要的保护模式。
这是必须要执行的步骤，因为不能fail over到一个处于最大保护模式的备数据库。另外，如果在最大保护模式的主数据库正在活跃地与备数据库通讯，那么使用这个命令来更改保护模式将不会成功。因为failover会将原主数据库从Oracle Data Guard配置中移除，这个功能用来保护运行在最大保护模式的主数据库不被非计划地failover。
注意：不要fail over到备数据数来进行测试验证备数据库是否正确地进行了更新。
1.5. 角色转换触发器
当角色转换发生时会产生DB_ROLE_CHANGE系统事件，如果数据库在打开状态时，事件会马上发出，如果数据库在关闭状态，事件会在下次打开数据库时发生。
DB_ROLE_CHANGE事件可以用来在角色转换时触发执行一组行为。
2．物理备数据库角色转换
如果运行Oracle数据库12.1以后的版本，执行switchover或failover到物理备数据库的步骤已简化了。以前的步骤也支持（参考“Performing Role Transitions Using Old Syntax”），但Oracle建议使用新的步骤来进行切换。
在角色转换时让物理备数据库的会话保持连接
从Oracle 12.2.0.1版本开始，当物理备数据库转换为主数据库时，可以使用选项来使连接到物理备数据库的会话在switchover/failover过程中保持连接，不会中断。
备实例启动前在init.ora文件中设置STANDBY_DB_PRESERVE_STATES初始化参数，这个参数只适用物理备数据库，可以设置以下值：
1）NONE，用户会话或当前缓存在switchover/failover时不会保留，这是缺省值。
2）ALL，用户会话和当前缓存都在switchover/failover时会保留
3）SESSION，用户会话在switchover/failover时会保留
4）BUFFER，当前缓存在switchover/failover时会保留
2.1. 物理备数据库的正常切换（switchover）
按照以下步骤来执行switchover到物理备数据库：
1）确认目标备数据库已经处于切换就绪状态。
新的switchover语句有VERIFY选项用来执行检查各种switchover要求的条件。检查包括以下项目：Redo Apply是否在切换目标上运行；切换目标是否是12.1以后的版本；切换目标是否同步；切换目标是否有MRP运行。
假设主数据库的DB_UNIQUE_NAME是BOSTON，目标备数据库的DB_UNIQUE_NAME是CHICAGO。在主数据库BOSTON上，执行以下SQL语句确认切换目标CHICAGO是否准备好切换：
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO VERIFY;
ERROR at line 1:
ORA-16470: Redo Apply is not running on switchover target
如果操作成功，将会返回一条“Database Altered”信息，但在这个示例中返回一个ORA-16470错误。这个错误表示switchover目标CHICAGO没有准备好做切换。Redo Apply必须在切换前启动。在Redo Apply启动后，再执行以上语句：
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO VERIFY;
ERROR at line 1:
ORA-16475: succeeded with warnings, check alert log for more details
切换目标CHICAGO已经准备好做切换，但是ORA-16475错误的告警可能会影响切换性能。告警日志包含类似信息：
SWITCHOVER VERIFY WARNING: switchover target has dirty online redo logfiles
that require clearing. It takes time to clear online redo logfiles. This may
slow down switchover process
可以解决好问题或如果切换性能不重要，这些告警可以忽略。在做完必要的处理后，再次执行语句：
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO VERIFY;
Database altered.
切换目标已经准备好做切换。
2）在主数据库上发起切换；
SQL> ALTER DATABASE SWITCHOVER TO CHICAGO;
Database altered.
如果错误发生，mount起旧的主数据库（BOSTON）和旧的备数据库（CHICAGO）。在两个数据库上，查询视图V$DATABASE的DATABASE_ROLE，主备数据库有三种可能的数据库角色组合。下表描述了这些组合，提供了可能的原因和每种状况的修复动作。
| 主备数据库角色 | 原因和修复动作 |
|---|---|
| BOSTON是主数据库， CHICAGO是备数据库 | 原因：BOSTON数据库切换到备数据库角色失败 修复动作：检查alert告警日志中阻止BOSTON切换到备数据库的错误，执行相应的操作来解决错误，重新打开BOSTON数据库的一个实例，再次从步骤1执行切换过程 |
| BOSTON是备数据库， CHICAGO是备数据库 | 原因：CHICAGO数据库切换到主数据库角色失败 修复动作：执行下面的SQL语句来转换BOSTON或CHICAGO到主数据库 SQL> ALTER DATABASE SWITCHOVER TO target_db_name FORCE; 如果语句失败时报ORA-16473错误，那么必须在再次执行命令前启动Redo Apply。 启动Redo Apply： SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT; 重新执行切换命令： SQL> ALTER DATABASE SWITCHOVER TO BOSTON FORCE; |
| BOSTON是备数据库， CHICAGO是主数据库 | 原因：数据库已经成功转换成新的数据库角色，但在将最终成功状态报告给BOSTON时出现错误。 修复动作：继续执行下面的步骤 3来完成切换操作 |
3）在新的主数据库CHICAGO上打开数据库：
SQL> ALTER DATABASE OPEN;
4）MOUNT新的备数据库BOSTON：
SQL> STARTUP MOUNT;
或，如果BOSTON是Oracle Active Database Guard物理备数据库，那么以只读打开它：
SQL> STARTUP;
5）在新的备数据库上启动Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT FROM SESSION;
2.2. 物理备数据库的故障切换（failover）
按照以下步骤执行failover到物理备数据库：
1）如果主数据库可以被挂载，将没有被发送的归档和当前redo日志从主数据库flush到备数据库。如果这个操作成功，即使主数据库不在零数据丢失的保护模式，零数据损失failover是可能的。
首先，确保Redo Apply在目标备数据库是active。然后挂载，但不打开主数据库。如果主数据库不能挂载，跳到步骤2。
在主数据库上执行以下SQL语句：
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
对于target_db_name，指定备数据库的DB_UNIQUE_NAME。语句将没有发送的redo从主数据库flush到备数据库，然后等待redo应用到备数据库。
如果语句完成没有报任何错误，跳到步骤5。如果语句完成时报错，或因为不能等待更长的时间直到语句完成，必须停止，继续步骤2。
2）在目标备数据库上查询V$ARCHIVED_LOG视图获取每个redo线程的最高的日志序号。
SQL> SELECT UNIQUE THREAD# AS THREAD, MAX(SEQUENCE#) OVER (PARTITION BY THREAD#) AS LAST FROM V$ARCHIVED_LOG;
THREAD LAST
---------- ----------
1 76
2 59
如果可能，复制每个主数据库redo线程最近的归档redo日志文件到备数据库，然后注册。
SQL> ALTER DATABASE REGISTER PHYSICAL LOGFILE ‘filespec1’;
3）在目标备数据库上查询视图V$ARCHIVE_GAP确认在目标备数据库上是否存在redo gap。
SQL> SELECT THREAD#, LOW_SEQUENCE#, HIGH_SEQUENCE# FROM V$ARCHIVE_GAP;
THREAD# LOW_SEQUENCE# HIGH_SEQUENCE#
---------- ------------- --------------
1 90 92
在这个示例中，gap包括线程1序号90，91和92的归档redo日志文件。
如果可能，复制缺失的归档redo日志文件到目标备数据库并进行注册。
4）步骤3的查询只显示最高的gap。在处理完gap后，再次执行查询直到没有更多的行返回为止。
如果在执行完第2到第4步骤后，不能处理完所有归档redo日志文件的gap（如不能访问故障主数据库的系统），那么在failover过程中就会有数据丢失。
5）在目标备数据库停止Redo Apply。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE CANCEL;
6）在目标备数据库上，Failover到目标备数据库。
SQL> ALTER DATABASE FAILOVER TO target_db_name；
如果语句执行完成没有报错，跳到步骤9。
如果语句报错，继续步骤7。
7）如果报错，尝试解决报错的原因，然后重新执行语句。
如果成功，跳到步骤9。
如果错误还是发生，继续步骤8。
8）执行有数据丢失的failover。
如果无法解决错误，可以使用以下SQL语句执行failover：
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
9）打开新的主数据库：
SQL> ALTER DATABASE OPEN;
10）Oracle建议对新主数据库进行全备。
11）如果Redo Apply在Data Guard配置中的其他的物理备数据库上已经停止，重启它。
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
12）在failover后，使用闪回数据库（参考章节“在failover后使用闪回转换故障主数据库到备数据库”）或RMAN备份（参考章节“在角色转换后使用RMAN备份转换故障主数据库到备数据库”）可以将原主数据库可以转换成新主数据库的物理备数据库，或者使用新主数据库的备份来重新创建成为物理备数据库。
一旦原主数据库以备数据库角色运行，就可以执行switchover来恢复它的主数据库角色。
3．逻辑备数据库角色转换
注：逻辑备数据库不复制数据库服务。在切换到逻辑备数据库时，连接到主数据库服务的中间层将不能连接（因为创建的服务不被复制），或者连接到不正确的版本（因为修改的服务属性不被复制）。
Oracle集群件不复制它管理的服务到逻辑备数据库。必须手工在主备数据库间保持服务同步。
3.1. 逻辑备数据库的正常切换（switchover）
当在主数据库和逻辑备数据库之间执行switchover转换角色时，先在主数据库上发起switchover，再在逻辑备数据库上完成。
按照以下步骤来执行switchover到逻辑数据库：
1）在当前主数据库上，查询视图V$DATABASE的SWITCHOVER_STATUS列确认执行switchover是可能的：
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO STANDBY
列SWITCHOVER_STATUS的值TO STANDBY或SESSION ACTIVE预示主数据库切换到逻辑备数据库角色是可能的。如果不是这两个值，那么确认Oracle Data Guard的配置运行正常（例如，LOG_ARCHIVE_DEST_n参数设置正确）。
2）在主数据库执行以下SQL语句为当前主数据库准备逻辑备数据库角色：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO LOGICAL STANDBY;
语句通知当前主数据库它将很快切换到逻辑备数据库角色，开始从新主数据库接收redo数据。在主数据库上执行这个步骤准备接收记录在当前逻辑备数据库的redo流中的LogMiner字典。
如果操作成功，值PREPARING SWITCHOVER会显示在视图V$DATABASE的列SWITCHOVER_STATUS中。
3）在切换目标逻辑备数据库上使用以下语句建立LogMiner字典：
SQL> ALTER DATABASE PREPARE TO SWITCHOVER TO PRIMARY;
语句还在逻辑备数据库上启动redo传输服务，开始传输它的redo数据到当前主数据库和Oracle Data Guard配置中的其他备数据库。这些从逻辑备数据库接收redo数据的站点接受redo数据但不应用它。
当LogMiner字典开始记录到redo流时，在逻辑备数据库的列V$DATABASE.SWITCHOVER_STATUS初始时显示PREPARING DICTIONARY。当步骤成功完成时，SWITCHOVER_STATUS列显示 PREPARING SWITCHOVER。
4）在完成主数据库到逻辑备数据库角色的转换之前，查询视图V$DATABASE的列SWITCHOVER_STATUS来确认LogMiner字典已经被主数据库接收。如果没有收到LogMiner字典，switchover不能进行下去，因为当前主数据库必须要能解析未来主数据库发送的redo记录。
当查询返回TO LOGICAL STANDBY值时，可以继续步骤5。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO LOGICAL STANDBY
注：可以按顺序执行以下语句来取消switchover操作
a. 在主数据库上取消switchover
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
b. 在逻辑备数据库上取消switchover
SQL> ALTER DATABASE PREPARE TO SWITCHOVER CANCEL;
5）在主数据库执行以下SQL语句完成主数据库到逻辑备数据库的角色转换：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO LOGICAL STANDBY;
语句等待主数据库上的所有当前事务停止，禁止任何新用户启动新事务，为switchover提交建立一个时间点。
执行这个语句也禁止用户更改逻辑备数据库上维护的数据。为了确保更快的执行，确认主数据库在执行switchover语句前处于安静的状态（例如，让用户临时从主数据库注销）。可以查询视图V$TRANSACTION来获取当前进行的可能会延时语句执行的事务的状态。
主数据库现在经历到一个逻辑备数据库的角色转换。当主数据库经历到逻辑备数据库的角色转换时，不需要关闭和重启数据库。
6）在完成主数据库到逻辑备数据库的角色转换后，逻辑备数据库会收到switchover的通知。在逻辑备数据库上查询视图V$DATABAE的SWITCHOVER_STATUS列来确认switchover通知正在被目标备数据库处理。一旦所有可用的redo记录应用到了逻辑备数据库，在预料到预期的角色转换时，SQL Apply会自动关闭。
在switchover过程中SWITCHOVER_STATUS列的值会更新来显示进度。当状态是TO PRIMARY时，继续步骤7。
SQL> SELECT SWITCHOVER_STATUS FROM V$DATABASE;
SWITCHOVER_STATUS
-----------------
TO PRIMARY
7）在要切换为主数据库角色的逻辑备数据库上使用以下SQL语句切换逻辑备数据库到主数据库角色：
SQL> ALTER DATABASE COMMIT TO SWITCHOVER TO PRIMARY;
不需要关闭和重启Oracle Data Guard配置中的任何逻辑备数据库。如前面“选择一个角色转换的目标备数据库”所述，配置中的所有其他逻辑备数据库会成为新的主数据库的备数据库，任何物理备数据库依旧是原主数据库的备数据库。
8）在新的逻辑备数据库上，启动SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
3.2. 逻辑备数据库的故障切换（failover）
取决于配置的保护模式和redo传输服务的属性，可能可以自动恢复所有或部分主数据库的修改。
按照以下步骤执行failover到逻辑备数据库：
1）如果主数据库可以被挂载，将没有被发送的归档和当前redo日志从主数据库flush到备数据库。如果这个操作成功，即使主数据库不在零数据丢失的保护模式，零数据损失failover是可能的。
首先，确保Redo Apply在目标备数据库上是active。然后挂载，但不打开主数据库。如果主数据库不能挂载，跳到步骤2。
在主数据库上执行以下SQL语句：
SQL> ALTER SYSTEM FLUSH REDO TO target_db_name;
对于target_db_name，指定备数据库的DB_UNIQUE_NAME。语句将没有发送的redo从主数据库flush到备数据库，然后等待redo应用到备数据库。
2）取决于配置中组件的条件，你可能可以访问主数据库上的归档redo日志文件。如果这样，执行以下操作：
a. 确认在逻辑备数据库上是否缺失任何归档redo日志文件。
SELECT FILE_NAME, SEQUENCE# AS SEQ#, FIRST_CHANGE# AS F_SCN#, NEXT_CHANGE# AS N_SCN#, TIMESTAMP, DICT_BEGIN AS BEG, DICT_END AS END, THREAD# AS THR#, APPLIED FROM DBA_LOGSTDBY_LOG ORDER BY SEQUENCE#;
b. 从主数据库上拷贝缺失的日志文件到逻辑备数据库。
c. 注册拷贝的日志文件。
SQL> ALTER DATABASE REGISTER LOGICAL LOGFILE ‘filespec1’;
3）在目标逻辑备数据库上执行以下命令：
SQL> ALTER DATABASE ACTIVATE LOGICAL STANDBY DATABASE FINISH APPLY;
语句停止RFS（remote file server）进程，在逻辑备数据库成为主数据库之前应用备redo日志文件中的剩余的redo数据，停止SQL Apply，然后激活数据库为主数据库角色。
如果没有指定FINISH APPLY子语句，那么在当前备redo日志文件中的没有应用的redo将不会在逻辑备数据库成为主数据库之前被应用。
4） 按照以下章节“在故障切换后配置逻辑备数据库”描述的方法确认现存的逻辑备数据库可以继续为新主数据库提供保护。
5） 在failover后对新主数据库做全备。
6） 在failover后，使用闪回数据库（参考章节“在failover后使用闪回转换故障主数据库到备数据库”）或RMAN备份（参考章节“在角色转换后使用RMAN备份转换故障主数据库到备数据库”）可以将原主数据库可以转换成新主数据库的逻辑备数据库，或者使用新主数据库的备份来重新创建成为逻辑备数据库。
一旦原主数据库以备数据库角色运行，就可以执行switchover来恢复它的主数据库角色。
4 .在物理备数据库或逻辑备数据库故障切换后配置其它逻辑备数据库
在主数据库故障切换到另外一个备数据库后，这些步骤要求在逻辑备数据库上执行。
在故障切换发生后，逻辑备数据库不能作为新的主数据库的备数据库直到它应用了原主数据库的最后的redo为止。这与新主数据库在故障切换中应用了最后的redo的方式相似。必须执行的步骤取决于新主数据库在故障切换前是物理备数据库还是逻辑备数据库。
4.1. 当新主数据库原来是物理备数据库
这些步骤演示了如何配置逻辑备数据库来支持在获取主角色前是物理备数据库的新主数据库。
在这个场景中，SAT是逻辑备数据库，NYC是主数据库。
1） 在SAT数据库上，执行以下语句配置FAL_SERVER参数来启用自动恢复日志文件。
SQL> ALTER SYSTEM SET FAL_SERVER=‘<tns_name_to_new_primary>’;
SQL> ALTER SYSTEM SET FAL_CLIENT=‘<tns_name_to_local_database>’;
2）调用PREPARE_FOR_NEW_PRIMARY程序来确认逻辑备数据库能够作为新主数据库的备数据库服务。在这个步骤中，造成数据分歧风险的日志文件的本地拷贝会从本地数据库删除。这些日志文件然后直接从主数据库请求重新归档。
在SAT数据库上，执行以下语句：
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( former_standby_type => ‘PHYSICAL’ dblink => ‘nyc_link’);
注：如果返回消息ORA-16109和有告警“LOGSTDBY: prepare_for_new_primary failure – applied too far, flashback required.”写入到alert.log，执行以下步骤：
a. 闪回数据库到告警中说明的SCN；
b. 重新执行这个步骤。
3）在SAT数据库上，执行以下语句来启动SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
4.2. 当新主数据库原来是逻辑备数据库
这些步骤演示了如何配置逻辑备数据库来支持在获取主角色前是逻辑备数据库的新主数据库。
在这个场景中，SAT是逻辑备数据库，NYC是主数据库。
1）确认新主数据库已经准备好支持逻辑备数据库。在NYC数据库上，确认下面的查询返回值NONE。否则新主数据库还没有完成需要启用逻辑备数据库支持的工作。例如：
SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;
在尝试恢复旧主数据库前，值NONE必须被返回。
2） 在SAT数据库上，执行以下语句来配置FAL_SERVER参数来启动自动恢复日志文件：
SQL> ALTER SYSTEM SET FAL_SERVER=‘<tns_name_to_new_primary>’;
SQL> ALTER SYSTEM SET FAL_CLIENT=‘<tns_name_to_local_database>’;
3）调用PREPARE_FOR_NEW_PRIMARY程序来确认逻辑备数据库能够作为新主数据库的备数据库服务。在这个步骤中，造成数据分歧风险的日志文件的本地拷贝会从本地数据库删除。这些日志文件然后直接从主数据库请求重新归档。
在SAT数据库上，执行以下语句：
SQL> EXECUTE DBMS_LOGSTDBY.PREPARE_FOR_NEW_PRIMARY( former_standby_type => ’ LOGICAL ’ dblink => ‘nyc_link’);
注：如果返回消息ORA-16109和有告警“LOGSTDBY: prepare_for_new_primary failure – applied too far, flashback required.”写入到alert.log，执行以下步骤：
c. 闪回数据库到告警中说明的SCN；
d. 重新执行这个步骤。
4）在SAT数据库上，执行以下语句来启动SQL Apply：
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY
nyc_link;
语句必须不启用实时应用选项来执行。为了在逻辑备数据库上启用实时应用，等待以上语句成功完成，然后执行以下语句：
SQL> ALTER DATABASE STOP LOGICAL STANDBY APPLY;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY IMMEDIATE;
5．在角色转换后使用闪回
在角色转换后，可以选择使用FLASHBACK DATABASE命令来将数据库恢复到角色转换前的时间点或SCN。
如果闪回主数据库，那么必须闪回所有它的备数据库到相同的或早些的SCN或时间。当闪回主数据库或备数据库时，不需要管过去的switchover。只要SCN/时间早于过去的switchover，Oracle就能自动闪回跨越过去的switchover。
注：在角色转换发生前闪回数据库必须已经在数据库上启用。
5.1. 在switchover后使用闪回
在switchover之后，可以使用FLASHBACK DATABASE命令将数据库恢复到switchover前的时间点或SCN。
如果switchover涉及物理备数据库，在闪回操作中主备数据库的角色会保留。当数据库闪回到目标SCN或时间点时，数据库运行的角色不会更改。数据库在switchover后运行在物理备数据库角色但在闪回时间点之前是主数据库角色，在闪回数据库操作之后将仍然运行在物理备数据库角色。
如果switchover涉及逻辑备数据库，闪回会更改备数据库的角色到目标SCN或时间点时它所在的数据库角色。
5.2. 在failover后使用闪回转换故障主数据库到备数据库
在failover发生后，原主数据库不能再加入Oracle Data Guard的配置，直到它被修复和作为新配置的备数据库建立为止。
可以使用闪回将故障的主数据库恢复到在故障发生前的时间点，然后将它转换为新配置的备数据库。
5.2.1.闪回故障主数据库到物理备数据库
以下步骤将旧的主数据库作为物理备数据库恢复到Oracle Data Guard配置中。下面的步骤假设failover已经在物理备数据库上执行和在failover时闪回已经在旧的主数据库上启用。
1）在新主数据库上，查询确定旧备数据库变成新主数据库时的SCN：
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
2）关闭旧主数据库（如果需要），挂载它，闪回到前面步骤中确定的STANDBY_BECAME_PRIMARY_SCN的值。
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
SQL> FLASHBACK DATABASE TO SCN standby_became_primary_scn;
3） 在旧主数据库上转换数据库到物理备数据库：
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
4） 在新物理备数据库上启动redo传输，在新主数据库上执行以下步骤：
a. 执行以下查询查看归档目标的当前状态：
col dest_name format a20
col destination format a30
col error format a30
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
b. 如果需要，启用传输目标
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
c. 执行日志切换来确保备数据库开始从新主数据库接收redo数据，并确认redo发送成功。
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
5）在新物理备数据库上启动Redo Apply
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Redo Apply每次遇到角色转换产生的redo记录时就会自动停止，所以需要重新启动Redo Apply一次或多次直到它已经应用新主数据库变成主数据库时的SCN之后为止。
一旦故障主数据库恢复和运行在备数据库角色，可以选择执行switchover转换数据库到它原来（故障前）的角色。
5.2.2.闪回故障主数据库到逻辑备数据库
以下步骤将旧的主数据库作为新的逻辑备数据库恢复到Oracle Data Guard配置中，不必从新主数据库正式实例化来实现。
下面的步骤假设Oracle Data Guard配置已经在逻辑备数据库上完成failover和在failover时闪回已经在旧的主数据库上启用。
1）在新主数据库上，查询确定闪回SCN和恢复SCN。闪回SCN是故障主数据库闪回的SCN，恢复SCN是故障数据库恢复的SCN。在新主数据库执行以下查询确认这些SCN：
SQL> SELECT merge_change# AS FLASHBACK_SCN, processed_change# AS RECOVERY_SCN
FROM DBA_LOGSTDBY_HISTORY
WHERE stream_sequence# = (SELECT MAX(stream_sequence#)-1
FROM DBA_LOGSTDBY_HISTORY);
2）闪回故障主数据库到在前面步骤中确认的闪回SCN：
SQL> FLASHBACK DATABASE TO SCN flashback_scn;
3）转换故障主数据库到物理备数据库，重新挂载备数据库为恢复做准备：
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
4）配置参数FAL_SERVER来启动自动恢复日志文件。在物理备数据库（原故障主数据库）上执行以下命令：
SQL> ALTER SYSTEM SET FAL_SERVER=‘<tns_name_to_new_primary>’;
5）删除任何在failover过程中或之后从故障主数据库中创建的归档日志。如果故障主数据库与备数据库隔离，它可能会有与当前主数据库不一致的有分歧的归档日志。为了确保这些有分歧的归档日志决不会应用，必须从备份和快速恢复区域中删除。可以使用以下RMAN命令从快速恢复区域中删除相关的归档日志：
RMAN> DELETE FORCE ARCHIVELOG FROM SCN FLASHBACK_SCN;
一旦删除，这些有分歧的日志和随后的事务将不可能再恢复。
6）恢复直到步骤1中确定的恢复SCN：
SQL> RECOVERY MANAGED STANDBY DATABASE UNTIL CHANGE recovery_scn;
7）启动数据库保护
SQL> ALTER DATABASE GUARD ALL;
8）激活物理备数据成为主数据库：
SQL> ALTER DATABASE ACTIVATE STANDBY DATABASE;
9）打开数据库：
SQL> ALTER DATABASE OPEN;
10）创建一个到新主数据库的数据库链接，启动SQL Apply：
SQL> CREATE PUBLIC DATABASE LINK mylink
CONNECT TO system IDENTIFIED BY password
USING ‘service_name_of_new_primary_database’;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;
5.3．闪回逻辑备数据库到特定的应用SCN
备数据库的其中一个好处是闪回可以在备数据库上执行而不影响主数据库服务。闪回数据库到一个指定的时间点是一个直接明确的任务，然而，在逻辑备数据库上，可以闪回到一个正好在某个已知被提交的事务之前的时间。在failover后当配置一个新主数据库的逻辑备数据库时可能会出现这样的需求。以下步骤描述如何使用闪回数据库和SQL Apply来恢复到一个已知的应用SCN。
1）一旦在主数据库上确定了已知的SCN（APPLIED_SCN），在逻辑备数据库上查询确定相应的用来闪回操作的SCN。
SQL> SELECT DBMS_LOGSTDBY.MAP_PRIMARY_SCN (PRIMARY_SCN => APPLIED_SCN) -
AS TARGET_SCN FROM DUAL;
2）闪回逻辑备数据库到指定SCN，然后使用RESETLOGS选项打开逻辑备数据库：
SQL> SHUTDOWN;
SQL> STARTUP MOUNT EXCLUSIVE;
SQL> FLASHBACK DATABASE TO SCN <TARGET_SCN>;
SQL> ALTER DATABASE OPEN RESETLOGS;
3）查询确认SQL Apply已经应用小于或直到APPLIED_SCN：
SQL> SELECT APPLIED_SCN FROM V$LOGSTDBY_PROGRESS;
6．在角色转换后使用RMAN备份转换故障主数据库到备数据库
如果故障主数据库的闪回数据库功能没有启用，可以使用故障主数据库的本地备份转换故障主数据库到物理或逻辑备数据库。
6.1.使用RMAN备份转换故障主数据库到物理备数据库
步骤要求旧主数据库的COMPATIBLE初始化参数至少设置为11.0.0。
1）在新主数据库上，查询确定旧备数据库变成新主数据库时的SCN：
SQL> SELECT TO_CHAR(STANDBY_BECAME_PRIMARY_SCN) FROM V$DATABASE;
2）使用旧主数据库到达备数据库成为新主数据库的SCN（standby_became_primary_scn）前的备份还原数据库。然后，执行时间点恢复来恢复旧主数据库到相同的点。
RMAN> RUN
{
SET UNTIL SCN <standby_became_primary_scn + 1>;
RESTORE DATABASE;
RECOVER DATABASE;
}
对于用户管理的恢复，可以先手工还原数据库，然后使用以下命令恢复故障主数据库：
SQL> RECOVER DATABASE USING BACKUP CONTROLFILE UNTIL CHANGE <standby_became_primary_scn + 1>;
不像使用闪回数据库的重新实例化，这个步骤增加1到standby_became_primary_scn。对于数据文件，闪回到一个SCN是和恢复到SCN加1等同的。
3）将旧主数据库上转换到物理备数据库，然后重新挂载
SQL> ALTER DATABASE CONVERT TO PHYSICAL STANDBY;
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
4）以只读方式打开数据库:
SQL> ALTER DATABASE OPEN READ ONLY;
这个步骤的目标是使用目录检查来将控制文件与数据库同步。命令执行后，检查alert日志中是否有目录检查建议的行为。如果旧主数据库不是在failover过程中增加或删除数据文件的话，通常不需要用户介入。
5）如果已经购买Oracle Active Data Guard选项的授权和希望让物理备数据库运行在活动查询模式，跳过这个步骤。否则，将数据库切换到挂载状态：
SQL> SHUTDOWN IMMEDIATE;
SQL> STARTUP MOUNT;
6） 在新备数据库创建前，新主数据库可能已经停止向远程目标传输redo。在新主数据库上执行以下步骤重新启动redo传输服务。
a. 查看归档目标的当前状态：
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
b. 如果需要，启用传输目标：
SQL> ALTER SYSTEM SET LOG_ARCHIVE_DEST_STATE_n=ENABLE;
c. 执行日志切换来确保备数据库开始从新主数据库接收redo数据和确认redo发送成功。
SQL> ALTER SYSTEM SWITCH LOGFILE;
SQL> SELECT DEST_ID, DEST_NAME, STATUS, PROTECTION_MODE, DESTINATION, ERROR,SRL FROM V$ARCHIVE_DEST_STATUS;
7）在新物理备数据库上启动Redo Apply：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
一旦故障主数据库恢复和运行在备数据库角色，可以选择执行switchover转换数据库到它原来（故障前）的角色。
6.2.使用RMAN备份转换故障主数据库到逻辑备数据库
以下步骤描述如何使用RMAN备份将故障主数据库转换到逻辑备数据库。
1）在新主数据库上，查询和确定想恢复故障主数据库到的SCN：
SQL> SELECT APPLIED_SCN RECOVERY_SCN FROM V$LOGSTDBY_PROGRESS;
同样在新主数据库上，确定处理归档日志使用的SCN，如下：
a. 确保所有备redo日志已经被归档。发出以下查询，直到NONE值返回为止。取决于数据库的大小和需要归档的日志数量，在返回NONE状态之前可能要花费一些时间。
SQL> SELECT PENDING_ROLE_CHANGE_TASKS FROM V$DATABASE;
b.在返回NONE状态之后，执行以下查询获取作为恢复操作的一部分处理归档日志的SCN。
SQL> SELECT VALUE ARCHIVE_SCN FROM SYSTEM.LOGSTDBY$PARAMETERS
WHERE NAME=‘STANDBY_BECAME_PRIMARY_SCN’;
2）删除任何在failover过程中或之后从故障主数据库中创建的归档日志。如果故障主数据库与备数据库隔离，它可能会有与当前主数据库不一致的有分歧的归档日志。为了确保这些有分歧的归档日志决不会被应用，必须从备份和快速恢复区域中删除。可以使用以下RMAN命令从快速恢复区域中删除相关的归档日志：
RMAN> DELETE FORCE ARCHIVELOG FROM SCN ARCHIVE_SCN;
一旦删除，这些有分歧的日志和随后的事务将不可能再恢复。
3） 在新主数据库上，查询确定在从备份恢复前必须拷贝到故障主数据库上最少量的日志文件集：
SQL> SELECT file_name FROM DBA_LOGSTDBY_LOG WHERE next_change# > ARCHIVE_SCN;
检索要求的备日志，拷贝备份集到新备数据库上，然后还原到新备数据库的快速恢复区。因为这些日志来自备redo日志，他们不是备数据库的标准归档日志。RMAN可以使用部分文件名称来从正确的位置检索文件：
RMAN> BACKUP AS COPY DEVICE TYPE DISK FORMAT ‘/tmp/test/%U’
ARCHIVELOG LIKE ‘%’;
RMAN> CATALOG START WITH ‘/tmp/test’;
RMAN> RESTORE ARCHIVELOG FROM SEQUENCE 33 UNTIL SEQUENCE 35;
4）还原包含所有原主数据库的数据文件的备份，恢复到RECOVERY_SCN+1。Oracle建议充分利用当前控制文件。
a. 启动数据库到受限制模式，保护数据库不受意外的事务影响直到在打开数据库后可以执行GUARD ALL命令为止
b. 使用备份还原故障主数据库的数据文件
c. 关闭闪回数据库，如果它是启用的话（对于子语句USING BACKUP CONTROLFILE是必要的）
d. 在SQL*PLUS中执行时间点恢复到RECOVERY_SCN+1
不管是使用当前控制文件还是备份控制文件，必须指定子语句USING BACKUP CONTROLFILE来允许指向还原的归档日志。否则，恢复进程将会尝试访问在线redo日志而不是步骤3中检索到的日志。当提示步骤3中检索到的序列时，确保指定了还原的归档日志文件拷贝的文件名称：
SQL> RECOVER DATABASE UNTIL CHANGE RECOVERY_SCN + 1 USING BACKUP CONTROLFILE;
5）使用选项RESETLOGS打开数据库：
SQL> ALTER DATABASE OPEN RESETLOGS;
6）启动数据库保护
SQL> ALTER DATABASE GUARD ALL;
7）创建一个到新主数据库的数据库链接，启动SQL Apply：
SQL> CREATE PUBLIC DATABASE LINK mylink
CONNECT TO system IDENTIFIED BY password
USING ‘service_name_of_new_primary_database’;
SQL> ALTER DATABASE START LOGICAL STANDBY APPLY NEW PRIMARY mylink;
此时，可以停止限制会话（ALTER SYSTEM DISABLE RESTRICTED SESSION），或者如果需要重启数据库来重新启用步骤4c中禁用的闪回，让重启来关闭RESTRICTED SESSION。
来源：《Oracle Data Guard Concepts and Administration, 19c》
