编辑数据库属性
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_astart observer;
observer started
此时，终端会话将呈现挂起状态。
验证配置
在单独的终端会话中，验证配置。 本示例介绍了用于提供 FSFO 特定信息的“show configuration”命令的详细模式。如果状态为 SUCCESS，您可以开始测试角色转换。
dgmgrl sys/password@db1_ashow 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
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: TRUECurrent 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_aswitchover 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 targetFast-
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;
HISTORY
----------
140.35
如果没有 30 分钟内的可用历史记录，不要启动故障切换。
创建一些测试数据
如果我们不须验证是否满足持久性约束条件，顶多是个测试，因此我们在主数据库上进行一些更改并查看更改是否在故障切换后仍然存在。本指南使用最高可用性模式实现“零数据丢失”。
作为测试用户登录，并进行一些不会影响系统其他部分的更改。
-- Note that DDL statements automatically commitcreate 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"...Performing failover NOW, please wait...
Failover succeeded, new primary is "db1_b"
通过登录到新主数据库上的 dgmgrl 查看 Broker 配置。 您会看到之前的主数据库现在已禁用。
dgmgrl sys/password@db1_bshow 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 openDatabase 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 意味着满足成功进行故障切换的所有条件，包括正在运行的观察器和为满足持久性需求传输到故障切换目标的重做。本部分将介绍如何保持顶级 FSFO 环境。
询问 Broker
如果 Broker 报错，使用 Broker 的“show configuration”命令确定 FSFO 状态，使用“show database <db_unique_name> statusreport”命令查看详细信息。
询问主数据库
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 SYSmkstore -wrl /u01/app/oracle/admin/wallet -createEntry oracle.security.client.default_password <sys password>
添加钱夹位置并覆盖到 sqlnet.ora。
WALLET_LOCATION = (SOURCE = (METHOD = FILE) (METHOD_DATA = (DIRECTORY = /u01/app/oracle/admin/wallet) ) )SQLNET.WALLET_OVERRIDE = TRUE
确定观察器状态文件（fsfo.dat 文件）的存储位置
观察器在一个文件中维护状态信息。 默认情况下，该文件名为 fsfo.dat 并创建于启动观察器的工作目录。该状态文件在观察器运行时锁定，以防止多个观察器使用同一文件。为避免一台主机上运行的多个观察器时的锁定问题，通常来说，比较好的做法是将状态文件存储在与数据库相关联的目录中。
mkdir -p /u01/app/oracle/admin/db1/observer
观察器启动命令
以下是一行 *nix 的观察器启动命令。 注意，使用“/@<tns_alias>”登录将用到钱夹。
nohup dgmgrl /@db1 "start observer file='/u01/app/oracle/admin/db1/observer/fsfo.dat'" \ >> /u01/app/oracle/admin/db1/observer/dgmgrl.log &
有助于了解观察器的信息
-
所有与观察器相关联的连接（包括初始连接）必须使用专用服务器连接。 使用 Shared Server (MTS) 或连接池可能导致无法预料的行为。
-
为实现可靠的启动，初始连接应始终连接到主数据库。运行中的观察器在角色转换后将自动跟随主数据库，但如果初始连接连接到故障数据库或者包含过期或损坏的 Broker 配置文件的数据库，新（重新）启动的观察器将不会启动。
-
启动可能会失败，原因为“cORA-16647: could not start more than one observer”。如果之前的观察器进程未注销即终止并且新观察器未使用之前的 fsfo.dat 文件，那么即使没有观察器在实际运行也会发生该错误。如果出现此情形，运行“stop observer”并重试。
-
至少配置两台主机来运行观察器是一个比较好的办法，这样，其中一台主机可以在另一台发生故障时进行替换。
故障切换脚本
创建一个自动启动 FSFO 故障切换的脚本，并将其作为备用数据库翻转的标准方法。 这不仅节省了时间，还将使由自动化反向手动进程所引起的问题最小化。每一次翻转都将演练您的故障切换和 DR 流程，从中您将了解 FSFO 配置是多么出色，并且在真实的紧急情况下，每一个人都知道如何应对。故障切换将趋于常规。实际上，故障切换非常可靠、快捷和简便，转换将成为异常而不再是惯例。只需确保脚本中包括对闪回数据库历史记录的检查，从而在故障切换需要手动恢复时提供一个中止的选项。
DB_ROLE_CHANGE 系统事件
当数据库在角色转换后第一次打开时，将触发 DB_ROLE_CHANGE 事件。 转换或故障切换后，在该事件上创建一个触发器来执行特定于您环境的操作，如将名称解析服务更新为指向新主数据库。尽量保持该触发器保持简单可靠，将其仅限定为角色转换时绝对必要，因为此时出现任何故障都将影响可用性。如果需要触发很多操作，请将它们放入一个单独的脚本中并使用触发器在一个孤立的进程或独立于数据库的线程中运行该脚本。
包括多个备用数据库的 FSFO 配置
备用节点
除故障切换目标之外的所有备用数据库被称为备用节点 (v$database.fs_failover_status = 'BYSTANDER')。备用节点是 Data Guard 配置的一部分，但不是 FSFO 配置的一部分。FSFO 配置在任何给定时间只包括两个数据库（主数据库和故障切换目标数据库）。
在故障切换期间，备用节点默认“跟随”主数据库，根据需要从新主数据库进行闪回和重应用重做。（是的，备用节点同样需要闪回数据库）。
在故障切换后，备用节点将不会自动成为新的故障切换目标。只有通过操作将故障切换目标更改为一个备用节点，新的主数据库只有在之前主数据库恢复为备用数据库后才能拥有一个故障切换目标。如果 Broker 配置更改为使备用节点成为新的故障切换目标（适用于故障数据库将停机一段时间的情况），观察器将不会自动恢复之前的主数据库，因为它将不再是 FSFO 配置的一部分。恢复需通过其他方式完成（手动或脚本 Broker 脚本命令）。
转换限制
启用 FSFO 的配置包含多个备用数据库，不能转换到非故障切换目标的备用数据库。 要转换到非当前故障切换目标的备用数据库：
-
禁用 FSFO
-
将故障切换目标更改为转换到的备用数据库
-
启用 FSFO
-
转换
或者
-
禁用 FSFO
-
转换
-
将故障切换目标更改为所希望的备用数据库
-
启用 FSFO
