直接查v$active_session_history难见db link真实延迟，因sql*net message to dblink是瞬时等待（常
为什么直接查 v$active_session_history 很难看到 db link 真实延迟
因为 sql*net message to dblink 是瞬时等待：本地发包后等 ack，持续时间常低于 1 秒，ash 每秒采样一次且只记录非空闲等待态，极易漏掉。它不反映远程数据库的执行耗时，只卡在本地网络层确认阶段——哪怕远程已 hang 死，ash 可能只记几十微秒，甚至完全不出现。
常见误判现象包括：
-
EVENT列查不到'SQL*Net message to dblink'，但业务明显变慢 - 查到少量该事件，
TIME_WAITED却只有几十微秒，与实际延迟严重不符 - 同一
SQL_ID在 ASH 中高频出现，但无法关联到具体 DB Link 名称
先用 v$system_event 确认问题是否真实存在
ASH 是“谁、何时、哪条 SQL”出问题，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 —— 通常可忽略 - 平均单次
avg_ms —— 网络层基本正常 -
avg_ms > 100或pct > 5%，才值得进 ASH 深挖
ASH 中定位 DB Link 延迟的实操要点
必须严苛过滤，否则结果无意义。关键条件缺一不可：
- 限定时间范围：
SAMPLE_TIME > SYSDATE - 1/24（最近 1 小时） - 强制等待阈值：
TIME_WAITED > 100000（单位微秒，即 >100ms） - 关联
P1RAW推测 DB Link 名称：SELECT DISTINCT UTL_RAW.CAST_TO_VARCHAR2(P1RAW) FROM V$ACTIVE_SESSION_HISTORY WHERE EVENT = 'SQL*Net message to dblink' AND TIME_WAITED > 100000 - 结合
SQL_ID查V$SQL获取完整语句，再人工识别是否含@符号或远程对象引用
注意：V$ACTIVE_SESSION_HISTORY 重启即清空，长期趋势需查 DBA_HIST_ACTIVE_SESS_HISTORY，但后者延迟高、采样粒度粗，不适合定位瞬时 DB Link 延迟。
真正瓶颈往往不在本地，而要交叉验证远程端
DB Link 延迟本质是分布式事务链路问题，单看本地 ASH 只能看到“最后一公里”。必须同步检查：
- 远程库的
v$system_event中SQL*Net message from client是否高占比（说明本地请求抵达后，远程处理慢） - 远程库的
v$session中是否存在长时间未完成的会话，EVENT是否为db file sequential/scattered read或enq: TX（说明远程执行计划退化或锁冲突） - 网络层抓包确认是否存在重传、乱序或 ICMP 超时（尤其跨机房或云环境）
最容易被忽略的是：DB Link 使用的远程用户权限、同义词解析路径、NLS 设置差异，这些都可能触发隐式转换或全表扫描，最终表现为“DB Link 慢”，实则是远程 SQL 执行效率崩了。
