一、问题现象
在日常巡检过程中，发现 生产 ODA 与 办公 ODA 两套平台的 RAC 节点一均存在负载异常偏高现象，load average 一度达到 100+。
其中：
-
生产 ODA 节点一 load 约为
100+； -
办公 ODA 节点一 load 约为
115+； -
对应 RAC 节点二负载较低，未出现同类异常。
进一步查看发现，节点一虽然 load 较高，但 CPU idle 仍保持在 90% 以上，IO wait 为 0，内存及 Swap 未见明显压力。因此初步判断，该问题并非 CPU、内存、Swap 或 IO 资源打满导致，更像是异常进程堆积或进程等待导致 load 被拉高。
二、排查过程
1. 查看系统负载
巡检时通过 top 查看系统负载：
top
uptime发现 RAC 节点一 load 明显偏高，但系统资源未见明显瓶颈：
CPU idle 较高
IO wait 为 0
内存剩余充足
Swap 基本未使用因此初步排除 CPU 打满、IO 卡死、内存不足等常见问题。
2. 查看系统进程
继续查看节点一系统进程：
ps -ef在进程列表中发现大量异常进程，格式类似：
/bin/lsof -p <PID>
/bin/lsof -p <PID>
/bin/lsof -p <PID>这些进程具有明显异常特征：
root 用户运行
父进程 PPID = 1
启动时间为 May23
CPU 时间为 00:00:00
数量较多这些进程不是 Oracle 数据库核心进程，也不是正常业务应用进程，而是异常残留的 /bin/lsof -p 进程。
3. 精准筛选异常进程
发现异常进程后，进一步筛选确认：
ps -ef | grep lsof更精准筛选：
ps -ef | grep '[l]sof -p'确认节点一存在大量 /bin/lsof -p xxx 异常残留进程。
这些进程长期未退出，父进程已变成 1，说明原始调用进程已经结束，而这些 lsof 进程被系统接管，形成异常残留进程。
4. 对比 RAC 节点二
随后在对应 RAC 节点二进行同样检查，未发现类似大量 /bin/lsof -p 异常残留进程。
由此判断：
异常主要集中在 RAC 节点一，节点一 load 偏高与大量残留
lsof进程高度相关。
三、原因分析
1. 直接原因
本次 RAC 节点一 load 异常升高的直接原因是：
节点一存在大量异常残留的
/bin/lsof -p xxx进程，这些进程长期未退出，导致系统 load 被持续拉高。
虽然这些进程 CPU 时间显示为 00:00:00，但如果进程卡在文件系统、NFS、旧文件句柄或资源等待状态，仍可能被计入 load average。
因此会出现：
load 很高
CPU idle 仍然较高
IO wait 不一定明显
内存和 Swap 正常
业务不一定明显卡顿这类问题属于典型的 异常等待/残留进程导致 load 虚高。
2. 根本原因初步判断
结合异常进程启动时间均为 May23，而当天曾修改过异地备份服务器 IP 地址，初步判断本次问题与异地备份链路变更有关。
异地备份服务器 IP 由：
192.0.2.50调整为：
192.0.2.248同时，异地备份服务器的 NFS 备份路径主要挂载在 RAC 节点一 上。因此，IP 变更期间如果节点一上的 NFS 挂载、旧文件句柄、备份路径或备份相关进程出现异常，就可能主要影响节点一。
推测链路如下：
异地备份服务器 IP 调整
↓
异地备份 NFS 路径挂载在 RAC 节点一
↓
节点一 NFS 挂载 / 旧文件句柄 / 备份链路短时间异常
↓
相关巡检或排查动作执行 lsof -p
↓
lsof 访问异常资源时卡住
↓
节点一大量 lsof 进程残留
↓
节点一 load 持续偏高
↓
节点二未承载该 NFS 备份挂载路径，因此未出现同类异常四、处理措施
1. 清理异常 lsof 进程
清理前先确认异常进程：
ps -ef | grep '[l]sof -p'确认无误后，执行普通清理：
ps -ef | grep '[l]sof -p' | awk '{print $2}' | xargs -r kill等待几秒后复查：
ps -ef | grep '[l]sof -p'如仍有残留，再执行强制清理：
ps -ef | grep '[l]sof -p' | awk '{print $2}' | xargs -r kill -9清理完成后确认数量：
ps -ef | grep '[l]sof -p' | wc -l结果为：
0说明异常 lsof -p 残留进程已清理完成。
2. 清理后查看系统负载
清理异常进程后，再次查看系统负载：
top
uptime清理后 load 明显下降，系统状态恢复正常，CPU、内存、Swap、IO 指标均未见异常。
3. 检查 NFS 挂载状态
检查当前 NFS 挂载情况：
cat /proc/mounts | egrep '192.0.2.50|192.0.2.248|nfs'
findmnt | egrep '192.0.2.50|192.0.2.248|nfs'确认当前异地备份 NFS 已指向新 IP：
192.0.2.248未发现旧 IP 192.0.2.50 仍作为有效 NFS 挂载源。
4. 优化 RMAN 备份脚本
为防止后续 NFS 未挂载时，RMAN 误将备份写入本地目录，已分别对 办公 ODA 和 生产 ODA 的 RMAN 备份脚本增加 NFS 前置检查。
检查内容包括：
NFS 挂载点是否已挂载
RMAN 备份目录是否存在
RMAN 备份目录是否可写核心检查逻辑如下：
LOG_DIR="/home/oracle/rman/log"
NFS_DIR="/ODACDBbackup_nfs/192.0.2.101_CDB"
NFS_RMAN_DIR="${NFS_DIR}/rman"
TODAY=$(date +"%Y%m%d")
CHECK_LOG="${LOG_DIR}/nfs_check_${TODAY}.log"
mkdir -p "$LOG_DIR"
if ! mountpoint -q "$NFS_DIR"; then
echo "$(date '+%F %T') ERROR: NFS目录 $NFS_DIR 未挂载，停止备份，防止写入本地磁盘。" >> "$CHECK_LOG"
exit 1
fi
if [ ! -d "$NFS_RMAN_DIR" ]; then
echo "$(date '+%F %T') ERROR: RMAN备份目录 $NFS_RMAN_DIR 不存在，停止备份。" >> "$CHECK_LOG"
exit 1
fi
if [ ! -w "$NFS_RMAN_DIR" ]; then
echo "$(date '+%F %T') ERROR: RMAN备份目录 $NFS_RMAN_DIR 不可写，停止备份。" >> "$CHECK_LOG"
exit 1
fi同时将 nfs_check_*.log 纳入日志清理范围：
find "$LOG_DIR" -type f \( \
-name "*_backup_*.log" -o \
-name "*_ARCH_clean_*.log" -o \
-name "nfs_check_*.log" \
\) -mtime +$((KEEP_DAYS-1)) -print -delete五、处理结果
本次处理完成后：
异常 lsof 进程已清理
两套 ODA 节点一负载恢复正常
NFS 当前挂载正常
RMAN 备份目录可写
办公 ODA 和生产 ODA 备份脚本均已增加 NFS 防误写保护脚本验证结果：
bash -n 检查通过
NFS mounted OK
RMAN dir writable OK六、最终结论
本次两套 ODA RAC 节点一 load 异常偏高，并非 Oracle 数据库本身 CPU 打满，也不是内存、Swap 或 IO 故障导致。
最终判断为：
异地备份服务器 IP 变更后，由于异地备份 NFS 路径主要挂载在 RAC 节点一，节点一上的备份链路/NFS 相关资源曾出现异常，导致巡检或排查过程中产生的大量
/bin/lsof -p进程卡住未退出。这些残留进程长期堆积，造成 RAC 节点一 load 异常升高。清理异常进程后，系统负载恢复正常。
后续已完成 RMAN 备份脚本优化，增加 NFS 挂载点、备份目录存在性和可写性检查，防止类似问题再次引发备份异常或误写入本地磁盘。
简短总结
巡检发现生产 ODA 与办公 ODA 的 RAC 节点一 load 均异常偏高，达到 100+，而节点二负载较低。进一步查看节点一进程后，发现存在大量
/bin/lsof -p xxx异常残留进程，而节点二未发现类似情况。结合异常进程启动时间为 May23，且当天曾修改异地备份服务器 IP，同时异地备份 NFS 路径主要挂载在 RAC 节点一，判断为 IP 变更期间节点一备份/NFS 链路异常，导致lsof进程卡住并长期残留，最终推高节点一 load。清理异常进程后，负载恢复正常；同时已优化 RMAN 备份脚本，增加 NFS 挂载检查，防止后续备份异常写入本地目录。