Oracle 11g RAC ADG搭建全记录：从IP规划到Broker配置的23个关键步骤

企业级Oracle 11g RAC与ADG混合架构部署：从零构建高可用数据保护屏障

在核心业务系统架构中，数据的高可用性与灾难恢复能力是衡量技术架构成熟度的关键标尺。对于许多依赖Oracle数据库的企业而言，将Oracle Real Application Clusters 与 Active Data Guard 相结合，构建一个既能提供本地高可用、又能实现异地数据实时保护的环境，已成为生产系统的标准配置。然而，从零开始搭建一套跨越RAC集群与单实例备库的混合架构，绝非简单的软件安装，它更像是一场对架构师全局规划能力、对运维人员细节掌控力的综合考验。本文将从一个真实的、面向生产的视角出发，抛开那些“小白友好”的简化步骤，深入探讨在规划、部署、调试一个双节点RAC到单实例ADG环境时，那些真正决定成败的23个关键环节与深层逻辑。

1. 架构蓝图与前置规划：奠定成功的基石

在敲下第一条命令之前，缜密的规划是避免后续无数“坑”的唯一途径。一个典型的双节点RAC到单实例ADG架构，其核心在于网络、存储与资源的清晰隔离与高效协同。

网络拓扑规划是首要任务。你需要为至少三个网络平面做好准备：面向客户端的公共网络、用于集群内部心跳与缓存融合的私有网络，以及用于Data Guard数据传输的专用网络（可选，但生产环境强烈建议）。IP地址的分配必须遵循清晰、可扩展的命名规范。例如，我们可以采用以下结构：

注意：SCAN IP是Oracle RAC 11gR2引入的特性，它为客户端提供了一个统一的、可解析到多个后端节点的域名。在DNS或/etc/hosts中，需要将其解析到所有集群节点。私有网络务必使用独立的、高带宽、低延迟的物理网卡，并确保交换机端口配置了多播支持。

存储规划同样关键。对于RAC环境，共享存储是集群的“心脏”。我们需要为不同的用途创建独立的ASM磁盘组。通常，DATA磁盘组用于存放数据文件、控制文件、在线重做日志；FRA磁盘组用于快速恢复区，存放归档日志、备份文件；OCR和Voting Disk则需要单独的、高可用的磁盘（通常三个以形成奇数仲裁）。在虚拟化环境中，确保这些磁盘以“独立-持久”模式附加，并正确配置SCSI总线共享。

# 示例：在VMware ESXi环境下，通过.vmx文件配置共享磁盘
scsi1.shared = "TRUE"
disk.locking = "FALSE"
scsi1:0.present = "TRUE"
scsi1:0.fileName = "/vmfs/volumes/datastore1/rac-shared/asm-data01.vmdk"
scsi1:0.mode = "independent-persistent"

操作系统与用户准备是最后一道前置工序。确保所有节点使用相同版本和补丁级别的操作系统（如Oracle Linux 7.9）。通过oracle-database-preinstall-19c这样的预安装包可以快速完成大部分内核参数、用户组和依赖包的配置，但切记要根据11g RAC的特定要求进行复查和调整，特别是hugepages、aio-max-nr等参数。

2. RAC集群的精细部署：网格与数据库的协同

安装Grid Infrastructure是构建RAC的第一步。这个过程不仅仅是运行runInstaller，更重要的是理解每个选项背后的含义。

Grid安装的静默与交互：在生产环境中，我倾向于使用响应文件进行静默安装，这能确保环境的一致性，并便于自动化。关键配置项包括：

• 集群类型：选择“为数据库配置集群”
• SCAN配置：正确填写SCAN名称和端口，确保网络解析无误。
• GNS配置：对于简单环境，通常选择“不使用GNS”。
• 存储选项：为OCR和Voting Disk选择“外部冗余”的ASM磁盘组，并指定三个候选磁盘。

安装过程中最常见的“拦路虎”是在执行root.sh脚本时，ohasd服务启动失败。在Oracle Linux 7及以上版本中，这是因为系统从initd转向了systemd。解决方法是为ohasd创建一个systemd服务单元。

# 创建并启用ohasd的systemd服务
cat > /usr/lib/systemd/system/ohas.service << 'EOF'
[Unit]
Description=Oracle High Availability Services
After=syslog.target

[Service]
ExecStart=/etc/init.d/init.ohasd run >/dev/null 2>&1
Type=simple
Restart=always

[Install]
WantedBy=multi-user.target
EOF

systemctl daemon-reload
systemctl enable ohas.service
systemctl start ohas.service

数据库软件安装与补丁：在Grid就绪后，安装Oracle数据库软件。这里有一个经典的“坑”：在较新的Linux 7系统上安装11g，编译agent nmhs时会报错。解决方法是在ins_emagent.mk文件中链接libnnz11.so库。

# 修改 $ORACLE_HOME/sysman/lib/ins_emagent.mk
# 找到 $(MK_EMAGENT_NMECTL) 这一行，在最后添加 -lnnz11
$(MK_EMAGENT_NMECTL) -lnnz11

安装完成后，**立即打上最新的PSU（Patch Set Update）或BP（Bundle Patch）**是必须的。对于11.2.0.4，P31718723是一个关键的补丁集。使用OPatch工具时，务必先更新OPatch本身到兼容版本，然后分别在Grid和Oracle Home下应用补丁。

创建ASM磁盘组与数据库实例：通过asmca图形化工具或命令行创建DATA和FRA磁盘组。随后使用dbca创建集群数据库。这里的关键是选择“Admin-Managed”还是“Policy-Managed”管理方式，以及正确配置每个实例的服务名和存储位置。创建完成后，必须检查集群状态。

-- 以grid用户检查集群资源状态
crsctl status res -t
-- 以oracle用户检查数据库实例状态
srvctl status database -d <db_name>

3. 构建物理备库：从克隆到同步

备库的构建始于一个与主库环境尽可能一致的“空白”服务器。网络、存储、操作系统、用户、软件目录结构都应镜像主库RAC节点。

备库的“轻量级”Grid安装：备库是单实例，但为了使用ASM存储，仍然需要安装Grid Infrastructure，但选择“为独立服务器配置”即可。这会在备库上安装一个单节点的Oracle Restart环境，用于管理ASM实例和监听器。

参数文件的准备与定制：这是连接主备库的逻辑桥梁。首先从主库生成一个参数文件（pfile），然后对其进行关键修改以适配备库角色。

-- 在主库生成pfile
CREATE PFILE='/tmp/init_orcl_standby.ora' FROM SPFILE;

将生成的pfile拷贝到备库，并修改以下核心参数：

• db_unique_name：设置为备库的唯一名称，如orcl_sby。
• fal_server和fal_client：配置故障归档日志传输服务。
• log_archive_config：启用Data Guard配置。
• log_archive_dest_1和log_archive_dest_2：分别配置本地归档路径和到备库的归档传输服务。
• standby_file_management：设置为AUTO，以便自动管理备库数据文件。
• dg_broker_start和dg_broker_config_file：为后续启用Broker做准备。

使用RMAN Active Duplicate进行数据同步：这是最高效的备库创建方式，它通过网络直接从主库“拉取”数据，无需中间备份文件。这个过程需要主备库之间建立完好的TNS连接。

# 在备库服务器上执行RMAN命令
rman TARGET sys/<password>@ORCL_PRIMARY AUXILIARY sys/<password>@ORCL_STANDBY
DUPLICATE TARGET DATABASE FOR STANDBY FROM ACTIVE DATABASE NOFILENAMECHECK;

这个命令会执行以下操作：

1. 在备库启动实例到NOMOUNT状态。
2. 从主库恢复备库控制文件。
3. 通过网络直接恢复所有数据文件到备库ASM磁盘组。
4. 应用必要的归档日志，将备库置于一致状态。

提示：确保主库的FORCE LOGGING已开启，并且已创建了足够数量的STANDBY LOGFILE组（通常比在线重做日志组多一组）。这能保证所有数据变更都能被传输到备库，并避免备库应用日志时因日志组不足而挂起。

4. Data Guard Broker的配置与高级管理

当主备库数据同步完成后，手动管理角色切换、监控状态会变得繁琐。Data Guard Broker提供了一个统一的管理框架，将多个数据库作为一个整体配置来管理。

启用与初始化Broker配置：首先确保所有节点的dg_broker_start参数为TRUE，并且配置文件路径指向共享或可访问的位置（如ASM磁盘组）。

-- 在主库检查并启用Broker参数
ALTER SYSTEM SET dg_broker_start=TRUE SCOPE=BOTH;
ALTER SYSTEM SET dg_broker_config_file1='+DATA/dr1orcl.dat' SCOPE=SPFILE;
ALTER SYSTEM SET dg_broker_config_file2='+FRA/dr2orcl.dat' SCOPE=SPFILE;

然后通过DGMGRL命令行工具创建配置。

-- 连接到主库，创建Broker配置
DGMGRL> CONNECT sys/<password>@ORCL_PRIMARY
DGMGRL> CREATE CONFIGURATION 'DG_ORCL' AS
      > PRIMARY DATABASE IS 'ORCL_PRIMARY'
      > CONNECT IDENTIFIER IS ORCL_PRIMARY;
DGMGRL> ADD DATABASE 'ORCL_STANDBY' AS
      > CONNECT IDENTIFIER IS ORCL_STANDBY
      > MAINTAINED AS PHYSICAL;
DGMGRL> ENABLE CONFIGURATION;

配置保护模式与重做传输：Broker允许你轻松设置数据保护模式（最大性能、最大可用性、最大保护）和重做传输模式（SYNC同步或ASYNC异步）。

DGMGRL> EDIT CONFIGURATION SET PROTECTION MODE AS MAXAVAILABILITY;
DGMGRL> EDIT DATABASE 'ORCL_STANDBY' SET PROPERTY LogXptMode='SYNC';
DGMGRL> EDIT DATABASE 'ORCL_PRIMARY' SET PROPERTY LogXptMode='SYNC';

• 最大性能模式：默认模式，重做数据异步传输，对主库性能影响最小，但可能丢失少量数据。
• 最大可用性模式：重做数据同步传输，确保提交事务的数据在至少一个备库落盘后才向应用返回成功。这是高可用场景的常见选择。
• 最大保护模式：最高级别的保护，要求同步传输且必须成功，否则主库会停止服务。对网络稳定性要求极高。

监控与角色切换：Broker提供了清晰的监控视图。SHOW CONFIGURATION和SHOW DATABASE VERBOSE <db_name>命令可以查看配置状态、延迟、应用状态等详细信息。

最强大的功能之一是无缝的角色切换。无论是计划内的维护（SWITCHOVER）还是灾难发生时的故障转移（FAILOVER），Broker都能极大地简化流程。

-- 计划内切换（主备角色互换）
DGMGRL> SWITCHOVER TO 'ORCL_STANDBY';
-- 执行后，原备库成为新的主库，原主库成为新的备库，整个过程对应用透明（需配合TNS配置）。

-- 灾难恢复时的故障转移（原主库可能丢失数据）
DGMGRL> FAILOVER TO 'ORCL_STANDBY';
-- 故障转移后，原配置被破坏，需要重建。

在实际生产运维中，我习惯为关键的Broker命令编写Shell脚本，并结合监控系统（如Zabbix或Prometheus）对V$DATAGUARD_STATS、V$ARCHIVED_LOG等视图进行监控，实时掌握数据同步的健康状况。例如，监控transport lag和apply lag，确保它们保持在可接受的阈值内，是保证灾备有效性的日常工作。