数据库容灾的设计与实现（三）

四、FSFO 实现故障自动切换

Data Guard为我们提供了一套高可用的解决方案，但是在实际的使用方面确实显得有一些过于复杂，特别是在需要配置的多台Standby机器的情况下更是如此，需要登录每一台服务器进行配置，显得异常繁琐；在需要做Switchover或者是Failover 的时候情况也是一样，需要操作一系列的命令才能完成一次Switchover/Failover的操作，这种切换是比较复杂和费时的，而且在紧急情况下还会有切换失败导致数据丢失的风险。

从Oracle10GR2开始，在Data Guard的基础上，Oracle提供了Fast-Start Failover（FSFO）技术，通过使用该项技术简化Data Guard复杂的管理过程，采用集中化的统一管理，使得容灾系统在切换过程中实现完全自动化，保证数据的绝对安全性，完全媲美应用级容灾系统的功能。

（一）FSFO 环境的主要组件

FSFO构建于众多其他 Oracle 技术和特性如 Data Guard、flashbak database闪回数据库和Data Guard Broker之上。

1. Data Guard

FSFO 的基础是 Data Guard — 一个Primary数据库和至少一个Standby数据库。Standby数据库可以是物理的或逻辑的，可以有多个Standby数据库，但只有一个Standby数据库可作为随时进行故障切换的目标。以下段落将描述受支持的可用性模式。

（1）最高可用性模式（Oracle 数据库 10g 第 2 版及更高版本）

在最高可用性模式中，FSFO保证在故障切换期间不会丢失已收到提交确认的事务。该保证的代价是增加提交延迟（log file sync 等待事件）。最高可用性模式使用同步REDO传输，FSFO则增加了额外要求，即REDO应记录在目标Standby数据库（log_archive_dest_n 的 AFFIRM 选项）的备用REDO日志 (SRL) 中。往返的网络延迟增加了总体提交延迟。增加的延迟降低了吞吐量；然而，有些时候吞吐量的差异是由增加的并行造成的。

虽然REDO传输是同步的，但如果Standby数据库由于某种原因（如Standby数据库的主机或网络故障）不可用，最高可用性模式会保持Primary数据库可用。如果在用户指定的时间段（log_archive_dest_n 的 NET_TIMEOUT 选项）之后，Primary数据库无法联系到Standby数据库，它将退出同步传输模式并开始像在最高性能模式中一样进行操作。当Standby数据库再次可用时，Primary数据库和Standby数据库重新同步并恢复同步重做传输。

（2）最高性能模式（Oracle 数据库11g第1版及更高版本）

Oracle 数据库11g  FSFO 增加了对最高性能模式的支持（异步重做传输），提交延迟不受REDO传输的影响，但Standby数据库未收到其重做的已提交事务将在故障切换期间丢失。通过指定故障切换期间丢失事务的最大允许时间，最高性能模式中的 FSFO 配置可以限制潜在的数据丢失。例如，如果指定的限定值为 30 秒（默认），FSFO 将保证在故障切换期间保存 30 秒钟内提交的所有事务，最小允许限定值为 10 秒钟。

2. Data Guard Broker

Broker 是一个 Data Guard 管理实用程序，用于维护有关Primary数据库及其Standby数据库的状态信息。 它自动设置与 Data Guard 相关的数据库初始化参数（如实例启动和角色转换)、启动Standby数据库的应用服务，并且自动执行与维护 Data Guard 配置相关的许多管理任务。FSFO是 Broker 的一个特性，用于记录故障切换目标的相关信息，例如，故障发生后到触发故障切换之间的等待时间以及 FSFO 的其他特有属性。

3. Flashback Database

Flashback Database（闪回数据库）[15]是一个集成在 Oracle 数据库中的持续数据保护 (CDP) 解决方案。它使用名为闪回日志的磁盘数据结构，提供一个将数据库快速恢复到之前时间点或 SCN 的方法。数据库闪回比传统的时间点或基于 SCN 的恢复速度更快、结合更完美。FSFO 将闪回数据库用作将故障Primary数据库恢复为Standby数据库流程的一部分。

自动恢复的问题通常因为错误的配置，因此我们来了解一些详细信息。

闪回数据库记录经过更改的数据块的前映像。为了避免记录每个数据块的每次更改的开销，闪回数据库每30分钟进行一次快照，仅记录前映像块上一次快照后的第一次更改。在同一快照期间中，不再记录对同一数据块的后续更改。

数据库的闪回分成两个阶段：

（1）恢复。闪回数据库将数据文件恢复到指定 SCN 前最近的快照。这可以与执行从指定 SCN 前的备份进行数据文件 RMAN 恢复相比，但是速度更快。

（2）介质恢复。恢复完成后，恢复将作为典型介质恢复继续进行，根据归档REDO日志和联机REDO日志应用重做并通过撤消回滚未提交的更改。这意味着为了使闪回数据库操作成功，闪回数据库需要在快照时间和恢复 SCN 之间生成的所有存档重做日志（通常为重做后的 30 分钟）。可以使用V$RECOVERY_PROGRESS 视图监视恢复状态。

对于 FSFO 环境，设置数据库参数fashback_retention_target = 60 或更高值，可以为原故障主库自动恢复为Standby库提供足够的闪回数据库历史记录。快照的元数据存储在闪回日志本身中。如果没有元数据，Oracle 将无法找到快照，从而无法进行闪回。为了避免计时差异产生的问题，此参数的值不少于 60 分钟，实际上，如果值设置为 30 或 30 以下，肯定会导致闪回数据库故障。

闪回数据库将日志存储在快速恢复区 (FRA) 中，所以 FRA 必须有足够大的空间来存储至少60分钟的闪回数据库历史记录。总的存储需求与快照期间更改的数据块的数量成比例，例如，一小组数据块上的 1,000,000 次块更改生成的闪回数据库历史记录小于一大组数据块上的 1,000,000 次块更改所生成的闪回数据库历史记录。确定闪存数据库存储需求的一个好方法是，启用闪存数据库并观察其在几次峰值负载时所使用的存储量。通过启用闪回数据库来确定其存储需求也有一定的风险 ，如有必要，在Primary数据库处于打开状态时可以将其禁用。然而，重新启用闪回数据库将需要回弹，因为数据库必须进行mount且未打开。

4. FSFO 观察器

观察器是非常典型的主/备用 Data Guard 配置中的第三方。它实际上是一个内置 DGMGRL CLI（Data Guard Broker 命令行界面）中、占用空间很小的 OCI 客户端[19]，与其他所有客户端一样，可以运行在与数据库服务器不同的硬件平台上。其主要工作是在条件允许时执行故障切换，而不影响 DBA 设置的数据持久性约束条件。只有观察器能启动 FSFO 故障切换。它的另一个工作是在启用该特性的情况下自动将发生故障的Primary数据库恢复为Standby数据库。观察器是 Data Guard 故障切换在强健的高可用性解决方案中承担重要角色的关键因素，也是造成 Data Guard 故障切换在FSFO 出现前后重大差异的关键因素。

FSFO观察器版本必须与数据库版本匹配。Oracle 数据库 11g 观察器与 10g 数据库不兼容，Oracle 数据库 10g 观察器与 11g 数据库也不兼容。

（二）FSFO切换的条件

默认情况下，当全部满足以下条件时，观察器才会启动到目标Standby数据库的故障切换。

（1）观察器正在运行

（2）观察器和Standby数据库均与Primary数据库失去联系 。

（3）观察器仍然保持与Standby数据库的联系

（4）满足持久性约束条件

（5）故障切换阈值延时已过

下面数据库方面的任一条件会出触发Primary数据库与Standby数据库切换

（1）数据库实例失败（非RAC环境）

（2）使用shutdown abort命令对主库进行关闭（非RAC环境）

（3）由于IO错误导致数据文件脱机即Datafile Offline

下面的网络条件同时满足会触发Primary数据库与Standby数据库切换

1. 观察器和Standby数据库均与Primary数据库失去联系
2. Standby数据库确认处于synchronized状态
3. 观察器和Standby数据库保持联系

（三）FSFO自动故障切换的实现

本文使用一个物理Standby数据库。FSFO 还可以与逻辑Standby数据库结合使用，支持 FSFO 的配置可有多个Standby数据库，包括混合的物理数据库和逻辑数据库，但只有一个Standby数据库可随时作为故障切换目标。

下面实施过程中，数据库主机仍为P590和P720主机，数据库本身称为orajy和orajy_std数据库。观察器主机是orajyobserver其他信息见下表。

表 4-1 运行条件假设

数据库名称	Orajy
数据库唯一名称	orajy Orajy_std
主机名	P590 P720 orajyobserver
TNS 别名	orajy orajy_std

1.配置 Oracle Net

Data Guard 使用 Oracle Net (SQL*Net) 在Primary数据库和Standby数据库以及 FSFO 观察器之间进行通信。正确配置 Oracle Net 是成功部署 FSFO 的一个关键因素。错误的 Oracle Net 配置是导致FSFO失败问题的主要原因。

（1）配置监听器

针对应用程序连接和 Data Guard 连接使用不同的监听器是很好的做法。 这样，Data Guard可以在应用程序监听器因进行维护而停止工作时保持运行。请确保在 local_listeners 数据库参数中包括 Data Guard 监听器。

大多数在 FSFO 环境中使用的网络服务可使用动态注册，但要在角色转换期间或故障切换后的恢复期间启用Broker 以重新启动实例，您必须定义一个名为 db_unique_name_dgmgrl.db_domain 的静态服务。

针对主机p590的 listener.ora 配置：

LISTENER_DG =

  (DESCRIPTION=

    (ADDRESS_LIST=

      (ADDRESS=(PROTOCOL=tcp)(HOST=10.79.20.51)(PORT=1522))

    )

  )

SID_LIST_LISTENER_DG=

  (SID_LIST=

    (SID_DESC=

      (SID_NAME=orajy)

      (SDU=32767)

      (ORACLE_HOME=/app/oracle/product/10.2.0/db)

      (GLOBAL_DBNAME=orajy_static)

    )

    (SID_DESC=

      (SID_NAME=orajy)

      (SDU=32767)

      (ORACLE_HOME=/app/oracle/product/10.2.0/db)

      (GLOBAL_DBNAME=orajy_dgmgrl)

    )

  )

在实际环境中db_domain没有设置，为空。

针对主机b的 listener.ora 配置：

LISTENER_DG =

  (DESCRIPTION=

    (ADDRESS_LIST=

      (ADDRESS=(PROTOCOL=tcp)(HOST=10.79.20.54)(PORT=1522))

    )

  )

SID_LIST_LISTENER_DG=

  (SID_LIST=

    (SID_DESC=

      (SID_NAME=orajy)

      (SDU=32767)

      (ORACLE_HOME=/app/oracle/product/10.2.0/db)

      (GLOBAL_DBNAME=orajy_std_static)

    )

    (SID_DESC=

      (SID_NAME=orajy)

      (SDU=32767)

      (ORACLE_HOME=/app/oracle/product/10.2.0/db)

      (GLOBAL_DBNAME=orajy_std_dgmgrl)

    )

  )

（2）配置命名方法

为每个数据库创建一个唯一的连接别名。用每个数据库的 db_unique_name 作为 Oracle Net 别名既简单又直观。

orajy_dg用于连接到数据库orajy上的动态 Data Guard 服务的别名。

orajy_std_dg用于连接到数据库orajy_std上的动态 Data Guard 服务的别名。

orajy_static_dg用于连接到数据库orajy上的静态 Data Guard 服务的别名。

orajy_std_static_dg用于连接到数据库orajy_std上的静态 Data Guard 服务的别名。 

 两个数据库上tnsnames.ora配置：

orajy_dg=

  (description=

    (SDU=32767)

    (address_list=

      (address=(protocol=tcp)(host=10.79.20.51)(port=1522))

    )

    (connect_data=

      (service_name=orajy)

      (server=dedicated)

    )

  )

orajy_std_dg=

  (description=

    (SDU=32767)

    (address_list=

      (address=(protocol=tcp)(host=10.79.20.54)(port=1522))

    )

    (connect_data=

      (service_name=orajy_std)

      (server=dedicated)

    )

  )

orajy_static_dg=

  (description=

    (SDU=32767)

    (address_list=

      (address=(protocol=tcp)(host=10.79.20.51)(port=1522))

    )

    (connect_data=

      (service_name=orajy_static)

      (server=dedicated)

    )

  )

orajy_std_static_dg=

  (description=

    (SDU=32767)

    (address_list=

      (address=(protocol=tcp)(host=10.79.20.54)(port=1522))

    )

    (connect_data=

      (service_name=orajy_std_static)

      (server=dedicated)

    )

  )

（3）启动 Data Guard 监听器

启动P590和P720主机上的 Data Guard 监听器。

lsnrctl start LISTENER_DG

（4）测试 Oracle Net 连接

验证来自两个网络服务别名

tnsping orajy_dg

tsnping orajy_std_dg

显示类似下面连接信息，表示连接正常

Attempting to contact (description= (SDU=32767) (address_list= (address=(protocol=tcp)(host=10.79.20.51)(port=1522)))

 (connect_data= (service_name=orajy) (server=dedicated)))

OK (0 msec)

2. 准备Primary数据库

为了使用快速启动故障切换，假设我们的主库P590第四章中的配置完成。还需P590上的Primary数据库做以下配置。

(1) 将 Data Guard 监听器添加到 local_listeners 参数

为了使数据库在 Data Guard监听器中注册，必须将它添加到数据库的 local_listener 参数中。如果已经使用了local_listener，则需将 Data Guard 监听器添加到列表中。设置完 local_listener 之后，将数据库注册到监听器并验证该服务已注册成功。

也可以在设置 local_listener 参数时使用 tnsnames.ora 文件中定义的 TNS 别名。 在向多个监听器注册时，该方法尤其有用。

alter system set local_listener='(address=(host=10.79.20.51)(port=1522)(protocol=tcp))';

alter system register;

以下假设在第四章中P590上的Primary数据库已经完成设置

启用存档日志模式、启用强制日志记录、使用spfile、创建口令文件、启用远程登录、设置 db_unique_name、创建备用重做日志。

(2) 配置快速恢复区

如果您还没有快速恢复区 (FRA)，需要为闪回数据库创建一个。如果您已经拥有一个 FRA，可能需要增加其大小以容纳闪回数据库文件。有关储存需求的信息，请参阅上文中的闪回数据库部分。

alter system set db_recovery_file_dest_size = 20g scope=both;

alter system set db_recovery_file_dest = '/oraarch/orajy/fra'  scope=both;

(3) 启用自动备用文件管理

非硬性要求，但建议如此。

alter system set standby_file_management=auto;

(4)设置 log_archive_config

必须先设置该参数，然后才能在最高可用性模式下打开Primary数据库。其余 Data Guard 相关参数稍后通过 Broker进行设置。

alter system set log_archive_config='DG_CONFIG=(orajy_std)' scope=both;

(5)需要Primary数据库处于mount状态的操作

启用闪回数据库

alter database flashback on;

alter system set db_flashback_retention_target = 60 scope=both;

启用最高可用性模式

如上文所述，最高可用性模式对于 Oracle 数据库 10g 是必选的，对于 Oracle 数据库 11g 则是可选的。

alter database set standby database to maximize availability;

3. 准备备用数据库

可以使用第四章中的实施过程创建一个Standby数据库。在Standby数据库启用闪回数据库，要求Standby数据库处于mount状态。

alter database flashback on;

alter system set db_flashback_retention_target = 60 scope=both;

如果Standby数据库处于接收REDO日志状态，先取消日志接收，待数据库闪回启用后，再启用日志接收。

recover managed standby database cancel;

4. 创建Data Guard Broker 配置

(1) 设置 Data Guard Broker 配置文件的位置

Broker 将其配置信息存储在数据库外的一组文件镜像中。默认情况下，两个文件都存储在 $ORACLE_HOME/dbs 中。要保护这两个文件，比较好的做法是将它们存储在不同的文件系统中。

设置（Primary数据库和Standby数据库进行设置）

alter system set dg_broker_config_file1='/oradata/orajy/dgbroker/dg1orajy.dat';

alter system set dg_broker_config_file2='/oraarch/orajy/dgbroker/dg2orajy.dat';

(2) 启用 Data Guard Broker

（Primary数据库和Standby数据库均设置）

alter system set dg_broker_start=true;

(3) 配置 Broker

a. 在Primary数据库上启动 dgmgrl 实用程序并以 SYS 身份进行连接

dgmgrl sys/shift001@orajy_dg

b. 添加Primary数据库

create configuration 'FSF' as primary database is orajy connect identifier is orajy;

c. 添加Standby数据库

add database orajy_std as connect identifier is orajy_std maintained as physical;

d. 编辑数据库属性

默认情况下，Broker 将Primary数据库设置为使用异步日志传输。本环境中采用最大可用性模式，需要将此设置参数LogXptMode更改为同步。

NetTimeout 属性指定在考虑连接丢失前 LGWR 将阻塞对同步模式中来自Standby数据库的确认的等待秒数（对应于 log_archive_dest_n 的 NET_TIMEOUT 选项）。默认值为 30 秒。使用最高可用性模式时，考虑降低该值以减少Standby数据库不可用时的提交阻塞时间。选择一个足够高的值，避免由间歇性网络问题引起的假性断开。本示例使用 10 秒钟。

Broker 的许多数据库属性与数据库 spfile 参数相对应。Broker 在角色转换、数据库启动/关闭以及其他事件期间，通过执行相应的 ALTER SYSTEM 命令来维护这些参数。如果这些参数在 Broker 外部进行了修改，将出现警告。

edit database orajy set property LogXptMode='SYNC';

edit database orajy set property NetTimeout=10;

edit database orajy_std set property LogXptMode='SYNC';

edit database orajy_std set property NetTimeout=10;

e. 启用配置

Broker可能需要几分钟的时间验证配置、设置两个数据库上的参数并启动托管恢复。 监视Primary数据库和Standby数据库上的警报日志是在监视 Broker 运行和熟悉其如何执行各种任务的好方法。

enable configuration;

5. 启用FSFO

现在，启用 FSFO以确保已满足所有条件。Broker 在启用 FSFO前验证配置满足所有前提条件并将报告发现的任何问题。最常见的问题是不匹配 Data Guard 保护模式和 LogXptMode 属性，以及忘记在Primary数据库或Standby数据库上启用闪回数据库。

启用 FSFO 并不能使其完成自动故障切换的配置，这需要接下来将介绍的观察器。

enable fast_start failover;

启用 FSFO 后，Broker 需要找到一个观察器，而我们还没有启动，所以，如果您在“show configuration”处验证配置，Broker 将报警

show configuration

Configuration

  Name:   FSF

  Enabled:  YES

  Protection Mode:  MaxAvailability

  Databases:

  orajy - Primary database

  orajy_std - Physical standby database

        - Fast-Start Failover target

Fast-Start Failover: ENABLED

Current status for "FSF":

Warning: ORA-16608: one or more databases have warnings

在Primary数据库上运行 StatusReport 应验证导致错误的原因是缺少观察器。

show database orajy statusreport

STATUS REPORT

INSTANCE_NAME   SEVERITY ERROR_TEXT

*      ERROR ORA-16819: fast-start failover observer not started

6. 配置观察器

为了最大程度地体现 FSFO 的优势，观察器应与Primary数据库和Standby数据库运行在不同主机上。Primary数据库、Standby数据库和观察器根据容灾的需要放置在不同的地理区域。观察器需要较少的系统资源，需要很少的网络带宽和主备库连接，对延迟不太敏感，只要将其放置在任何有可靠网络连接的地点即可。

由于观察器是 dgmgrl 会话的特定实例，观察器主机应安装 Oracle Client Administrator 软件或完整的 Oracle数据库软件系列。

(1)验证连接

tnsping orajy_dg

tnsping orajy_std_dg

(2)启动观察器

通过运行 dgmgrl 启动观察器并使用 SYS 凭证登录。这里将以交互方式启动它以验证一切运行正常。注意，启动观察器后，终端会话将呈现挂起状态。这是正常现象。可以创建脚本实现观察器作为后台进程启动。

dgmgrl sys/shift001@orajy

start observer;

此时，终端会话将呈现挂起状态。

(3)验证配置

重开一个终端会话验证配置。 本示例介绍了用于提供 FSFO 特定信息的“show configuration”命令的详细模式。如果状态为 SUCCESS，说明我们的配置已经成功完成

dgmgrl sys/shift001@orajy_dg

show configuration verbose

7. 测试切换

(1) 测试双向转换

为了实现完全自动转换，Broker 需要 SYSDBA 权限以重新启动两个数据库或其中一个数据库。 如果没有该权限，Broker 仍将完成角色转换，但需要手动重新启动数据库。

dgmgrl sys/shift001@orajy_dg

switchover to orajy_std

现在，让我们来测试另一个方向的转换。

switchover to orajy

显示Switchover succeeded, 说明切换成功

(2) 测试故障切换

现在我们知道转换已成功，该测试故障切换了。测试 FSFO 故障切换需要模拟缺少Primary数据库。最简单的方法是中止Primary数据库。这将使观察器在达到 FSFO 阈值延时后，启动故障切换。在中止Primary数据库后，查看两个数据库上的警报日志和观察器日志对深入了解 FSFO 故障切换期间所发生的情况有很大帮助。

我们还可以使用 dgmgrl 故障切换命令来启动故障切换。这将演练配置，但触发故障切换的方式与失去与Primary数据库的连接不同。

a. 我们希望故障切换测试完成后，观察器能够自动将之前的Primary数据库恢复为Standby数据库，因此在每次测试之前，确保闪回数据库至少有 30 分钟的历史记录。每次故障切换测试前执行此操作。如果闪回数据库历史记录不足，观察器将不能进行恢复，而您将需要手动从备份或Primary数据库副本进行恢复。

在即将中止的Primary数据库上：

select (sysdate - oldest_flashback_time)*24*60 as history from v$flashback_database_log;

查看结果，大于30分钟，可以启动故障切换。

b. 们在Primary数据库上进行一些更改并查看更改是否在故障切换后仍然存在。本次测试使用最高可用性模式实现“零数据丢失”。

作为测试用户登录，并进行一些不会影响系统其他部分的更改。

-- Note that DDL statements automatically commit

create table x as select * from all_objects;

Table created.

select count(*) from x;

  COUNT(*)

----------

     68855

c. 中止Primary数据库。

shutdown abort

通过登录到新Primary数据库上的 dgmgrl 查看 Broker 配置。 您会看到之前的Primary数据库现在已禁用。

dgmgrl sys/shift001@orajy_std_dg

show configuration

Configuration

  Name: FSF

  Enabled: YES

  Protection Mode:     MaxAvailability

  Databases:

    orajy_std - Primary database

    orajy - Physical standby database (disabled)

          - Fast-Start Failover target

Fast-Start Failover: ENABLED

Current status for "FSF":

Warning: ORA-16608: one or more databases have warnings

查看测试数据，登录到新的Primary数据库并验证更改与之前Primary数据库一致。

select count(*) from x;

  COUNT(*)

----------

     68855

d. 将之前中止的Primary数据库恢复为Standby数据库

恢复的第一步是将数据库闪回到Standby数据库变为Primary数据库的 SCN 处（新Primary数据库上的 v$database.standby_became_primary_scn）。如上文所述，闪回数据库将分成两个阶段进行：恢复阶段和介质恢复阶段。在恢复阶段，闪回数据库使用闪回数据库日志中的前映像块将数据库恢复到 standby_became_primary_scn 之前的一点。在介质恢复阶段中，闪回数据库应用REDO以将数据库带到 standby_became_primary_scn。为使闪回数据库成功，闪回数据库日志中必须包括足够的可用历史记录，并且恢复点和 standby_became_primary_scn 之间生成的所有redo必须可用。如果闪回数据库失败，自动恢复将停止，需要用户手动执行基于 SCN 的恢复以恢复到 standby_became_primary_scn，直到完成该恢复。

一旦闪回数据库成功，观察器会将该数据库转换为Standby数据库，执行回弹并开始应用服务，将原Primary数据库启动到mount状态可以通过查看观察器日志了解原Primary数据库的恢复情况。

e. 在另一个方向重复操作

现在，对 FSFO 故障切换回到原始Primary数据库的操作进行测试。进行一些新的更改并验证故障切换执行后这些更改仍然存在。记住，在中止Primary数据库前查看闪回数据库历史记录。

本章小结

本章是在基于Data Guard的基础上，提出了使用Broker技术来避免 Data Guard所产生的不足之处，通过FSFO来实现生产数据库的自动故障切换，使得容灾系统在切换过程中实现完全自动化，保证数据业务的连续性，简化了 Data Guard复杂的管理过程。目前油田的核心数据库容量不是特别大，一般在200GB以下，数据库采用这样的容灾技术，采用FSFO实现数据库的灾难切换，可以媲美实施费用昂贵的存储级数据容灾系统。