本指南详细介绍了如何利用Oracle DataGuard快速启动故障切换功能，显著提高系统的可用性和灾难恢复能力。从配置快速恢复区到启用闪回数据库，再到设置DataGuardBroker和观察器，一步步指导用户实现故障切换的自动化，确保数据安全与业务连续性。
FSFO 可以显著提高所有环境的可用性和灾难恢复准备，从基于云的价格低廉的系统一直到全球分布的数据中心
FSFO 构建于众多其他 Oracle 技术和特性（如 Data Guard、闪回数据库和 Data Guard Broker）之上。
Data Guard Broker
Broker 是一个 Data Guard 管理实用程序，用于维护有关主数据库及其备用数据库的状态信息。它自动设置与 Data Guard 相关的数据库初始化参数（如实例启动和角色转换)、启动备用数据库的应用服务，并且自动执行与维护 Data Guard 配置相关的许多管理任务。FSFO 是 Broker 的一个特性，用于记录故障切换目标的相关信息，例如，故障发生后到触发故障切换之间的等待时间以及 FSFO 的其他特有属性
闪回数据库
闪回数据库是一个集成在 Oracle 数据库中的持续数据保护 (CDP) 解决方案。它使用名为闪回日志的磁盘数据结构，提供一个将数据库快速恢复到之前时间点或 SCN 的方法。数据库闪回比传统的时间点或基于 SCN 的恢复速度更快、结合更完美（一条简单的 DDL 语句）。FSFO 将闪回数据库用作将故障主数据库恢复为备用数据库流程的一部分
对于 FSFO 环境
设置 db_flashback_retention_target = 60 或更高值，可以为自动备用恢复提供足够的闪回数据库历史记录。模糊快照的元数据存储在闪回日志本身中。如果没有元数据，Oracle 将无法找到模糊快照，从而无法进行闪回。为了避免计时差异产生的问题，我们建议值设置为不少于 60 分钟，实际上，如果值设置为 30 或 30 以下，肯定会导致闪回数据库故障。
闪回数据库将日志存储在快速恢复区 (FRA) 中，所以 FRA 必须有足够大的空间来存储至少 60 分钟的闪回数据库历史记录。总的存储需求与快照期间更改的不同数据块的数量成比例，例如，一小组数据块上的 1,000,000 次块更改生成的闪回数据库历史记录小于一大组数据块上的 1,000,000 次块更改所生成的闪回数据库历史记录。确定闪存数据库存储需求的一个好方法是，启用闪存数据库并观察其在几次峰值负载时所使用的存储量。通过启用闪回数据库来确定其存储需求也有一定的风险 — 如有必要，在主数据库处于打开状态时可以将其禁用。然而，重新启用闪回数据库将需要回弹，因为数据库必须进行安装且未打开。
FSFO 观察器
观察器是非常典型的主/备用 Data Guard 配置中的第三方。它实际上是一个内置于 DGMGRL CLI（Data Guard Broker 命令行界面）中、占用空间很小的 OCI 客户端，与其他所有客户端一样，可以运行在与数据库服务器不同的硬件平台上。其主要工作是在条件允许时执行故障切换，而不影响 DBA 设置的数据持久性约束条件。只有观察器能启动 FSFO 故障切换。它的另一个工作是在启用该特性的情况下（默认）自动将主数据库恢复为备用数据库。观察器是 Data Guard 故障切换在强健的高可用性解决方案中承担重要角色的关键因素，也是造成 Data Guard 故障切换在 FSFO 出现前后重大差异的关键因素。
注：FSFO 观察器版本必须与数据库版本匹配。 Oracle 数据库 11g 观察器与 10g 数据库不兼容，Oracle 数据库 10g 观察器与 11g 数据库也不兼容
FSFO故障切换的条件
默认情况下，当且仅当满足以下条件时，观察器才会启动到目标备用数据库的故障切换：
- 观察器正在运行
- 观察器和备用数据库均与主数据库失去联系
- 注：如果观察器与主数据库失去联系，但是备用数据库并未失去联系，观察器可以确定主数据库仍然通过备用数据库运行。
- 观察器仍然保持与备用数据库的联系
- 满足持久性约束条件
- 故障切换阈值延时已过
-
运行状况条件
Broker 可配置为在以下任一条件下启动故障切换。以蓝色显示的条件是默认启用的。
- Datafile Offline（由于 IO 错误）
- Corrupted Controlfile
- Corrupted Dictionary
- Inaccessible Logfile（由于 IO 错误）
- Stuck Archiver
应用程序可直接使用 DBMS_DG.INITIATE_FS_FAILOVER 过程启动 FSFO 故障切换，并包括一个可选的在观察器日志和主数据库警报日志中显示的消息文本。
- Datafile Offline（由于 IO 错误）
- 案例简述：
- db1_a：用于连接到数据库“a”上的动态 Data Guard 服务的别名
db1_b：用于连接到数据库“b”上的动态 Data Guard 服务的别名
db1_a_static：用于连接到数据库“a”上的静态 Data Guard 服务的别名db1_b_static：用于连接到数据库“b”上的静态 Data Guard 服务的别名
启动 Data Guard 监听器
hosts.启动“a”和“b”主机上的 Data Guard 监听器。
lsnrctl start LISTENER_DG
准备主数据库
配置快速恢复区
如果您还没有快速恢复区 (FRA)，您将需要为闪回数据库创建一个。如果您已经拥有一个 FRA，可能需要增加其大小以容纳闪回数据库文件。有关储存需求的信息，请参阅上面的 闪回数据库部分。
配置
alter system set db_recovery_file_dest_size = 20g scope=both;
alter system set db_recovery_file_dest = '/u01/fra' scope=both;
验证
show parameter db_recovery_file
启用存档日志模式
启用
alter database archivelog;
验证
select log_mode from v$database;
LOG_MODE
------------
ARCHIVELOG启用闪回数据库
启用
alter database flashback on;
alter system set db_flashback_retention_target = 60 scope=both;验证
select flashback_on from v$database;
FLASHBACK_ON
------------------
YESshow parameter db_flashback_retention_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 60启用最高可用性模式
如上文所述，最高可用性模式对于 Oracle 数据库 10 g 是必选的，对于 Oracle 数据库 11 g 则是可选的。
启用
alter database set standby database to maximize availability;
验证
select protection_mode from v$database;
PROTECTION_MODE
--------------------
MAXIMUM AVAILABILITY
在备用数据库启用闪回数据库
启用
alter database flashback on;
alter system set db_flashback_retention_target = 60 scope=both;验证
select flashback_on from v$database;
FLASHBACK_ON
------------------
YESshow parameter db_flashback_retention_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 60
-
设置 Data Guard Broker 配置文件的位置
Broker 将其配置信息存储在数据库外的一组文件镜像中。默认情况下，两个文件都存储在 $ORACLE_HOME/dbs 中。要保护这两个文件，比较好的做法是将它们存储在不同的文件系统中。设置（主数据库和备用数据库）
alter system set dg_broker_config_file1='/u01/app/oracle/admin/db1/dgbroker/dg1db1.dat';
alter system set dg_broker_config_file2='/u02/app/oracle/admin/db1/dgbroker/dg2db1.dat';验证
show parameter dg_broker_config_file
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_config_file1 string /u01/app/oracle/admin/db1/dgbr
oker/dg1db1.dat
dg_broker_config_file2 string /u02/app/oracle/admin/db1/dgbr
oker/dg2db1.dat启用 Data Guard Broker
启用（主数据库和备用数据库）
alter system set dg_broker_start=true;
验证
show parameter dg_broker_start
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_start boolean TRUE配置 Broker
在主数据库上启动 dgmgrl 实用程序并以 SYS 身份进行连接
dgmgrl sys/password@db1_a
创建 Broker 配置
添加主数据库
create configuration 'FSF' as primary database is db1_a
connect identifier is db1_a;
Configuration "FSF" created with primary database "db1_a"添加备用数据库
add database db1_b as
connect identifier is db1_b
maintained as physical;
Database "db1_b" added验证配置
show configuration
Configuration
Name: FSF
Enabled: NO
Protection Mode: MaxAvailability
Databases:
db1_a - Primary database
db1_b - Physical standby database
Fast-Start Failover: DISABLED
Current status for "FSF":
DISABLED编辑数据库属性
LogXptMode
默认情况下，Broker 将主数据库设置为使用异步日志传输。针对最高可用性环境时，需要将此设置更改为同步。
NetTimeout
NetTimeout 属性指定在考虑连接丢失前 LGWR 将阻塞对同步模式中来自备用数据库的确认的等待秒数（对应于 log_archive_dest_n 的 NET_TIMEOUT 选项）。默认值为 30 秒。使用最高可用性模式时，考虑降低该值以减少备用数据库不可用时的提交阻塞时间。选择一个足够高的值，避免由间歇性网络问题引起的假性断开。本示例使用 10 秒钟。
ObserverConnectIdentifier（11g 及更高版本）
Oracle 数据库 11g 将 ObserverConnectIdentifier 数据库属性添加到 Broker 配置，使您可以为观察器指定一个连接标识符，用于监视主数据库和故障切换目标。默认情况下，观察器和 Data Guard 使用相同的连接标识符在主数据库和备用数据库间进行重做传输和信息交换（Oracle 数据库 11g 中为 DGConnectIdentifier，Oracle 数据库 10g 中为 InitialConnectIdentifier）。ObserverConnectIdentifier使您可以指定观察器使用不同的连接标识符。例如，您可以用此参数使观察器使用与客户端应用程序相同的连接标识符监视数据库。
在本指南中，我们将在保留其他属性的默认值，但您应熟悉所有 Broker 配置和数据库属性。Data Guard Broker 文档（10g 和 11g）第 9 章中包含了每个属性的描述。其中一些属性已经在这两个版本中有所改动。
注：Broker 的许多数据库属性与数据库 spfile 参数相对应。Broker 在角色转换、数据库启动/关闭以及其他事件期间，通过执行相应的 ALTER SYSTEM 命令来维护这些参数。如果这些参数在 Broker 外部进行了修改，将出现警告。要查看特定参数，使用“show database ... StatusReport”命令。
edit database db1_a set property LogXptMode='SYNC';
edit database db1_a set property NetTimeout=10;
edit database db1_b set property NetTimeout=10;启用配置
Broker 将验证配置、设置两个数据库上的参数并启动托管恢复。这可能需要几分钟的时间。监视主数据库和备用数据库上的警报日志是在监视 Broker 运行和熟悉其如何执行各种任务的好方法。
enable configuration;
验证配置
在继续前确保一切正常运行。
show configuration
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_a - Primary database
db1_b - Physical standby database
Fast-Start Failover: DISABLED
Current status for "FSF":
SUCCESS启用快速启动故障切换
现在，启用 FSFO 以确保已满足所有前提。Broker 将在启用 FSFO 前验证配置已满足所有前提条件并将报告发现的任何问题。最常见的问题是不匹配 Data Guard 保护模式和 LogXptMode 属性，以及忘记在主数据库或备用数据库上启用闪回数据库。
注意，启用 FSFO 并不能使其完成自动故障切换的配置 — 这需要我们接下来将介绍的观察器。
enable fast_start failover;
启用 FSFO 后，Broker 需要找到一个观察器，而我们还没有启动，所以，如果您在“show configuration”处验证配置，Broker 将报警（如果没有报警，请等待一分钟，就会发现缺少观察器）。
Enabled.
show configuration
在主数据库上运行 StatusReport 应验证导致错误的原因是缺少观察器。
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_a - Primary database
db1_b - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Current status for "FSF":
Warning: ORA-16608: one or more databases have warningsshow database db1_a statusreport
STATUS REPORT
INSTANCE_NAME SEVERITY ERROR_TEXT
* ERROR ORA-16819: fast-start failover observer not started配置观察器
为了最大程度地体现 FSFO 的优势，观察器应与主数据库和备用数据库运行在不同主机上。理想情况下，主数据库、备用数据库和观察器将位于不同的地理区域。观察器非常轻型且需要较少的系统资源。观察器与主数据库/备用数据库互连（带宽和延迟将决定性能因素）不同，仅需很少的网络带宽并且对延迟不太敏感，这使其可以用于任何有可靠连接的地点。
由于观察器是 dgmgrl 会话的特定实例，观察器主机应安装 Oracle Client Administrator 软件或完整的 Oracle 数据库软件系列。
验证到主数据库和备用数据库的连接
tnsping db1_a
Attempting to contact (description= (SDU=32767) (address_list= (address=(protocol=tcp)(host=dbhost-a)(port=1522)))
(connect_data= (service_name=db1_a.demo.org) (server=dedicated)))
OK (0 msec)tnsping db1_b
Attempting to contact (description= (SDU=32767) (address_list= (address=(protocol=tcp)(host=dbhost-b)(port=1522)))
(connect_data= (service_name=db1_b.demo.org) (server=dedicated)))
OK (0 msec)启动观察器
通过运行 dgmgrl 启动观察器并使用 SYS 凭证登录。我们现在将以交互方式启动它以验证一切运行正常。注意，启动观察器后，终端会话将呈现挂起状态。这是正常现象。附录提供有关如何创建简单的包装脚本以将观察器作为后台进程启动的信息。
dgmgrl sys/password@db1_a
此时，终端会话将呈现挂起状态。
start observer;
observer started
验证配置
在单独的终端会话中，验证配置。本示例介绍了用于提供 FSFO 特定信息的“show configuration”命令的详细模式。如果状态为 SUCCESS，您可以开始测试角色转换。
dgmgrl sys/password@db1_a
使用“show fast_start failover”命令查看哪个用户可配置的 FSFO 故障切换条件有效。
show configuration verbose
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_a - Primary database
db1_b - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Threshold: 30 seconds
Target: db1_b
Observer: observer.demo.org
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Current status for "FSF":
SUCCESS
show fast_start failover;
Fast-Start Failover: ENABLED
Threshold: 30 seconds
Target: db1_b
Observer: observer.demo.org
Lag Limit: 30 seconds (not in use)
Shutdown Primary: TRUE
Auto-reinstate: TRUE
Configurable Failover Conditions
Health Conditions:
Corrupted Controlfile YES
Corrupted Dictionary YES
Inaccessible Logfile NO
Stuck Archiver NO
Datafile Offline YES
Oracle Error Conditions:
(none)测试配置
配置的真实测试是成功的进行双向角色转换，包括转换和 FSFO 故障切换。我们将从转换开始。
测试双向转换
为了实现完全自动转换，Broker 需要 SYSDBA 凭证以重新启动两个数据库或其中一个数据库。如果没有该凭证，Broker 仍将完成角色转换，但需要手动重新启动数据库。
dgmgrl sys/password@db1_a
switchover to db1_b
Performing switchover NOW, please wait...
New primary database "db1_b" is opening...
Operation requires shutdown of instance "db1" on database "db1_a"
Shutting down instance "db1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "db1" on database "db1_a"
Starting instance "db1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "db1_b"show configuration
现在，让我们来测试另一个方向的转换。
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_b - Primary database
db1_a - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Current status for "FSF":
SUCCESS
switchover to db1_a
Performing switchover NOW, please wait...
New primary database "db1_a" is opening...
Operation requires shutdown of instance "db1" on database "db1_b"
Shutting down instance "db1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "db1" on database "db1_b"
Starting instance "db1"...
ORACLE instance started.
Database mounted.
Switchover succeeded, new primary is "db1_a"show configuration
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_a - Primary database
db1_b - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Current status for "FSF":
SUCCESS双向测试 FSFO 故障切换
现在我们知道转换已成功，该测试故障切换了。测试 FSFO 故障切换需要模拟缺少主数据库。最简单的方法是中止主数据库。这将使观察器在达到 FSFO 阈值延时（默认值为 30 秒）后，启动故障切换。在中止主数据库后，查看两个数据库上的警报日志和观察器日志对深入了解 FSFO 故障切换期间所发生的情况有很大帮助。
我们还可以使用 dgmgrl 故障切换命令来启动故障切换。这将演练配置，但触发故障切换的方式与失去与主数据库的连接不同。
检查闪回数据库记忆
我们希望故障切换测试完成后，观察器能够自动将之前的主数据库恢复为备用数据库，因此在每次测试之前，确保闪回数据库至少有 30 分钟的历史记录。每次故障切换测试前执行此操作。如果闪回数据库历史记录不足，观察器将不能进行恢复，而您将需要手动从备份或主数据库副本进行恢复。
在即将中止的主数据库上：
select (sysdate - oldest_flashback_time)*24*60 as history from v$flashback_database_log;
如果没有 30 分钟内的可用历史记录，不要启动故障切换。
HISTORY
----------
140.35
创建一些测试数据
如果我们不须验证是否满足持久性约束条件，顶多是个测试，因此我们在主数据库上进行一些更改并查看更改是否在故障切换后仍然存在。本指南使用最高可用性模式实现“零数据丢失”。
作为测试用户登录，并进行一些不会影响系统其他部分的更改。
-- Note that DDL statements automatically commit
create table x as select * from all_objects;
Table created.select count(*) from x;
COUNT(*)
----------
68855启动 FSFO 故障切换
中止主数据库。
shutdown abort
观察器日志：
Initiating Fast-Start Failover to database "db1_b"...
通过登录到新主数据库上的 dgmgrl 查看 Broker 配置。您会看到之前的主数据库现在已禁用。
Performing failover NOW, please wait...
Failover succeeded, new primary is "db1_b"
dgmgrl sys/password@db1_b
show configuration
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_b - Primary database
db1_a - 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查看测试数据
登录到新的主数据库并验证更改与之前主数据库一致。
select count(*) from x;
COUNT(*)
----------
68855将之前中止的主数据库恢复为备用数据库
通过安装数据库启动恢复。注意，数据库此时不会打开。仅当观察器验证主数据库仍为主数据库后，主数据库才会打开。如果观察器发现该数据库不再是主数据库，会尝试将其恢复为故障切换的目标备用数据库。
恢复的第一步是将数据库闪回到备用数据库变为主数据库的 SCN 处（新主数据库上的 v$database.standby_became_primary_scn）。如闪回数据库部分中所述，闪回数据库将分成两个阶段进行：恢复阶段和介质恢复阶段。在恢复阶段，闪回数据库使用闪回数据库日志中的前映像块将数据库恢复到 standby_became_primary_scn 之前的一点。在介质恢复阶段中，闪回数据库应用重做以将数据库带到standby_became_primary_scn。为使闪回数据库成功，闪回数据库日志中必须包括足够的可用历史记录，并且恢复点和standby_became_primary_scn 之间生成的所有重做必须可用。如果闪回数据库失败，自动恢复将停止，您将需要手动执行基于 SCN 的恢复以恢复到 standby_became_primary_scn，直到完成该恢复。
一旦闪回数据库成功，观察器会将该数据库转换为备用数据库，执行回弹并开始应用服务。
startup mount
观察器日志：
Initiating reinstatement for database "db1_a"...
dgmgrl 状态：
Reinstating database "db1_a", please wait...
Operation requires shutdown of instance "db1" on database "db1_a"
Shutting down instance "db1"...
ORA-01109: database not open
Database dismounted.
ORACLE instance shut down.
Operation requires startup of instance "db1" on database "db1_a"
Starting instance "db1"...
ORACLE instance started.
Database mounted.
Continuing to reinstate database "db1_a" ...
Reinstatement of database "db1_a" succeeded
Configuration
Name: FSF
Enabled: YES
Protection Mode: MaxAvailability
Databases:
db1_b - Primary database
db1_a - Physical standby database
- Fast-Start Failover target
Fast-Start Failover: ENABLED
Current status for "FSF":
SUCCESS在另一个方向重复操作
现在，对 FSFO 故障切换回到原始主数据库的操作进行测试。进行一些新的更改并验证故障切换执行后这些更改仍然存在。记住，在中止主数据库前查看闪回数据库历史记录。
主数据库停滞
还有一个很好的测试是模拟网络故障时主数据库仍然运行，但与故障切换目标备用数据库和观察器失去联系。当主数据库同时失去与故障切换目标和观察器的联系时，将进入“停滞”状态 (v$database.fs_failover_status = 'STALLED')，所有仍与主数据库连接的会话将在提交时阻塞。查询和 DML 将继续运行 — 只有提交的会话会阻塞。这将防止在故障切换时出现“裂脑”情况，因为对隔离主数据库进行的更改并不是永久性的。运行 10.2.0.4 之前版本的 Oracle 数据库 10g 数据库将处于停滞状态，直至您中止或由观察器设定其在连接恢复后仍然作为主数据库。从 10.2.0.4 开始（包括 11g 以及之后的所有版本），Oracle 将提供 FastStartFailoverPmyShutdown Broker 属性，如果超过 FSFO 阈值超时后主数据库仍然处于停滞状态，您可以通过该属性指定主数据库应该进行何种操作。如果该属性设置为“TRUE”（默认值），主数据库将自己终止。如果该属性设置为“FALSE”，数据库仍然处于打开的停滞状态，直至终止或者通知其在未发生故障切换的时间内继续运行（例如，停滞开始后但未到达故障切换超时前，观察器被终止）。
有机会要实验下！
扫一扫
151
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
