v$active_session_history数据被主动覆盖而非丢失，因其采用4mb环形内存缓冲区设计；采样间隔约1秒但非实时，短于500ms事件易遗漏；需检查statistics_level是否为typical并调大_ash_size及sga_max_size。
v$active_session_history 里的数据不是“丢失”，而是被主动覆盖了——这是设计行为，不是故障。
ASH 内存缓冲区是固定大小的环形队列
Oracle 把 ASH 数据存在 SGA 里一块叫 ASH buffers 的固定内存区域，默认大小是 4194304 字节（即 4MB）。它不是日志式追加写，而是类似循环队列：新采样进来，最老的样本自动被挤掉。
- 高并发下，4MB 往往撑不过 10–15 分钟；查
SELECT MIN(sample_time), MAX(sample_time) FROM v$active_session_history，时间跨度远小于 60 分钟，基本就是 buffer 不够用了 -
_ash_size参数控制容量，但修改后必须重启实例：ALTER SYSTEM SET "_ash_size"=524288000 SCOPE=SPFILE（设为 500MB） - 别忘了同步调大
sga_max_size，否则下次启动会失败
采样本身就有天然盲区
ASH 每秒采样一次，靠 MMNL 进程从 v$session 抓快照，但这“每秒”只是统计平均值，不是硬实时。
- 持续不到 500ms 的卡顿，很可能落在两次采样间隙，根本不会出现在
v$active_session_history中 - 空闲会话、SQL 解析未完成阶段、极短事务（
- AWR 快照生成前后，
MMNL可能忙于刷盘，采样频率临时下降
查不到数据 ≠ 没发生过
如果 v$active_session_history 返回空或时间跨度极短，第一反应不该是“ASH 坏了”，而应切换视角：
- 用
dba_hist_active_sess_history查历史快照——前提是 AWR 正常采集且保留策略允许 - 不要写
SAMPLE_TIME > SYSDATE - 1/1440这种模糊条件查“最近 1 分钟”，SYSDATE是查询时刻时间，容易跨采样周期漏数据；应手动指定精确时间范围，比如BETWEEN TIMESTAMP '2026-06-22 17:30:00' AND TIMESTAMP '2026-06-22 17:31:00' - 某些场景（如凌晨低峰期突发抖动），
v$active_session_history早被覆盖，但awr_pdb_active_sess_history或dba_hist_snapshot里可能还留有线索
升级或配置变更后 ASH 完全为空
曾有案例：11g 升级到 19c 后 v$active_session_history 始终返回 0 行，dba_hist_active_sess_history 停在 99 条不动。这不是内存不够，而是 ASH 功能被意外关闭：
- 检查参数
statistics_level是否为ALL或BASIC—— 若是，ASH 会被彻底禁用；必须设为TYPICAL（默认值） -
alter system set statistics_level=typical scope=both;立即生效，无需重启 - 确认
MMNL进程是否正常运行：ps -ef | grep mmnl，RAC 环境下每个节点都要查
真正难定位的问题，往往要交叉比对：v$active_session_history 的实时粒度 + dba_hist_active_sess_history 的快照时间点 + 应用日志里的超时戳 + 当前 gv$session 状态。单靠一个视图下结论，很容易误判。
