ASH数据不直接写磁盘，因其本质是内存环形缓冲区，仅保留约1小时秒级样本，重启即丢、满即覆；设计目标为低开销实时捕获，全量落盘会拖垮SGA和I/O。
ASH数据为什么不是直接写磁盘，而是靠AWR“采样”落盘
因为ash本质是内存环形缓冲区（v$active_session_history），只保留约1小时活跃会话的秒级样本，重启即丢、满即覆。它设计目标就是低开销实时捕获，不是长期归档——直接全量写磁盘会拖垮sga和i/o，尤其高并发实例。
AWR不“同步复制”ASH，而是按策略抽样：默认每小时从内存ASH中抽取一部分记录（Oracle文档称约10%），用direct-path insert批量写入WRH$_ACTIVE_SESSION_HISTORY分区表。这个过程由MMNL进程触发，与MMON快照采集解耦，避免争抢资源。
- 抽样不是随机的：优先保留
session_state = 'ON CPU'或高等待事件频次的样本 - 写入的是“已解析状态”：SQL文本不落盘，只存
sql_id；等待事件字段已标准化（如enq: TX - row lock contention） - 落盘后数据归属AWR生命周期：受
dbms_workload_repository.modify_snapshot_settings控制，默认保留7天
为什么不能跳过AWR，自己定期导出v$active_session_history
你可以用CREATE TABLE AS SELECT把v$active_session_history导成普通表，但实际意义有限：
- 导出期间ASH内存持续被覆盖，导出结果大概率不连续、缺片段
- 导出动作本身会引入额外CPU和I/O压力，可能干扰正在发生的性能问题
- 缺失时间对齐：
v$active_session_history.sample_time精度是毫秒级，但不同会话采样时刻有微小偏移，手工导出无法保证与AWR快照时间轴一致 - 没有元数据绑定：导出表不带
snap_id、不参与dba_hist_active_sess_history的分区清理逻辑，后续空间管理全靠人工
AWR里看到的ASH数据，和实时查v$active_session_history对不上
这是正常现象，根本原因在于两套数据来源和时效性完全不同：
-
v$active_session_history是当前内存中的“活数据”，sample_time最新可达几秒前 -
dba_hist_active_sess_history是历史快照，最早也得等上一个整点快照生成后才入库（默认每小时一次），且仅含抽样后的子集 - 若刚发生尖刺（比如2分钟前CPU飙到95%），
v$active_session_history能立刻查到，但dba_hist_active_sess_history要等到下一个快照点（可能还要等10–50分钟）才出现相关记录 - 注意
dba_hist_active_sess_history里的sample_time是“采样发生时间”，不是“落盘时间”；而v$active_session_history里的同名字段是真实采集时刻
想让关键ASH数据更多进AWR，能调什么参数
不能直接增大“ASH进AWR的比例”，但可通过调整底层机制间接影响：
- 增大ASH内存分配：
ALTER SYSTEM SET "_ash_size"=536870912 SCOPE=SPFILE（单位字节，示例设为512MB），重启生效。更大的缓冲区意味着更长的内存驻留时间，MMNL有更多机会从中抽样 - 缩短AWR快照间隔：
EXEC dbms_workload_repository.modify_snapshot_settings(interval => 15)（单位分钟），让MMNL更频繁地触发采样，提高关键时段覆盖概率 - 禁用ASH采样过滤（慎用）：
ALTER SYSTEM SET "_ash_sample_all"=TRUE，强制MMNL抽取全部ASH样本而非10%，但会显著增加SYSAUX空间占用和写入延迟 - 以上隐含参数需DBA权限，且修改后必须验证
v$sgastat中ASH buffers实际增长量，避免SGA其他组件被挤压
真正容易被忽略的是：AWR里的ASH数据永远只是“快照切片”，不是录像回放。诊断秒级突变必须依赖内存视图，指望dba_hist_active_sess_history查刚发生的锁等待，基本等于翻一小时前的监控截图找现在的故障。
