ASH数据“不足”需先确认statistics_level为TYPICAL,再排查_ash_size不足、采样时间范围不准或应转向dba_hist_active_sess_history查历史数据。
ASH数据“不足”不是丢了,而是被覆盖或根本没采到——得先分清是内存挤兑、采样失效,还是查询姿势错了。
这是最常被忽略的硬开关。如果设成 ALL 或 BASIC,v$active_session_history 会彻底停摆,连一行都不会有。
SELECT name, value FROM v$parameter WHERE name = 'statistics_level'; —— 必须返回 TYPICAL
ALTER SYSTEM SET statistics_level = typical SCOPE = BOTH;,无需重启默认 4MB 内存缓冲区,在高并发下撑不过 10–15 分钟。查 MIN(sample_time) 和 MAX(sample_time) 发现只差几分钟,基本就是 buffer 溢出了。
ALTER SYSTEM SET "_ash_size" = 524288000 SCOPE = SPFILE;(500MB 示例)sga_max_size,否则下次启动失败SCOPE=BOTH 热生效ASH 采样不是均匀滴答,平均约 1 秒一次,但实际间隔浮动很大。用模糊时间范围容易跨过整个采样窗口,直接查不到。
SAMPLE_TIME BETWEEN TIMESTAMP '2026-07-21 19:30:00' AND TIMESTAMP '2026-07-21 19:31:00'
dba_hist_active_sess_history 定位大致区间(它每 10 秒存一次,更稳定)v$active_session_history 是内存视图,天然易失;而 dba_hist_active_sess_history 是磁盘持久化数据,只要 AWR 正常采集,就可能保留数天甚至数周。
SELECT COUNT(*) FROM dba_hist_snapshot WHERE end_interval_time > SYSDATE - 1;
SELECT * FROM dba_hist_active_sess_history WHERE sample_time BETWEEN ...
awr_pdb_active_sess_history 里还留着线索真正难搞的不是调参数,而是区分“没采到”和“采了但被覆盖”。前者得看 statistics_level 和 MMNL 进程是否活着,后者才是调 _ash_size 的事。很多人一上来就加内存,结果发现压根没开采样功能。