示例 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)
)
)
启动 Data Guard 监听器
hosts.启动“a”和“b”主机上的 Data Guard 监听器。
lsnrctl start LISTENER_DG
测试 Oracle Net 连接
验证来自两个主机的配置。
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_listeners 参数
为了使数据库在 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
创建 spfile
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
设置 db_unique_name
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
设置 log_archive_config
必须先设置该参数,然后才能在最高可用性模式下打开主数据库。其余 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 条目
向备用数据库的 oratab 文件添加一个条目
db1:/u01/app/oracle/product/11.1.0/db_1:Y
创建 init.ora 文件
对于 RMAN 复制活动数据库方法而言,init.ora 文件(本示例中为 initdb1.ora)仅需要一个参数:db_name(甚至不必是数据库的真实名称 — 可使用任意名称)。RMAN 将从主数据库复制 spfile,因此仅在复制的第一阶段需要该 init.ora 文件。
db_name = db1
设置环境
确保备用数据库上的操作系统环境已设置。使用 Oracle 提供的 oraenv 脚本。
以非安装方式启动备用数据库
startup nomount
使用 RMAN 创建备用数据库
运行 RMAN 实用程序并连接到目标(主数据库)和辅助对象(新备用数据库)。
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
设置 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;
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 故障切换需要模拟缺少主数据库。最简单的方法是中止主数据库。这将使观察器在达到 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
启动 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_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 意味着满足成功进行故障切换的所有条件,包括正在运行的观察器和为满足持久性需求传输到故障切换目标的重做。本部分将介绍如何保持顶级 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 SYS
mkstore -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
John Smiley [jrsmiley@gmail.com] 是一家大型网上零售店的持久性存储架构师。