RAC 容灾环境归档传输异常溯源

来源：这里教程网时间：2026-03-03 22:48:46 作者：

一、概述

本次故障发生在客户容灾环境，具体环境信息如下：

- 架构类型：双节点 Oracle RAC 集群；

- 数据库版本： Oracle 11.2.0.4 ，且已安装最新补丁；

- 部署平台：超融合平台，依托超融合的资源整合特性实现容灾环境的灵活部署与管理；

- 核心功能：通过 Oracle 容灾机制（如数据同步、归档日志传输）保障业务数据备份与业务连续性，支持故障切换与数据恢复。

二、故障背景与现象

（一）故障前置操作

因超融合平台资源紧张，客户需缩减容灾环境的系统资源分配，具体操作包括：

1. 通过超融合平台调低双节点服务器的 CPU 、内存配置；

2. 配合资源调整，同步修改数据库 SGA 、 PGA 及系统大页等常规内存参数；

3. 操作完成后重启双节点操作系统，计划恢复容灾环境的同步功能。

（二）故障核心现象

操作系统重启后，执行容灾同步恢复操作时出现异常，具体表现为：

1. 数据库实例可正常启动至只读状态，但开启 MRP （介质恢复进程）后，归档日志未如期从生产环境传递至备库；

2. 执行 `defer` 、 `enable` 命令重启归档传输开关，归档日志传输问题仍未解决；

3. 通过 `tnsping` 验证 1521 端口连通性，显示端口不通，初步判断网络或监听存在问题。

三、故障排查过程

（一）监听与实例注册问题定位

1. 通过 `su - grid 、 lsnrctl status` 检查容灾环境监听状态，发现监听服务已开启，但数据库实例未正确注册到监听；

2. 查看实例的 `remote listener` 和 `local listener` 参数，确认配置与预期一致，无参数错误；

3. 手工重置上述两个参数并执行 `alter system register` 触发生效，重新检查监听注册状态，问题依旧，排除参数配置异常。

（二）集群服务状态深度检查

1. 使用集群命令 `crsctl status res -t` 检查所有集群服务状态，发现监听资源 `ora.LISTENER.lsnr` 实际未启动（此前 “ 监听已开启 ” 为误判）；

2. 执行 `crsctl start res ora.LISTENER.lsnr` 尝试启动监听，系统报错提示 “ 依赖服务 `ora.net1.network` 未启动 ” ；

3. 进一步执行 `crsctl start res ora.net1.network` 启动依赖服务，显示启动失败，确定 `ora.net1.network` 服务为故障核心阻塞点。

（三）基础网络连通性验证

1. 检查双节点 public 网络互通性，通过 `ping` 命令测试节点间 IP 连通，结果正常，排除网络硬件故障；

2. 手工附加 VIP 至 public 网卡（命令： `ifconfig eth0:1 xxx.xxx.xx.29 netmask 255.255.255.0` ），操作可正常完成；

3. 执行 `ip addr del xxx.xxx.xx.29 dev eth0` 删除手工附加的 VIP ，操作无异常，确认网卡基础功能正常，排除网卡驱动或硬件问题。

（四）核心故障点定位（结合外部参考与客户确认）

1. 排查陷入瓶颈后，通过查询网络技术帖子，参考类似 `ora.net1.network` 启动失败案例，受启发检查网卡子网掩码配置，发现网卡 `eth0` 的子网掩码为 `255.255.255.128` ；

2. 为确认该子网掩码是否为预期配置，联系客户查阅其他正常环境的子网掩码设置，客户反馈当前 `255.255.255.128` 配置正确，排除 “ 子网掩码配置错误 ” 的初步猜想；

3. 结合 MOS 文档《 CRS-2674 Clusterware Network Resource ora.net1.network Could not Start (Doc ID 1270186.1) 》进行分析，通过 `srvctl config nodeapps` 、 `crsctl stat res ora.net1.network -f` 发现集群配置中 `ora.net1.network` 资源的子网掩码配置为 `255.255.255.0` ，与操作系统实际子网掩码 `255.255.255.128` 不匹配 —— 此为 `ora.net1.network` 服务启动失败的根本原因。

四、故障解决方案

（一）方案选择依据

根据客户反馈 “ 操作系统子网掩码配置正确 ” ，结合 MOS 文档建议，确定解决方案为：修改 OCR 中 `ora.net1.network` 资源的子网掩码配置，使其与操作系统实际配置一致，避免因修改操作系统配置引发其他网络依赖问题。

（二）具体操作步骤

1. 以 `root` 用户登录集群节点，使用 `srvctl` 命令修改集群网络资源配置（适配实际子网掩码 `255.255.255.128` ），命令如下（需替换 `<subnet IP>` 为实际子网地址、 `<interface>` 为网卡名，如 `eth0` ）：

srvctl modify nodeapps -n <HOSTNAME>1 -A <HOSTNAME>1-vip/255.255.255.128/bond0

2. 执行命令启动 `ora.net1.network` 服务，验证启动结果：

crsctl start res ora.net1.network

crsctl status res ora.net1.network # 确认状态为 “ONLINE”

3. 启动监听资源及相关依赖服务，恢复实例注册与归档传输：

crsctl start res ora.LISTENER.lsnr # 启动监听

alter system register; # 触发实例注册到监听

4. 验证归档日志传输功能，确认 MRP 进程正常运行，容灾同步恢复正常。

五、故障总结与预防措施

（一）故障根因总结

本次故障的核心原因是 “ 配置同步缺失 ” ：操作系统子网掩码修改后，未同步更新 Oracle 集群 OCR 中的网络资源配置，导致 `ora.net1.network` 服务因 “OCR 配置与实际环境不匹配 ” 无法启动，进而阻塞监听启动、实例注册及归档传输，引发一系列容灾同步问题。

（二）后续预防措施

1. 建立配置变更同步机制：涉及集群环境的网络配置（子网掩码、 IP 、网卡）或系统资源变更时，必须同步检查并更新 Oracle 集群配置（优先使用 `srvctl` 、 `crsctl` 等官方工具），操作后通过 `srvctl config network` 、 `ocrcheck` 验证配置一致性；