文章
企业管理
Oracle RAC One Node 和 Oracle Data Guard 配置 DBA 指南，第 2 部分（高级）
作者：Martin Bach
在本部分中，您将了解此配置的更高级的手动方法。
2011 年 7 月发布
在本文的第 1 部分，我们介绍了 Oracle RAC One Node 和 Oracle Data Guard 的 Oracle Data Guard Broker 配置。此配置非常适合经验不足的 DBA，他们不希望或不需要控制角色转换中的每一步。此外，该代理非常适合自动化至关重要或人员经验不足的情况。在本部分中，我们将研究可以为 DBA 提供更精细控制的手动配置。
与代理方式不同，手动配置 Oracle Data Guard 要求用户更好地了解过程以及 Oracle Data Guard 的工作方式，还要求用户更注意细节，确保所有备用数据库上的配置都相同。随着 Oracle 11.2 中备用数据库的配置增加到 30 个，这一点变得更加重要。
创建手动 Oracle Data Guard 配置
令人惊讶的是，Oracle RAC One Node 备用数据库的配置方式与 Oracle RAC 数据库的配置方式并无差异。一般而言，您必须在每个数据库（主数据库和备用数据库）上执行配置步骤。做好主数据库用作备用数据库的准备非常重要，包括创建备用重做日志。问题不在于角色更改是否将作为任务出现在您的桌面上，而是何时发生。记住，数据库不一定是体系中的故障组件 — 中间层问题同样可能导致大规模停机。
要针对备用数据库进行修改的主要初始化参数是 log_archive_dest_n 参数，它定义将存档日志传送到何处以及发生传送的角色。对 Oracle Data Guard 的实际改进之一出自 Oracle Database 10g，允许基于数据库角色配置日志传送。换句话说，您可以在主数据库上配置日志传送，指示它仅在处于备用角色时才发送重做。
我们来看看这在现实中是如何实现的。首先配置主数据库。
SQL alter system set log_archive_dest_2=
2> 'service=RONDG valid_for=(online_logfiles,primary_role) db_unique_name=RONDG';
System altered.
SQL> alter system set fal_server=RONDG;
System altered.
SQL> alter system set log_archive_config='dg_config=(RON,RONDG)';
System altered.
SQL> alter system set standby_file_management='auto';
System altered.
这些步骤是创建一个配置所必需的最少步骤。log_archive_dest_2 参数指定数据库 RON 应在处于主角色时向服务“RONDG”提交重做。Oracle Data Guard 概念和管理 指南包括所有选项，较有趣的可能是围绕压缩选项的部分（可能需要 Advanced Compression 选件）。使用 Oracle 11.1 时，可以对差异消除（FAL — 获取存档日志）所产生的流量进行压缩以节省带宽，现在使用 11.2，甚至可以压缩普通重做日志传送。
备用数据库上所需的配置步骤非常类似，只是与前面的相反：
SQL alter system set log_archive_dest_2=
2> 'service=RON valid_for=(online_logfiles,primary_role) db_unique_name=RON';
System altered.
SQL> alter system set fal_server=RON;
System altered.
SQL> alter system set log_archive_config='dg_config=(RON,RONDG)';
System altered.
SQL> alter system set standby_file_management='auto';
System altered.
还可以在此阶段选择为备用数据库（及主数据库！）创建备用重做日志文件以便实时应用。如果您有此计划，则应为每个线程添加备用重做日志，其大小与联机重做日志相同。一份已经足够；无需多份重做日志。同时，对于每个线程，应在现有组之外再创建一个备用重做日志组。
在我们的主数据库中，有两个线程（实例 RON_1 当前已启动并正在运行，这解释了线程 2 处于关闭状态的原因）：
RON SQL> select thread#,status,enabled,groups from v$thread;
THREAD# STATUS ENABLED GROUPS
---------- ------ -------- ----------
1 OPEN PUBLIC 2
2 CLOSED PUBLIC 2
RON SQL>
您可以进一步查询 v$log 来查看每个线程的大小和包含的组。Bytes、group# 和 thread# 这几列显示了重要信息。
之后添加备用重做日志就变得很简单。对于每个线程，添加组数 + 1 个备用重做日志。对于我的数据库，每个线程有 5 个组，所使用的命令可如下所示：
BEGIN
FOR THREAD IN 1..2 LOOP
FOR LOGFILE IN 1..6 LOOP
EXECUTE IMMEDIATE'ALTER DATABASE ADD LOGFILE THREAD ' || THREAD || ' SIZE 150M';
END LOOP;
END LOOP;
END;
/
这将为每个线程创建 6 个备用重做日志，足够实时应用。现在启用管理恢复以完成配置。
SQL> alter database recover managed standby database using current logfile
2 disconnect from session;
现在您应看到介质恢复正在进行 — 警报日志应生成如下行：
Media Recovery Log +FRA/rondg/archivelog/2011_03_29/thread_1_seq_265.270.747054265
Media Recovery Log +FRA/rondg/archivelog/2011_03_29/thread_1_seq_266.271.747054265
Media Recovery Log +FRA/rondg/archivelog/2011_03_29/thread_1_seq_267.261.747048749
好，您已步入正轨！在结束用于实现 Oracle Data Guard 配置的任务之前，我通常会检查日志传送是否正常。
测试 Data Guard 日志传送
成功配置后的第一步是测试日志传送是否正常。以下是一个示例：在执行日志切换之前，我要从主数据库查询当前日志序列号：
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 297
Next log sequence to archive 300
Current log sequence 300
SQL> alter system switch logfile
System altered.
在日志切换之前，备用数据库的当前序列号已达 299。日志切换之后，它报告了应用的新日志：
SQL> select max(sequence#) from v$log_history;
MAX(SEQUENCE#)
--------------
299
-- log switch on primary
SQL> /
MAX(SEQUENCE#)
--------------
300
在 Oracle RAC 数据库中，必须在以上查询中考虑到各个线程，但对于 Oracle RAC One Node，因为仅有一个活动实例，则无需如此。这对于自定义监视脚本的开发人员是一个好消息。
闪回数据库
为了安全起见，在切换之前我通常会在所有涉及的数据库上启用闪回数据库 — 这也包括备用数据库！检查闪回数据库是否已启用很简单，如果未启用，纠正也很简单。考虑以下未启用闪回的 RONDG 数据库的示例：
SQL> select db_unique_name,database_role,flashback_on from v$database
2 /
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RONDG PHYSICAL STANDBY NO
SQL> alter database recover managed standby database cancel;
Database altered.
SQL> alter database flashback on
Database altered.
SQL> alter database recover managed standby database using current logfile
2 disconnect from session;
Database altered
SQL> select db_unique_name,database_role,flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RONDG PHYSICAL STANDBY YES
测试正常切换
所有 Oracle Data Guard 配置必须定期进行切换测试才算完整的。许多经验丰富的 Oracle 讲师和该领域有经验的 DBA 还建议定期进行故障切换，但我访问的大多数地方都拒绝这种严格的测试。下一节将介绍故障切换。
在开始任何切换操作之前，比较稳健的做法是确保登录到正确的数据库并在所有涉及的数据库上启用了闪回。在这种情况下，操作如下：
SQL> select db_unique_name,database_role, flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RON PRIMARY YES
SQL> select db_unique_name,database_role, flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RONDG PHYSICAL STANDBY YES
在主数据库上启动切换命令，如下所示：
SQL> alter database commit to switchover to physical standby with session shutdown;
Database altered.
SQL> shutdown immediate
ORA-01507: database not mounted
ORACLE instance shut down.
[oracle@node1 ~]$ srvctl start database -d RON -o mount
[oracle@node1 ~]$ srvctl status database -d RON
Instance RON_1 is running on node node1
Online relocation: INACTIVE
连接到数据库可以看到角色确实已更改：
SQL> select db_unique_name,database_role from v$database;
DB_UNIQUE_NAME DATABASE_ROLE
------------------------------ ----------------
RON PHYSICAL STANDBY
现在剩下的就是启用管理恢复：
SQL> alter database recover managed standby database
2 using current logfile
3 disconnect from session;
Database altered.
您还应使用 srvctl modify database 将数据库的角色更新为物理备用以避免违反许可（当然，除非您拥有 Oracle Active Data Guard）。
在备用数据库上，完成 alter database commit to switchover... 后发出以下命令将其转为主数据库：
SQL> alter database commit to switchover to primary;
Database altered.
SQL> alter database open;
Database altered.
SQL> select db_unique_name,database_role,flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RONDG PRIMARY YES
检查日志传送是否正常很重要，使用与前面相同的方法。首先查询主数据库：
SQL> archive log list
Database log mode Archive Mode
Automatic archival Enabled
Archive destination USE_DB_RECOVERY_FILE_DEST
Oldest online log sequence 304
Next log sequence to archive 304
Current log sequence 304
SQL> alter system switch logfile;
System altered.
接着检查备用数据库：
SQL> select max(sequence#) from v$archived_log where applied='YES' and
2 resetlogs_change#=(select max(resetlogs_change#) from v$archived_log);
MAX(SEQUENCE#)
--------------
305
您还可以在 ADRCI 中执行 show alert –tail –f option 以便在 Oracle 传送、存档和应用日志时进行跟踪。视图 V$MANAGED_STANDBY 也非常有用。
最后启动服务 RON_APP.example.com 并使用 srvctl modify database 更新 RONDG 的配置以反映它现在是主数据库。
测试故障切换
在目前这种情况的基础上，下一步是测试故障切换。在 Oracle Database 10g 之前，故障切换意味着必须从备份恢复故障数据库。所幸现在情况已经发生了变化！在下一节，我将探讨如何充分利用闪回数据库特性最大限度减少恢复数据库所需的工作量。
在正常切换到 RONDG 的上一示例之后，我们来模拟主数据库 RONDG 上出现故障：
SQL> select db_unique_name,database_role,flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RONDG PRIMARY YES
[oracle@drnode1 ~]$ srvctl stop database -d RONDG -o abort
假设主数据库不能在认可的服务级别下重新启动，因此必须激活备用数据库。以下示例显示备用数据库上的步骤：
SQL> ALTER DATABASE RECOVER MANAGED STANDBY DATABASE FINISH;
Database altered.
SQL> ALTER DATABASE ACTIVATE PHYSICAL STANDBY DATABASE;
Database altered.
SQL> select db_unique_name,database_role,flashback_on from v$database;
DB_UNIQUE_NAME DATABASE_ROLE FLASHBACK_ON
------------------------------ ---------------- ------------------
RON PRIMARY YES
完成之后，服务已恢复，且应用程序团队忙于将其应用服务器重新指向新数据库。同样，不要忘记在 Oracle 集群注册表中反映配置更改。如果尚未启动，请确保在将系统移交给应用服务器团队之前已在 RONDG 上启动了服务 RON_APP.example.com。
将旧的主数据库恢复为物理备用数据库
如前所述，在 Oracle 9i Database 及之前版本中，激活备用数据库意味着大量工作，但幸运的是使用闪回数据库可以避免这种麻烦。（不过仅限于所需的全部日志仍然存在的情况下！）。新的主数据库保留了其被激活时的系统更改号 (SCN) 的记录：
SQL> select standby_became_primary_scn , database_role from v$database
STANDBY_BECAME_PRIMARY_SCN DATABASE_ROLE
-------------------------- ----------------
1397880 PRIMARY
旧的主数据库 RONDG 已闪回至这个 SCN 并重新转换为物理备用数据库。问题纠正之后，可以重新启动该数据库：
[oracle@drnode1 ~]$ sqlplus / as sysdba
SQL*Plus: Release 11.2.0.2.0 Production on Fri Dec 31 14:50:19 2010
Copyright (c) 1982, 2010, Oracle. All rights reserved.
Connected to an idle instance.
SQL> startup mount
ORACLE instance started.
Total System Global Area 4275781632 bytes
Fixed Size 2233336 bytes
Variable Size 2348813320 bytes
Database Buffers 1912602624 bytes
Redo Buffers 12132352 bytes
Database mounted.
SQL> flashback database to scn 1397880;
Flashback complete.
SQL> alter database convert to physical standby;
Database altered.
SQL> shutdown immediate
sORA-01507: database not mounted
ORACLE instance shut down.
SQL> startup mount
ORACLE instance started.
Total System Global Area 4275781632 bytes
Fixed Size 2233336 bytes
Variable Size 2348813320 bytes
Database Buffers 1912602624 bytes
Redo Buffers 12132352 bytes
Database mounted.
SQL> select db_unique_name,database_role from v$database;
DB_UNIQUE_NAME DATABASE_ROLE
------------------------------ ----------------
RONDG PHYSICAL STANDBY
SQL> alter database recover managed standby database disconnect from session
2 /
在声明系统正常之前，应再次验证日志传送和应用程序。稍后执行正常切换可以一切恢复如旧。
总结
在这个由两部分组成的文章中，我们学习了如何通过将 ACFS 用于诊断目标和其他管理文件来配置 Oracle RAC One Node 主数据库的物理备用数据库。在 Oracle 集群注册表中注册了备用数据库，并且创建和测试了手动和代理配置。可以采用该案例进一步尝试快速启动故障切换来实现 RON 环境的无人值守，但这留待读者自行练习。
Martin Bach 是居住在英国的 Oracle 兼职顾问，他与人合著了《Pro Oracle Database 11g RAC on Linux》(Apress)。
Printer View