时间：2021-07-01 10:21:17 帮助过：3人阅读
本文档将指导您使用物理备用服务器配置 Oracle Data Guard 快速启动故障切换 (FSFO)。FSFO 可以显著提高所有环境的可用性和灾难恢复准备，从基于云的价格低廉的系统一直到全球分布的数据中心。 本指南中的信息基于在跨国公司生产环境中部署 FSFO 的实践经验
本文档将指导您使用物理备用服务器配置 Oracle Data Guard 快速启动故障切换 (FSFO)。FSFO 可以显著提高所有环境的可用性和灾难恢复准备，从基于云的价格低廉的系统一直到全球分布的数据中心。
本指南中的信息基于在跨国公司生产环境中部署 FSFO 的实践经验。 本指南对您的现有环境做出几个假设，并且包括创建物理备用服务器和 Data Guard Broker 配置的示例。要开始本指南，您只需 Oracle 数据库企业版 10.2 版或更高版本、一个数据库和三个主机：两个主机用于数据库，一个小型主机用于 FSFO 观察器。本指南不对操作系统进行讨论；然而，一些示例中可能包含了特定于平台的元素（如路径和文件命名惯例）。
FSFO 构建于众多其他 Oracle 技术和特性（如 Data Guard、闪回数据库和 Data Guard Broker）之上。
FSFO 的基础是 Data Guard — 一个主数据库和至少一个备用数据库。备用数据库可以是物理的或逻辑的，可以有多个备用数据库，但只有一个备用数据库可作为随时进行故障切换的目标。以下段落将描述受支持的可用性模式。
最高可用性模式（Oracle 数据库 10g 第 2 版及更高版本）
在最高可用性模式中，FSFO 保证在故障切换期间不会丢失已收到提交确认 的事务。该保证的代价是增加提交延迟（log file sync 等待事件）。最高可用性模式使用同步重做传输，FSFO 则增加了额外要求，即重做应记录在目标备用数据库（log_archive_dest_n 的 AFFIRM 选项）的备用重做日志 (SRL) 中。Overall commit latency is increased by the round-trip network latency.往返网络延迟增加了总体提交延迟。增加的延迟降低了吞吐量；然而，有些时候吞吐量的差异是由增加的并行造成的。
虽然重做传输是同步的，但如果备用数据库由于某种原因（如备用数据库、主机或网络故障）不可用，最高可用性模式会保持主数据库可用。如果在用户指定的时间段（log_archive_dest_n 的 NET_TIMEOUT 选项）之后，主数据库无法联系到备用数据库，它将退出同步传输模式并开始像在最高性能模式中一样进行操作。当备用数据库再次可用时，主数据库和备用数据库重新同步并恢复同步重做传输。
最高性能模式（Oracle 数据库 11g 第 1 版及更高版本）
Oracle 数据库 11g FSFO 增加了对最高性能模式的支持（异步重做传输），提供了用持久性换取性能的灵活性。提交延迟不受重做传输的影响，但备用数据库未收到其重做的已提交事务将在故障切换期间丢失。通过指定故障切换期间丢失事务的最大允许时间，最高性能模式中的 FSFO 配置可以限制潜在的数据丢失。例如，如果指定的限定值为 30 秒（默认），FSFO 将保证在故障切换期间保存 30 秒钟内提交的所有事务。最小允许限定值为 10 秒钟。
Broker 是一个 Data Guard 管理实用程序，用于维护有关主数据库及其备用数据库的状态信息。它自动设置与 Data Guard 相关的数据库初始化参数（如实例启动和角色转换)、启动备用数据库的应用服务，并且自动执行与维护 Data Guard 配置相关的许多管理任务。FSFO 是 Broker 的一个特性，用于记录故障切换目标的相关信息，例如，故障发生后到触发故障切换之间的等待时间以及 FSFO 的其他特有属性。
闪回数据库是一个集成在 Oracle 数据库中的持续数据保护 (CDP) 解决方案。它使用名为闪回日志的磁盘数据结构，提供一个将数据库快速恢复到之前时间点或 SCN 的方法。数据库闪回比传统的时间点或基于 SCN 的恢复速度更快、结合更完美（一条简单的 DDL 语句）。FSFO 将闪回数据库用作将故障主数据库恢复为备用数据库流程的一部分。
自动恢复的问题通常因为错误的配置，因此我们来了解一些详细信息。
闪回数据库记录经过更改的数据块的前映像。为了避免记录每个数据块的每次更改的开销，闪回数据库每 30 分钟进行一次“模糊”快照，仅记录前映像块上一次快照后的第一次更改。在同一快照期间中，不再记录对同一数据块的后续更改。
数据库的闪回分成两个阶段：
对于 FSFO 环境，设置 db_flashback_retention_target = 60 或更高值，可以为自动备用恢复提供足够的闪回数据库历史记录。模糊快照的元数据存储在闪回日志本身中。如果没有元数据，Oracle 将无法找到模糊快照，从而无法进行闪回。为了避免计时差异产生的问题，我们建议值设置为不少于 60 分钟，实际上，如果值设置为 30 或 30 以下，肯定会导致闪回数据库故障。
闪回数据库将日志存储在快速恢复区 (FRA) 中，所以 FRA 必须有足够大的空间来存储至少 60 分钟的闪回数据库历史记录。总的存储需求与快照期间更改的不同数据块的数量成比例，例如，一小组数据块上的 1,000,000 次块更改生成的闪回数据库历史记录小于一大组数据块上的 1,000,000 次块更改所生成的闪回数据库历史记录。确定闪存数据库存储需求的一个好方法是，启用闪存数据库并观察其在几次峰值负载时所使用的存储量。通过启用闪回数据库来确定其存储需求也有一定的风险 — 如有必要，在主数据库处于打开状态时可以将其禁用。然而，重新启用闪回数据库将需要回弹，因为数据库必须进行安装且未打开。
观察器是非常典型的主/备用 Data Guard 配置中的第三方。它实际上是一个内置于 DGMGRL CLI（Data Guard Broker 命令行界面）中、占用空间很小的 OCI 客户端，与其他所有客户端一样，可以运行在与数据库服务器不同的硬件平台上。其主要工作是在条件允许时执行故障切换，而不影响 DBA 设置的数据持久性约束条件。只有观察器能启动 FSFO 故障切换。它的另一个工作是在启用该特性的情况下（默认）自动将主数据库恢复为备用数据库。观察器是 Data Guard 故障切换在强健的高可用性解决方案中承担重要角色的关键因素，也是造成 Data Guard 故障切换在 FSFO 出现前后重大差异的关键因素。
注：FSFO 观察器版本必须与数据库版本匹配。 Oracle 数据库 11g 观察器与 10g 数据库不兼容，Oracle 数据库 10g 观察器与 11g 数据库也不兼容。
默认情况下，当且仅当满足以下条件时，观察器才会启动到目标备用数据库的故障切换：
Oracle 数据库 11g 第 1 版引入了用户可配置的故障切换条件，这些条件可以触发观察器立即启动故障切换。
运行状况条件
Broker 可配置为在以下任一条件下启动故障切换。以蓝色显示的条件是默认启用的。
Oracle 错误 (ORA-NNNNN)
您可以指定一个将启动 FSFO 故障切换的 ORA 错误列表。该列表默认为空。
应用程序启动
应用程序可直接使用 DBMS_DG.INITIATE_FS_FAILOVER 过程启动 FSFO 故障切换，并包括一个可选的在观察器日志和主数据库警报日志中显示的消息文本。
本指南首先介绍一个将作为 Data Guard 配置主数据库的数据库。对于本次构建，我们将使用一个物理备用数据库。FSFO 还可以与逻辑备用数据库结合使用，支持 FSFO 的配置可有多个备用数据库，包括混合的物理数据库和逻辑数据库，但只有一个备用数据库可随时作为故障切换目标。
本指南中的主要步骤包括：
数据库主机称为“a”和“b”主机，数据库本身称为“a”和“b”数据库。观察器主机是“observer.demo.org”。
示例中使用的名称：
| 数据库名称 |
db1 |
| 数据库唯一名称 |
db1_a db1_b |
|
域名 |
demo.org |
| 主机名 |
dbhost-a dbhost-b |
| Data Guard 监听器名称 | LISTENER_DG |
| TNS 别名 |
db1_a db1_b |
针对应用程序连接和 Data Guard 连接使用不同的监听器是很好的做法。这样，Data Guard 可以在应用程序监听器因进行维护而停止工作时保持运行。请确保在 local_listeners 数据库参数中包括 Data Guard 监听器。
大多数在 FSFO 环境中使用的网络服务可使用动态注册，但要在角色转换期间或故障切换后的恢复期间启用 Broker 以重新启动实例，您必须定义一个名为 db_unique_name_dgmgrl.db_domain 的静态服务。（注：11.1.0.7 添加了 StaticConnectIdentifierBroker 数据库属性，允许您指定一个不同的服务名称。）如果您要使用 RMAN 创建备用数据库，还需要一个静态服务来重新启动所创建的数据库。为了将 Broker 和非 Broker 活动分离，建议再定义一个静态服务。
针对主机“a”的 listener.ora 配置：
LISTENER_DG =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=dbhost-a)(PORT=1522))
)
)
SID_LIST_LISTENER_DG=
(SID_LIST=
(SID_DESC=
(SID_NAME=db1)
(SDU=32767)
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(GLOBAL_DBNAME=db1_a_static.demo.org)
)
(SID_DESC=
(SID_NAME=db1)
(SDU=32767)
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(GLOBAL_DBNAME=db1_a_dgmgrl.demo.org)
)
)
针对主机“b”的 listener.ora 配置：
LISTENER_DG =
(DESCRIPTION=
(ADDRESS_LIST=
(ADDRESS=(PROTOCOL=tcp)(HOST=dbhost-b)(PORT=1522))
)
)
SID_LIST_LISTENER_DG=
(SID_LIST=
(SID_DESC=
(SID_NAME=db1)
(SDU=32767)
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(GLOBAL_DBNAME=db1_b_static.demo.org)
)
(SID_DESC=
(SID_NAME=db1)
(SDU=32767)
(ORACLE_HOME=/u01/app/oracle/product/11.1.0/db_1)
(GLOBAL_DBNAME=db1_b_dgmgrl.demo.org)
)
)
为每个数据库创建一个唯一的连接别名。用每个数据库的 db_unique_name 作为 Oracle Net 别名既简单又直观。
db1_a：用于连接到数据库“a”上的动态 Data Guard 服务的别名
db1_b：用于连接到数据库“b”上的动态 Data Guard 服务的别名
db1_a_static：用于连接到数据库“a”上的静态 Data Guard 服务的别名
db1_b_static：用于连接到数据库“b”上的静态 Data Guard 服务的别名
示例 tnsnames.ora 条目：
db1_a=
(description=
(SDU=32767)
(address_list=
(address=(protocol=tcp)(host=dbhost-a)(port=1522))
)
(connect_data=
(service_name=db1_a.demo.org)
(server=dedicated)
)
)
db1_b=
(description=
(SDU=32767)
(address_list=
(address=(protocol=tcp)(host=dbhost-b)(port=1522))
)
(connect_data=
(service_name=db1_b.demo.org)
(server=dedicated)
)
)
db1_a_static=
(description=
(SDU=32767)
(address_list=
(address=(protocol=tcp)(host=dbhost-a)(port=1522))
)
(connect_data=
(service_name=db1_a_static.demo.org)
(server=dedicated)
)
)
db1_b_static=
(description=
(SDU=32767)
(address_list=
(address=(protocol=tcp)(host=dbhost-b)(port=1522))
)
(connect_data=
(service_name=db1_b_static.demo.org)
(server=dedicated)
)
)
hosts.启动“a”和“b”主机上的 Data Guard 监听器。
lsnrctl start LISTENER_DG
验证来自两个主机的配置。
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)
为了使用快速启动故障切换，主数据库必须满足一系列前提条件。本部分描述将如何配置和验证每个前提条件。要查看主数据库是否已满足某个前提条件，请按照验证部分的说明进行操作。
需要主数据库处于安装（未打开）状态的步骤集中在以下题为需要主数据库回弹的步骤的部分中。
为了使数据库在 Data Guard 监听器中注册，必须将监听器端点添加到数据库的 local_listener 参数中。如果已经使用了 local_listener，则需将 Data Guard 监听器添加到列表中。设置完 local_listener 之后，将数据库注册到监听器并验证该服务已注册成功。
注：您也可以在设置 local_listener 参数时使用 tnsnames.ora 文件中定义的 TNS 别名。在向参数值可能超过 255 个字符限制的多个监听器注册时，该方法尤其有用。
alter system set local_listener='(address=(host=dbhost-a)(port=1522)(protocol=tcp))';
alter system register;
show parameter local_listener
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
local_listener string (address=(host=dbhost-a)(port=
1522)(protocol=tcp))
lsnrctl status listener_dg
...
Services Summary...
Service "DB1_A" has 1 instance(s).
Instance "db1", status READY, has 1 handler(s) for this service...
Service "DB1_A_XPT" has 1 instance(s).
Instance "db1", status READY, has 1 handler(s) for this service...
Service "db1XDB" has 1 instance(s).
Instance "db1", status READY, has 1 handler(s) for this service...
Service "db1_a_dgmgrl.demo.org" has 1 instance(s).
Instance "db1", status UNKNOWN, has 1 handler(s) for this service...
Service "db1_a_static.demo.org" has 1 instance(s).
Instance "db1", status UNKNOWN, has 1 handler(s) for this service...
The command completed successfully
所有 Data Guard 环境都应在数据库级别启用强制日志记录，以避免添加时产生无日志记录的表空间。
alter database force logging;
select force_logging from v$database;
FOR
---
YES
Broker 将在启动和角色转换期间通过 ALTER SYSTEM 命令时更改数据库参数。保存这些更改将需要一个 spfile。
create spfile='?/dbs/spfile${ORACLE_SID}.ora' from pfile='?/dbs/init${ORACLE_SID}.ora';
alter system set spfile='?/dbs/spfiledb1.ora';
show parameter spfile;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
spfile string ?/dbs/spfiledb1.ora
所有 Data Guard 环境都需要使用口令文件以使数据库可以互相连接。
orapwd file=$ORACLE_HOME/dbs/orapw$ORACLE_SID
select * from v$pwfile_users;
USERNAME SYSDB SYSOP SYSAS
------------------------------ ----- ----- -----
SYS TRUE TRUE FALSE
Data Guard 配置中的数据库要进行互相连接，需要带有口令文件的远程登录。
alter system set remote_login_passwordfile=exclusive scope=spfile;
show parameter remote_login_passwordfile
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
remote_login_passwordfile string EXCLUSIVE
Data Guard 配置中的每个数据库必须有唯一的名称。本指南使用在 db_name 加一个下划线后接一个字母的命名惯例来创建 db_unique_name。
alter system set db_unique_name = db1_a scope=spfile;
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string db1_a
show parameter db_unique_name
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_unique_name string db1_a
如果您还没有快速恢复区 (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
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_recovery_file_dest string /u02/flash_recovery_area
db_recovery_file_dest_size big integer 2G
非硬性要求，但建议如此。
alter system set standby_file_management=auto;
show parameter standby_file_management
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
standby_file_management string AUTO
必须先设置该参数，然后才能在最高可用性模式下打开主数据库。其余 Data Guard 相关参数稍后将本指南中通过 Broker 进行设置。
alter system set log_archive_config='DG_CONFIG=(db1_b)' scope=both;
show parameter log_archive_config
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
log_archive_config string DG_CONFIG=(db1_b)
为适应所有加载条件，Oracle 建议 SRL 组至少比相同大小的 ORL 组多一个。本指南假定主数据库和备用数据库上的所有 ORL 和 SRL 大小相同。
确定联机重做日志文件 (ORL) 的数量和大小
select bytes, count(group#) from v$log group by bytes;
BYTES COUNT(GROUP#)
---------- -------------
52428800 3
找到最大 group#
select max(group#) from v$log;
MAX(GROUP#)
-----------
3
添加 SRL。与 ORL 不同，创建的 SRL 每组中仅有一个成员。无需像 ORL 中那样创建多个 SRL 来保护重做（主数据库中的 ORL 中已对重做进行保护）。多个 SRL 只会增加不必要的 IO 并将增加提交延时。对于具有多个 RAID 控制器的系统，考虑创建 SRL，以便在在控制器之间平衡分布其 IO。
在本示例中，有 3 个最大 ORL，最大 group# 为 3。我们将从 group# 11 开始递增，创建 4 个 SRL。从 11 开始是完全形式化的，这样使稍后添加的新 ORL 组可以保持其 group# 与现有 ORL 拥有相同的顺序。
alter database add standby logfile group 11 '/u02/oradata/db1/stby-t01-g11-m1.log' size 52428800;
alter database add standby logfile group 12 '/u02/oradata/db1/stby-t01-g12-m1.log' size 52428800;
alter database add standby logfile group 13 '/u02/oradata/db1/stby-t01-g13-m1.log' size 52428800;
alter database add standby logfile group 14 '/u02/oradata/db1/stby-t01-g14-m1.log' size 52428800;
select group#, type, member from v$logfile where type = 'STANDBY';
GROUP# TYPE MEMBER
---------- ------- ----------------------------------------
11 STANDBY /u02/oradata/db1/stby-t01-g11-m1.log
12 STANDBY /u02/oradata/db1/stby-t01-g12-m1.log
13 STANDBY /u02/oradata/db1/stby-t01-g13-m1.log
14 STANDBY /u02/oradata/db1/stby-t01-g14-m1.log
以下步骤均要求数据库处于安装（未打开）状态。可以在一个回弹中将它们全部同时完成。
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
------------------
YES
show parameter db_flashback_retention_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 60
如上文所述，最高可用性模式对于 Oracle 数据库 10g 是必选的，对于 Oracle 数据库 11g 则是可选的。
alter database set standby database to maximize availability;
select protection_mode from v$database;
PROTECTION_MODE
--------------------
MAXIMUM AVAILABILITY
如果您还没有备用数据库，使用您最喜欢的方法创建一个备用数据库。以下示例将利用 11g RMAN 活动数据库复制特性。通过该特性，RMAN 可以通过网络复制现有数据库而无需磁盘或磁带备份。以下部分假定备用主机已根据 Oracle 的建议进行设置，并且操作系统、帐户、安全性、资源限制、目录结构等配置正确。
在 Oracle 数据库 11g 中，由于 Oracle 数据库 11g 中安全性的增强，备用数据库中的口令文件必须是主数据库中口令文件的物理副本。Oracle 数据库 10g 中允许使用不同的口令文件，只要主数据库和备用数据库中的 SYS 口令相同即可。
向备用数据库的 oratab 文件添加一个条目
db1:/u01/app/oracle/product/11.1.0/db_1:Y
对于 RMAN 复制活动数据库方法而言，init.ora 文件（本示例中为 initdb1.ora）仅需要一个参数：db_name（甚至不必是数据库的真实名称 — 可使用任意名称）。RMAN 将从主数据库复制 spfile，因此仅在复制的第一阶段需要该 init.ora 文件。
db_name = db1
确保备用数据库上的操作系统环境已设置。使用 Oracle 提供的 oraenv 脚本。
startup nomount
rman target sys/password@db1_a_static auxiliary sys/password@db1_b_static
connected to target database: DB1 (DBID=1234567890)
connected to auxiliary database: X (not mounted)
CONFIGURE DEFAULT DEVICE TYPE TO DISK;
Oracle Data Guard 概念和管理文档（10g 第 2 版和 11g 第 1 版）的附录 F 中详细介绍了使用 RMAN 创建备用服务器的过程。本示例使用 11g 中的 FROM ACTIVE DATABASE 子句，该子句允许 RMAN 通过跨网络复制主数据库来创建备用数据库，而无需在磁盘或磁带上存储备份文件。RMAN 还复制 spfile 和口令文件，您可以更改各个参数的值。至少必须设置 db_unique_name。本示例假定备用数据库使用和主数据库相同的的目录结构。
注：如果您刚启用了存档日志模式，则会强行创建一个存档日志 (alter system archive log current) 以确保至少存在一个存档日志。否则，DUPLICATE TARGET DATABASE 命令将失败，错误消息为“RMAN-20208: UNTIL CHANGE is before RESETLOGS change”。
DUPLICATE TARGET DATABASE
FOR STANDBY
FROM ACTIVE DATABASE
DORECOVER
SPFILE
SET db_unique_name='db1_b'
SET log_archive_config=''
SET log_file_name_convert= ' ',' '
SET local_listener='(DESCRIPTION=(ADDRESS=(PROTOCOL=tcp)(HOST=dbhost-b)(PORT=1522)))'
NOFILENAMECHECK;
alter database flashback on;
alter system set db_flashback_retention_target = 60 scope=both;
select flashback_on from v$database;
FLASHBACK_ON
------------------
YES
show parameter db_flashback_retention_target
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
db_flashback_retention_target integer 60
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
alter system set dg_broker_start=true;
show parameter dg_broker_start
NAME TYPE VALUE
------------------------------------ ----------- ------------------------------
dg_broker_start boolean TRUE
dgmgrl sys/password@db1_a
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;
Enabled.
启用 FSFO 后，Broker 需要找到一个观察器，而我们还没有启动，所以，如果您在“show configuration”处验证配置，Broker 将报警（如果没有报警，请等待一分钟，就会发现缺少观察器）。
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":
Warning: ORA-16608: one or more databases have warnings
在主数据库上运行 StatusReport 应验证导致错误的原因是缺少观察器。
show 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 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”命令查看哪个用户可配置的 FSFO 故障切换条件有效。
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 阈值延时（默认值为 30 秒）后，启动故障切换。在中止主数据库后，查看两个数据库上的警报日志和观察器日志对深入了解 FSFO 故障切换期间所发生的情况有很大帮助。
我们还可以使用 dgmgrl 故障切换命令来启动故障切换。这将演练配置，但触发故障切换的方式与失去与主数据库的连接不同。
我们希望故障切换测试完成后，观察器能够自动将之前的主数据库恢复为备用数据库，因此在每次测试之前，确保闪回数据库至少有 30 分钟的历史记录。每次故障切换测试前执行此操作。如果闪回数据库历史记录不足，观察器将不能进行恢复，而您将需要手动从备份或主数据库副本进行恢复。
在即将中止的主数据库上：
select (sysdate - oldest_flashback_time)*24*60 as history from v$flashback_database_log;
HISTORY
----------
140.35
如果没有 30 分钟内的可用历史记录，不要启动故障切换。
如果我们不须验证是否满足持久性约束条件，顶多是个测试，因此我们在主数据库上进行一些更改并查看更改是否在故障切换后仍然存在。本指南使用最高可用性模式实现“零数据丢失”。
作为测试用户登录，并进行一些不会影响系统其他部分的更改。
-- Note that DDL statements automatically commit
create table x as select * from all_objects;
Table created.
select count(*) from x;
COUNT(*)
----------
68855
中止主数据库。
shutdown abort
观察器日志：
Initiating Fast-Start Failover to database "db1_b"...
Performing failover NOW, please wait...
Failover succeeded, new primary is "db1_b"
通过登录到新主数据库上的 dgmgrl 查看 Broker 配置。您会看到之前的主数据库现在已禁用。
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"...
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
dgmgrl 状态：
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”，数据库仍然处于打开的停滞状态，直至终止或者通知其在未发生故障切换的时间内继续运行（例如，停滞开始后但未到达故障切换超时前，观察器被终止）。
本指南中介绍的简单测试有利于确保基础部分正常工作，但是您可能希望开发一套更全面、更适合您的环境和需求的测试。
启用 FSFO 的系统和可以运行 FSFO 的系统有很大的区别。可以运行 FSFO 意味着满足成功进行故障切换的所有条件，包括正在运行的观察器和为满足持久性需求传输到故障切换目标的重做。本部分将介绍如何保持顶级 FSFO 环境。
如果 Broker 报错，使用 Broker 的“show configuration”命令确定 FSFO 状态，使用“show database
v$database 视图有专门用于监视 FSFO 状态的栏。以下所列的值表示 FSFO 可以进行故障切换。有关详细信息，请参阅所用版本的 Oracle 参考资料和 Data Guard 管理员指南。
fs_failover_status =
'SYNCHRONIZED' for MaxAvail
'TARGET UNDER LAG LIMIT' for MaxPerf
fs_failover_observer_present = 'YES'
没有什么比发现观察器刚刚进行故障切换的备用数据库在应用重做中落后 12 个小时更糟糕的了。如果故障切换目标收到了所有用于满足您持久性需求的重做，这将完美地满足观察器的所有条件。观察器不会考虑已经应用了多少重做。所以，请准备一个在备用数据库应用落后过多时通知相关人员的办法。
确保故障主数据库可自动恢复的重要性仅次于确保您拥有一个良好的主数据库。监视闪回数据库历史记录并在其降至 30 分钟以下时作出反应，这将节省时间并提高可用性。这还能在数据库在 FSFO 启动后的某一点禁用闪回数据库时向您发出警报。启用 FSFO 后，Broker 将检查主数据库和故障切换目标上的闪回数据库是否已启用。启用 FSFO 后，Broker 将继续在运行状况检查期间查看闪回数据库是否已启用。如果检测到闪回数据库因自身发现问题而遭禁用（无论手动或自动），Broker 将提示“ORA-16827: Flashback Database is disabled”。
如果应用程序和其他数据库客户端不知道主数据库的去向，故障切换数据库也无法发挥很好的作用。如果客户端已配置为收不到数据库响应时自动超时并重新连接，使用网络别名（例如，DNS CNAME）解决主数据库的问题将是一个简单有效的方法。进行角色更改后，命名服务将更新为新的主数据库地址。可以使用 DB_ROLE_CHANGE 系统上的触发器更新命名服务，并且客户端可以借助相应的客户端缓存 TTL 设置非常快速地连接到新的主数据库。
Oracle 还为 OCI 客户端提供快速应用通知 (FAN)，为 JDBC 客户端提供快速连接故障切换。这些功能使利用它们的应用程序可以异步接收数据库事件的通知（包括角色转换）。
本部分将帮助您开始创建用于自动启动和重新启动 FSFO 观察器的包装脚本。使用包装脚本在观察器主机启动时启动观察器进程，或者在观察器主机终止重新启动。您将决定如何编写包装和决定何时执行该包装的方法。
虽然并非严格要求，但创建钱夹将为存储启动观察器时自动连接到主数据库所需的凭证提供一个安全的方法。Oracle 数据库安全指南中的“配置身份认证”一章提供了有关如何创建钱夹的详细说明。
下面提供的 *nix 简单示例适用于两个版本。Oracle 数据库 10g FSFO 观察器限于使用钱夹中定义的默认用户名和口令。在 10g 中，一个钱夹可以用于多个观察器，但必须使用相同的 SYS 口令。Oracle 数据库 11g 观察器可使用特定的凭证，允许同一钱夹在多个观察器中使用不同的 SYS 口令。
创建存储钱夹的目录。
mkdir -p /u01/app/oracle/admin/wallet
创建一个钱夹并将其默认用户名和口令设置为数据库的 SYSDBA 凭证（通常为 SYS）。
mkstore -wrl /u01/app/oracle/admin/wallet -createEntry oracle.security.client.default_username SYS
mkstore -wrl /u01/app/oracle/admin/wallet -createEntry oracle.security.client.default_password
添加钱夹位置并覆盖到 sqlnet.ora。
WALLET_LOCATION =
(SOURCE =
(METHOD = FILE)
(METHOD_DATA =
(DIRECTORY = /u01/app/oracle/admin/wallet)
)
)
SQLNET.WALLET_OVERRIDE = TRUE
观察器在一个文件中维护状态信息。默认情况下，该文件名为 fsfo.dat 并创建于启动观察器的工作目录。该状态文件在观察器运行时锁定，以防止多个观察器使用同一文件。为避免一台主机上运行的多个观察器时的锁定问题，通常来说，比较好的做法是将状态文件存储在与数据库相关联的目录中。
mkdir -p /u01/app/oracle/admin/db1/observer
以下是一行 *nix 的观察器启动命令。注意，使用“/@
nohup dgmgrl /@db1 "start observer file='/u01/app/oracle/admin/db1/observer/fsfo.dat'" /
>> /u01/app/oracle/admin/db1/observer/dgmgrl.log &
创建一个自动启动 FSFO 故障切换的脚本，并将其作为备用数据库翻转的标准方法。这不仅节省了时间，还将使由自动化反向手动进程所引起的问题最小化。每一次翻转都将演练您的故障切换和 DR 流程，从中您将了解 FSFO 配置是多么出色，并且在真实的紧急情况下，每一个人都知道如何应对。故障切换将趋于常规。实际上，故障切换非常可靠、快捷和简便，转换将成为异常而不再是惯例。只需确保脚本中包括对闪回数据库历史记录的检查，从而在故障切换需要手动恢复时提供一个中止的选项。
当数据库在角色转换后第一次打开时，将触发 DB_ROLE_CHANGE 事件。转换或故障切换后，在该事件上创建一个触