故障转移注意事项

在故障转移操作期间，备用数据库转换为主角色并且旧的主数据库无法参与配置。
根据旧主数据库在故障转移之前运行的保护模式，故障转移期间可能会丢失一些数据或者没有数据丢失。

故障转移通常仅在主数据库变得无能为力并且不可能在合理的时间内执行切换或者成功修复主数据库时使用。

故障转移期间执行的特定操作会有所不同，具体取决于：

• 故障转移操作中是否涉及逻辑或者物理备用数据库
• 故障转移时的配置状态
• 用于启动故障转移的特定 SQL 命令

使用 DGMGRL 重新启用禁用的数据库

故障转移后，我们可能需要在配置中恢复或者重新创建数据库。
如果可以恢复数据库，则在完全故障转移后数据库具有以下状态：

ORA-16661: the standby database needs to be reinstated

注意：要恢复数据库，必须在故障转移之前在数据库上启用闪回数据库，并且闪回日志必须可用。

要恢复数据库：

1. 启动数据库实例并挂载数据库。

2. 在 oke DGMGRL 中并连接到新的主数据库 调用 DGMGRL 并连接到新的主数据库。

3. 使用 REINSTATE DATABASE DGMGRL 命令恢复数据库。

DGMGRL> REINSTATE DATABASE boston;

如果必须重新创建数据库，则故障转移后它具有以下状态：

ORA-16795: the standby database needs to be re-created

我们必须从主数据库的副本重新创建备用数据库，然后使用 ENABLE DATABASE DGMGRL 命令重新启用它。

DGMGRL> ENABLE DATABASE boston;

执行到物理备用数据库的故障转移

在故障转移操作期间，选定的备用数据库转换为主角色。
故障转移目标（物理备用数据库）重新启动。
操作完成后，Data Guard 概览页面会反映更新的配置。

完成或者立即故障转移后，可能需要恢复或者重新创建主数据库和一些备用数据库。
要恢复数据库，请单击“必须恢复数据库”链接。
然后单击“常规属性”页面上的“恢复”。
Enterprise Manager 将数据库恢复为新的主数据库的备用数据库。

注意：在故障转移之前，必须在数据库上启用闪回数据库，并且该数据库上必须有所需的闪回日志才能成功恢复。
此外，要恢复的数据库和新的主数据库必须具有网络连接。
本类稍后将介绍闪回数据库。

准备使用 SQL 进行切换

在执行 SWITCHOVER 命令之前，请验证是否在主数据库上配置了备用重做日志文件。
主数据库和任何物理备用数据库上的备用重做日志配置应该相同。
即使当数据库处于主要角色时不使用备用重做日志，建议在主数据库上配置备用重做日志，以准备最终的切换操作。

对于涉及物理备用数据库的切换，请验证主数据库是否已打开并且重做应用在备用数据库上是否处于活动状态。
对于涉及逻辑备用数据库的切换，验证主数据库实例和备用数据库实例都已打开并且 SQL 应用处于活动状态。

LOG ARCHIVE DEST LOG_ARCHIVE_DEST_n 参数的VALID FOR VALID_FOR 子句可以为主数据库角色和备用数据库角色配置。
通过预先为每个角色创建单独的目的地，在切换时不需要调整参数。

使用 Enterprise Manager 执行切换

用于切换时，企业管理器：
a)
检查以确保主数据库和备用数据库当前未处于错误状态，并且主数据库的代理管理已启用且在线
湾在切换期间自动关闭连接到主数据库的所有活动会话
C。
先把主库改成备角色，再把备库改成主角色
d.如果目标数据库是挂载的物理备用数据库，则打开目标数据库并重新启动以前的主数据库。

要使用 Enterprise Manager 启动切换：

• 在 Data Guard 页面上，选择要成为主数据库的备用数据库。
• 单击切换。如果我们尚未登录备用数据库，则可能会出现凭据页面。显示 Data Guard 切换确认页面
• 单击浏览主数据库会话链接以查看活动会话。
• 单击“是”继续切换，单击“否”取消。切换操作开始后将无法取消。

Data Guard 切换处理页面显示切换操作的进度，如下所示：

• 在主备库之间切换角色（如果切换目标是物理备库并挂载，则无需重启即可打开。重启之前的主库。）
• 等待 Data Guard Broker 完成切换数据库角色所需的初始化任务

我们可以通过单击相应的“查看警报日志”链接来查看主数据库和备用数据库的数据库警报日志。
一个新的浏览器窗口将打开，其中包含警报日志的内容。
切换操作完成后，我们将返回到 Data Guard 页面。

切换到逻辑备用数据库时的注意事项

• 与切换到物理备用数据库不同，切换到逻辑备用数据库不需要关闭主数据库。
• 如果要切换到逻辑备用数据库，则不需要终止连接到当前主数据库或者逻辑备用数据库的应用程序，因为在切换操作期间，这两个数据库都没有关闭。但是，由于旧主数据库上的会话在切换操作完成并打开数据库防护后可能会失败，因此我们现在应该终止此类打开的会话。数据库保护防止用户在逻辑备用数据库中进行更改。
• 如果我们切换到逻辑备用数据库，请注意我们可能没有所有数据 如果我们切换到逻辑备用数据库，请注意如果逻辑备用数据库只是主数据库的一个子集。
• 切换到逻辑备用数据库会使配置中的所有物理和快照备用数据库失效并禁用。我们必须从新主数据库的备份中重新创建物理备用数据库，然后才能重新启用它们。

使用企业管理器执行故障转移

仅在发生导致主数据库丢失的软件或者系统故障时才执行故障转移。
失败的主数据库被代理禁用，必须恢复或者重新创建。
然后备用数据库承担主数据库角色。

要使用企业管理器启动故障转移：

1. 在Data Guard 页面上，选择要成为主数据库的备用数据库。

2. 单击故障转移。

3. 在 Data Guard Failover Confirmation 页面上，指定要执行的故障转移类型：

• 完成：所有可用的重做都应用于备用数据库。 Oracle Corporation 建议我们指定这种类型的故障转移。
• 立即：没有在备用数据库上应用另外的数据，导致数据丢失故障转移。仅当不可能进行完全故障转移时才应使用立即故障转移。

4. 选择故障转移选项，然后单击是确认故障转移操作。

单击 Yes 后，Failover Processing 页面将显示故障转移操作的进度。
此操作开始后无法取消。

切换：之前

例如，假设主数据库位于旧金山，物理备用数据库位于波士顿。
切换仅在主数据库上启动并在目标备用数据库上完成。
我们可以通过DGMGRL 连接到配置中的任何数据库来执行SWITCHOVER 命令。

执行到逻辑备用数据库的故障转移

当我们执行到逻辑备用数据库的故障转移时，配置中的任何物理备用数据库在故障转移后永久禁用并且不再可用。
这些数据库必须从新的主数据库重新创建。

切换：之后

切换完成后，每个数据库的角色与切换前的角色相反。
在这个例子中，波士顿现在是主数据库，旧金山是备用数据库。

由于 Data Guard 不会自动将会话从一个数据库切换到另一个数据库，因此每个系统的活动会话都需要重新连接。
有关配置自动方法以重新连接会话的信息，请参阅标题为“Data Guard 环境中增强的客户端连接”的类。

切换

切换操作将主库转换为备角色，将备库转换为主角色，无需重置新主库的联机重做日志。

切换操作开始时的主数据库需要关闭并重新启动。
物理备用数据库在切换期间不会关闭和重新启动。
如果物理备用数据库处于 Active Data Guard 模式，它会关闭以进行转换，然后在切换完成后再次打开，但绝不会完全关闭以要求重新启动。

如果切换操作涉及逻辑备库，则无需关闭和重新启动主库或者任何备库。
逻辑备用数据库不需要关闭和重新启动。

注意：必要时，代理会自动启动和停止主数据库的 Real Application Clusters (RAC) 环境中除一个实例之外的所有实例。
如果不使用代理，则必须手动完成。
物理备库的辅助RAC实例在切换过程中不需要关闭。
它们可以保持在已安装或者 Active Data Guard 状态。
主 y gg 仍然只需要在切换期间运行一个实例

使用 DGMGRL 执行切换

确认执行切换所需的条件后，执行SWITCHOVER命令进行切换操作。

DGMGRL> SWITCHOVER TO 'london';
Performing switchover NOW, please wait...
Operation requires a connection to instance "london" on 
database "london"
Connecting to instance "london"...
Connected as SYSDG.
New primary database "london" is opening...
Operation requires startup of instance "boston" on 
database "boston"
Starting instance "boston"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "london"

Data Guard 代理执行以下操作：

• 验证主数据库和目标备用数据库处于正确状态
• 根据需要关闭任何实例
• 在主数据库和备用数据库之间切换角色
• 使用新角色信息更新代理配置文件
• 在运行重做应用的情况下重新启动新的备用数据库（以前的主数据库）
• 以读/写方式打开新的主数据库 以读/写模式打开新的主数据库并启动重做传输服务

角色管理服务

在 Data Guard 配置中，数据库以两个互斥角色之一运行：

1. 主要角色
2. 备用角色（物理、逻辑、快照子类型）

我们可以使用角色管理服务动态更改主角色和备用角色，作为称为切换操作的计划转换，或者作为数据库故障通过故障切换操作的结果。
例如，我们可能执行切换操作以将主数据库转换为备用角色，并将备用数据库转换为主角色以执行日常维护任务。

阻止切换的情况

如果出现以下情况，我们将无法执行切换：

• 归档重做日志文件不可用：如果备用数据库上的归档重做日志文件存在间隙，则无法切换到该备用数据库
• 需要时间点恢复：当我们执行到备用数据库的切换时，我们总是会切换到主数据库的当前状态。你不能切换到过去的时间
• 主数据库未打开且无法打开：在主数据库处于打开状态时启动了切换。如果无法打开主数据库，则无法进行切换

角色转换：切换和故障切换

切换

我们可以使用切换功能将主数据库的角色切换到可用的备用数据库之一。
选择的备库成为主库，原来的主库成为备库。
无需重新创建切换操作中涉及的任何数据库。
切换成功后，原主库和新主库之间不存在数据分歧。

故障转移

当主数据库发生故障并且无法及时恢复主数据库时，我们将调用故障转移操作。
在故障转移操作期间，备用数据库承担主数据库角色。
我们在要故障转移到主要角色的备用数据库上调用故障转移操作。

注意：我们可以启用快速启动故障转移以在主数据库不可用时自动进行故障转移。
当启用快速启动故障转移时，broker 会判断是否需要进行故障转移，并自动启动故障转移到指定的目标备用数据库，无需 DBA 干预，不丢失数据详情请参阅自动，无需 DBA干预且不会丢失数据。

使用 SQL 执行切换

1. 验证目标备库是否准备就绪：

SQL> ALTER DATABASE SWITCHOVER TO 'london' VERIFY;
Database altered.

2 在主数据库上启动切换：

SQL> ALTER DATABASE SWITCHOVER TO 'london';
Database altered.

3. 打开新的主数据库。

4. 挂载新的物理备用数据库。

5. 在新的物理备用数据库上启动重做应用。

SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE DISCONNECT;
Database altered.

不使用 Data Guard 代理时，切换将需要发出多个命令。
必须通过分别连接到每个实例来适当地启动切换中涉及的每个数据库（备用数据库为 MOUNT，主数据库为 OPEN READ WRITE）。
如果考虑到角色会发生变化而没有创建参数文件或者服务器参数文件，则可能需要相应地调整参数。

故障转移的类型

可以通过 Enterprise Manager、DGMGRL 或者 SQL 调用手动故障转移。
有两种类型的手动故障转移：

• 完成：恢复保护模式的最大重做数据量。在这种类型的故障转移中，代理避免禁用不是故障转移目标的任何备用数据库。完全故障转移是默认和推荐的故障转移类型。
• 立即：调用故障转移后，不会将另外的重做数据应用到备用数据库。这是最快的故障转移类型。立即故障转移后，我们必须重新创建或者恢复原始主数据库和所有不是故障转移目标的备用数据库。

注意：我们应该始终尝试执行完整的故障转移。
仅当完全故障转移不成功时才执行立即故障转移。
根据重做传输服务的目标属性，可以发生完整的故障转移而不会导致任何数据丢失，而立即故障转移通常会导致数据丢失。

我们可以配置快速启动故障转移，以便在主数据库丢失时代理自动故障转移到选定的备用数据库。

使用 DGMGRL 验证数据库的切换

VALIDATE DATABASE 命令在角色更改之前执行一组全面的数据库检查。
检查使用各种 Oracle Data Guard 视图以及自动诊断信息库中可用的信息。
VALIDATE DATABASE 命令显示数据库的简要摘要并报告检测到的任何错误或者警告。
VALIDATE DATABASE VERBOSE 显示简要摘要中的所有内容以及已验证的所有项目。
在执行切换之前，应对主数据库和备用数据库执行 VALIDATE DATABASE 命令。
针对物理备用数据库的详细输出示例如下：

DGMGRL> validate database verbose london
  Database Role:    Physical standby database
  Primary Database: boston
  Ready for Switchover: Yes
  Ready for Failover:   Yes (Primary Running)
  Capacity Information:
     Database Instances Threads
     boston    1          1
     london    1          1
 Temporary Tablespace File Information:
    boston TEMP Files: 3
    london TEMP Files: 3

 Flashback Database Status:
   boston: Off
   london: Off
 Data file Online Move in Progress:
   boston: No
   london: No
 Standby Apply-Related Information:
 Apply State: Running
 Apply Lag:   0 seconds
 Apply Delay: 0 minutes
 Transport-Related Information:
  Transport On:   Yes
  Gap Status:     No Gap
  Transport Lag: 0 seconds
  Transport Status: Success
 Log Files Cleared:
   boston Standby Redo Log Files: Cleared
   london Online Redo Log Files: Cleared
 Current Log File Groups Configuration:
   Thread # Online Redo Log Groups    Standby Redo Log Groups
          (boston)                      (london)
    1        3                             2
 Future Log File Groups Configuration:
   Thread # Online Redo Log Groups Standby Redo Log Groups
          (london)                      (boston)
   1         3                             0 

 Current Configuration Log File Sizes:
  Thread # Smallest Online Redo    Smallest Standby Redo
        Log File Size               Log File Size
          (boston)                   (london)
  1         50 MBytes                50 MBytes
  Apply-Related Property Settings:
   Property         boston Value         london Value
   DelayMins         0                      0        
   ApplyParallel    AUTO                   AUTO
 Transport-Related Property Settings:
   Property         boston Value        london Value
   LogXptMode        ASYNC                ASYNC
   Dependency                     
   DelayMins           0                    0
    Binding        optional             optional
   MaxFailure          0                    0
   MaxConnections      1                    1
   ReopenSecs         300                   300
   NetTimeout         30                     30
   RedoCompression   DISABLE             DISABLE
    LogShipping        ON                  ON

Automatic Diagnostic agnostic Repository Errors: 
Error                   boston   london
No logging operation       NO      NO
Control file corruptions   NO      NO
SRL Group Unavailable      NO      NO
System data file missing   NO      NO
System data file corrupted NO      NO
System data file offline   NO      NO
User data file missing     NO      NO
User data file corrupted   NO      NO
User data file offline     NO      NO
Block Corruptions found    NO      NO

使用 DGMGRL 执行手动故障转移

1、执行FAILOVER命令，启动对备库的故障切换操作：

DGMGRL> FAILOVER TO 'london' [IMMEDIATE];

2.重置保护模式（如有必要）。

3. 恢复或者重新创建以前的主数据库作为配置中的备用数据库。

4. 在配置中恢复或者重新创建其他禁用的备用数据库。

确定主库无法及时恢复后，执行FAILOVER命令进行故障切换操作。

如果我们指定 IMMEDIATE 选项，则不会尝试应用任何未应用的重做 如果我们指定 IMMEDIATE 选项，则不会尝试应用已收到的任何未应用的重做。

Data Guard 代理为完整的故障转移执行以下操作：

1. 验证目标备用数据库是否已启用。

2. 将所有未应用的重做数据应用到目标备库后，停止重做应用。

3. 通过以下方式将目标备用数据库转换为主数据库角色：

• 以读/写模式打开新的主数据库 以读/写模式打开新的主数据库。
• 确定是否需要恢复或者重新创建任何备用数据库。
• 启动重做传输服务。

对于立即故障转移，代理不会等待应用所有可用的重做数据（如步骤 2 中所述）。

故障转移

当主数据库发生故障并且无法及时恢复主数据库时，我们将调用故障转移操作。
在故障转移操作期间，主数据库在 Data Guard 环境中被禁用，备用数据库承担主数据库角色。
故障转移到备用数据库是一种单向操作。
我们不能“回退”并将数据库恢复到其以前作为备用数据库的角色。
因此，我们应该只在紧急情况下调用故障转移操作。

并不总是需要故障转移到备用数据库。
在某些情况下，主数据库的恢复可能会更快。
大多数故障可以在合理的时间内在主数据库中解决。

在故障转移操作中：

• 假定原始主数据库已丢失。 （如果需要，我们可以将原始主数据库恢复或者重新创建为新的备用数据库。然后，我们可以启动与故障转移操作相比的切换操作，以将数据库恢复到其原始角色。）
• 在故障转移操作时处于联机状态但不参与角色转换的备用数据库，除非由于应用滞后情况的差异而领先于故障转移目标，否则不需要关闭和重新启动。在这种情况下，它们可能需要闪回到备用数据库成为主数据库或者重新创建的位置。