ash默认1秒采样且仅保留60分钟，微秒级故障瞬间大概率未被采到；虽12.1+版本sample_time精度达微秒，但采样本身不连续，需结合dbms_monitor.session_trace_enable获取真正微秒级trace数据交叉验证。
为什么直接查 v$active_session_history 很难捕到微秒级故障瞬间
ASH 数据默认每 1 秒采样一次，且只保留最近 60 分钟（受 memory_target 或 sga_target 影响），所谓“微秒级故障瞬间”——比如一条 SQL 执行耗时仅 800 微秒但引发连锁超时——在 ASH 中大概率根本没被采到。不是查询语句写得不对，而是数据压根不存在。
真正能逼近微秒精度的，是 DBA_HIST_ACTIVE_SESS_HISTORY 的快照粒度（默认 60 秒）也不行；必须启用并依赖 V$ASH_INFO 中声明的底层机制：Oracle 实际使用的是 ksusec（微秒级时间戳字段）和 ksusecwa（wait time in microseconds）等内部视图字段，但这些**不对外公开**。所以“提取微秒级 ASH 数据”的本质，是绕过采样限制，用其他方式补全时间细节。
- 确认你的 Oracle 版本 ≥ 12.1：只有这个版本起，
v$active_session_history的sample_time字段精度才提升到微秒（实际存储为TIMESTAMP(6)） - 检查是否启用了
STATISTICS_LEVEL = TYPICAL或ALL：设为BASIC会彻底禁用 ASH 采集 - 不要依赖
sample_time - INTERVAL '1' SECOND去“倒推”，ASH 不是连续流，相邻两行之间可能空缺几十毫秒甚至更久
用 sample_time 和 time_waited 定位亚秒级异常会话
虽然采样间隔是秒级，但只要采样命中了那个瞬间，sample_time 本身带微秒精度，而 time_waited（单位：厘秒，即 10 毫秒）虽不够细，但结合 session_state 和 event 可交叉验证是否处于异常等待中。关键是要把时间条件写准。
SELECT
sample_id,
TO_CHAR(sample_time, 'yyyy-mm-dd hh24:mi:ss.ff3') AS sample_time_ms,
session_id,
session_serial#,
sql_id,
event,
time_waited, -- 单位厘秒，注意不是微秒
blocking_session,
p1text, p1, p2text, p2, p3text, p3
FROM v$active_session_history
WHERE sample_time BETWEEN
TIMESTAMP '2024-05-20 14:23:15.123456'
AND TIMESTAMP '2024-05-20 14:23:15.999999'
AND session_state = 'WAITING'
AND event NOT IN ('SQL*Net message from client', 'rdbms ipc message');
-
TO_CHAR(..., 'ff3')只显示毫秒，但底层sample_time是TIMESTAMP(6)，可用ff6查看完整微秒 -
time_waited是该采样点记录的本次等待已持续时间，不是单次等待耗时；若值为 0，说明当时刚进入等待或处于 CPU 运行态 - 过滤掉网络类空闲事件，否则会淹没真实问题
用 DBMS_MONITOR.SESSION_TRACE_ENABLE 补微秒级执行链路
当怀疑某次调用在亚秒内出错（如 PL/SQL 调用失败、绑定变量突变、硬解析卡顿），ASH 太稀疏，必须上跟踪。这不是替代 ASH，而是与之配合：先用 ASH 锁定大致时间窗和会话，再回溯启用 trace。
- 对目标会话立即启用 10046 trace（含等待+绑定）：
EXEC DBMS_MONITOR.SESSION_TRACE_ENABLE(session_id => 123, serial_num => 4567, waits => TRUE, binds => TRUE); - trace 文件中
ela=字段单位是微秒（例如ela=123456表示 123456 微秒），可精确定位单条语句、单次 latch 获取、单次 log file sync 的耗时 - 注意 trace 文件路径由
user_dump_dest决定，且需提前设置max_dump_file_size = UNLIMITED，否则大负载下会截断 - 别用
ALTER SESSION SET EVENTS '10046 trace name context forever, level 12'—— 这种方式无法按会话动态开启，容易误伤
容易被忽略的关键点：ASH 的 sample_time 并非事件发生时间
sample_time 是采样动作完成的时间点，不是会话状态变化的时间。一个等待可能从 14:23:15.123456 开始，但直到 14:23:16.000123 才被采到——这时你看到的 sample_time 是后者，time_waited 却可能是 876543 微秒。如果不理解这点，会误判故障起始时刻。
更麻烦的是：如果等待在两次采样之间结束（比如只持续了 300 微秒），它就完全不会出现在 ASH 中。这种“幽灵等待”只能靠 trace 或 AWR 报告里的 SQL 统计（elapsed_time_delta / executions_delta）间接推测。
所以，真要抓微秒级故障瞬间，不能只盯着 ASH；得把 v$active_session_history 当作“线索索引”，把 trace 当作“高清录像”，两者时间戳对齐后交叉印证——这才是实际生产中唯一靠谱的做法。
