v$active_session_history常查不到SQL*Net message to dblink，因其等待持续时间常低于1秒、仅记录非空闲等待态，且该事件只反映本地发包后等ACK的瞬时状态，不体现远程实际延迟；需结合v$system_event全局统计（看占比与平均耗时）和严苛过滤的ASH查询（时间、状态、等待阈值）交叉验证，并通过p1raw关联v$dblink推测DB Link名称。
直接查 v$active_session_history 很可能看不到 db link 的真实等待瓶颈，因为 sql*net message to dblink 事件只在本地实例采样，且容易被高负载冲刷掉；必须结合时间范围、等待阈值和 v$system_event 交叉验证。
为什么 v$active_session_history 常查不到 SQL*Net message to dblink
ASH 每秒采样一次，但只记录“正在等待且非空闲”的会话；而 SQL*Net message to dblink 是瞬时发送后的确认等待，持续时间常低于 1 秒（尤其网络良好时），极易漏采。更关键的是：该事件不反映远程数据库的处理延迟，只卡在本地发包后等 ACK 的阶段——所以即使远程已卡死，本地 ASH 也可能只记几毫秒或完全不记。
常见误判现象：
- ASH 中
event列查不到'SQL*Net message to dblink'，但业务明显变慢 - 查到少量该事件，
time_waited却只有几十微秒，与实际感知延迟严重不符 - 同一 SQL ID 在 ASH 中频繁出现，但
sql_id关联不到具体 DB Link 名称
必须用 v$system_event 先确认是否真有问题
先看全局等待占比和单次耗时，避免在低影响事件上浪费排查时间：
SELECT event, total_waits, time_waited_ms,
ROUND(100 * time_waited_ms / SUM(time_waited_ms) OVER(), 2) pct,
ROUND(time_waited_ms / NULLIF(total_waits, 0), 2) avg_ms
FROM v$system_event
WHERE event = 'SQL*Net message to dblink';健康参考线：
- 总占比
pct < 3%—— 通常可忽略 - 平均单次
avg_ms < 20—— 网络层基本正常 - 若
avg_ms > 100或pct > 5%，才值得进 ASH 深挖
注意：v$system_event 是累积统计，不带时间粒度，所以它告诉你“有没有问题”，ASH 才负责回答“什么时候、谁、在哪条 SQL 上出的问题”。
查 ASH 时要加严苛的时间和状态过滤
默认查 v$active_session_history 容易捞出噪音数据。必须锁定真实阻塞窗口，并排除瞬时抖动：
- 时间条件必须用动态表达式：
SAMPLE_TIME > SYSDATE - INTERVAL '5' MINUTE，不能写死时间点 - 强制过滤
session_state = 'WAITING'，避免把 CPU 运行态混进来 - 显式指定
event = 'SQL*Net message to dblink'（注意大小写和空格，不是大写或下划线） - 加上
time_waited > 50000（即 > 50ms），过滤掉无意义的微等待
示例语句：
SELECT sample_time, session_id, sql_id,
p1text, p1, p2text, p2,
time_waited
FROM v$active_session_history
WHERE event = 'SQL*Net message to dblink'
AND session_state = 'WAITING'
AND time_waited > 50000
AND sample_time > SYSDATE - INTERVAL '5' MINUTE
ORDER BY time_waited DESC;其中 p1 和 p2 是 DB Link 的内部标识符，虽不能直接映射名称，但相同值反复出现，说明是同一个 DB Link 实例在拖慢多个会话。
定位具体 DB Link 名称只能靠 v$dblink 关联
v$active_session_history 不存 DB Link 名，但 p1raw 字段里藏了线索。Oracle 内部用 p1raw 的后半段匹配 v$dblink.name：
SELECT a.sample_time, a.session_id, a.sql_id,
d.name AS dblink_name,
a.time_waited
FROM v$active_session_history a
JOIN v$dblink d ON SUBSTR(a.p1raw, INSTR(a.p1raw, ':') + 1) = d.name
WHERE a.event = 'SQL*Net message to dblink'
AND a.time_waited > 50000
AND a.sample_time > SYSDATE - INTERVAL '5' MINUTE;这个关联不 100% 可靠（依赖 p1raw 格式稳定），但比纯猜强得多。如果 v$dblink 查不到对应 name，大概率是 DB Link 已失效或未在当前会话中打开过。
真正棘手的地方在于：DB Link 等待本身不暴露远程 SQL，你看到的只是“本地发完包在等回音”。要继续往下查，得切到远程库，用它的 v$session 和 v$transaction 看谁在执行、有没有锁、事务是否卡住——这已经超出 ASH 能力边界了。
