在Oracle RAC中怎样利用ASH分析节点间网络丢包-Oracle-PHP中文网

ASH不记录网络丢包，仅反映Oracle内核感知的等待结果；需将其作为“症状指示器”，结合ocssd.log心跳日志、ping延迟分布及ethtool网卡统计交叉验证丢包。

在oracle rac中怎样利用ash分析节点间网络丢包

ASH 本身不记录网络丢包，查 gv$active_session_history 永远看不到 “TCP packet loss” 或 “retransmit” 这类事件——它只反映 Oracle 内核感知到的等待结果。真要定位节点间丢包，得把 ASH 当作“症状指示器”，再结合底层网络日志和系统指标交叉验证。

为什么 ASH 里找不到丢包，却还要先看它？

因为丢包会引发可观察的、带时间戳的等待毛刺，而 ASH 是唯一能秒级捕获这些毛刺的数据库视图。重点不是找“丢包”，而是找丢包引发的典型连锁反应：

gc buffer busy acquire 在多个节点上同时激增，且 time_waited 分布出现大量 >5ms 的样本（正常应
同一时间段内，gc cr block busy 和 gc current block 2-way 等待事件在不同节点呈镜像式此消彼长
enq: TX - row lock contention 出现跨实例阻塞链（blocking_instance != inst_id），但持锁会话本身 CPU 使用率极低、SQL 执行快，说明不是锁逻辑问题，而是 GC 块没及时送达

用 GV$ASH 快速筛出可疑时段和节点

别扫全表，也别依赖 AWR 报告里的笼统统计。直接跑这个查询，聚焦最近 3 分钟：

SELECT inst_id, event, COUNT(*) cnt, 
       ROUND(AVG(time_waited)/1000, 1) avg_ms,
       ROUND(STDDEV(time_waited)/1000, 1) std_ms
FROM gv$active_session_history 
WHERE sample_time > SYSDATE - 3/1440
  AND event IN ('gc buffer busy acquire',
                'gc cr block busy',
                'gc current block 2-way',
                'gc cr block busy')
GROUP BY inst_id, event
HAVING AVG(time_waited) > 5000  -- 平均等待超 5ms
ORDER BY avg_ms DESC;

如果某节点 gc buffer busy acquire 的 avg_ms 明显高于其他节点（比如 12.3 vs 其他节点平均 1.8），且 std_ms 很大（如 28.7），说明延迟抖动严重——这比稳定高延迟更指向丢包或乱序。

QuantOracle

63个确定性量化金融计算器 + 10个通过MCP的复合工作流。期权定价、Greeks、奇异衍生品、风险指标、投资组合优化……

下载

确认丢包后，下一步必须跳到操作系统层

ASH 只告诉你“可能丢了”，真要坐实，立刻切到节点操作系统：

查心跳日志：/oracle/11.2.0/grid/log//cssd/ocssd.log，搜 CRS-1611（75% 心跳丢失）和 CRS-1610（90% 丢失），多节点密集出现即铁证
用 ping -c 100 -i 0.1 看延迟分布：>5ms 的包占比超过 5%，GC 等待必然上扬；若出现超时（timeout）行，基本可断定丢包
跑 ethtool -S eth2 | grep -E "(rx_discards|tx_aborted_errors|rx_errors)"，只要非零，就是网卡、驱动或交换机层面的问题，和 Oracle 参数无关

最容易被忽略的是：gc buffer busy acquire 高并不等于存储慢，也不等于 SQL 写法差——在 RAC 里，它大概率是网络抖动的第一张多米诺骨牌。等你在 ASH 里看到它，网络问题通常已持续几十秒，必须立刻停止查 SQL 执行计划，转去翻 ocssd.log 和 ping 结果。