AWR快照未生成的直接证据是DBA_HIST_SNAPSHOT中对应snap_id完全缺失，常见原因包括MMON异常、SYSAUX空间不足、ORA-1688/ORA-12751静默失败、STATISTICS_LEVEL=BASIC导致ASH采样停摆、RAC单实例MMON挂起、DBID不匹配及基线锁定等。
AWR快照间隔数据丢失，不是“没采到”，而是快照根本没生成成功或被跳过。
DBA_HIST_SNAPSHOT里查不到对应快照ID
这是最直接的证据：执行SELECT snap_id, begin_interval_time, end_interval_time, status FROM dba_hist_snapshot ORDER BY snap_id DESC FETCH FIRST 20 ROWS ONLY;，发现时间轴上有明显空档（比如本该每30分钟一个快照，却连续缺了3个），且缺失区间内snap_id完全不存在。
- 常见原因包括：
MMON进程异常退出或卡死在x$kqlfbc扫描上（尤其Oracle 11g绑定变量泛滥时） -
SYSAUX空间不足导致分区扩展失败，WRH$_ACTIVE_SESSION_HISTORY等表无法写入新分区 - 快照生成过程中遭遇
ORA-1688（无法扩展表空间段）或ORA-12751（CPU time violation），但错误被静默吞掉，只留下status = 2（失败）或干脆不写记录
快照存在但ASH数据为空或严重稀疏
查到snap_id存在、status = 0，但生成的AWR报告中“Top SQL”、“Active Session History”部分数据量远低于预期（比如某小时仅几百行ASH，而正常应有数万），说明快照虽生成，但核心采样数据没落库。
- 典型诱因是
ASH采样被禁用：SELECT * FROM v$parameter WHERE name = 'statistics_level';返回BASIC——此时WRH$_ACTIVE_SESSION_HISTORY不会写入任何行 - 或
_ash_sampling_interval被调得过大（如设为30000毫秒），导致每30秒才采1次，漏掉大量短事务 - RAC环境中某实例的
MMON挂了，但其他实例还在跑，造成跨实例数据不完整，报告里只显示部分节点活动
DBID不匹配导致快照“不可见”
你在目标库执行@?/rdbms/admin/awrrpt.sql时，报告生成界面让你输DBID，若填错（比如把INSTANCE_NUMBER当DBID），会导致脚本去查另一个数据库的DBA_HIST_*视图，自然找不到本库的快照。
- 正确获取方式只有：
SELECT dbid FROM v$database;，不是v$instance或dba_hist_wr_control - 跨库导入的AWR快照会带源库
DBID，它和当前库DBID不同，因此即使物理数据在SYSAUX里，也不会出现在默认查询路径中 - 检查是否混入外部快照：
SELECT DISTINCT dbid FROM dba_hist_wr_control;，若返回多行，说明有导入数据，需明确指定DBID再查
基线锁定让快照“被隐藏”而非丢失
快照真实存在、DBID也对，但awrrpt.sql生成报告时提示“no data found”，或dba_hist_snapshot里对应时段快照status字段为空——这往往是基线（BASELINE）在作祟。
- Oracle 11g起，
STATIC基线会强制保留其覆盖范围内的所有快照，哪怕已超retention设置；查询dba_hist_baseline_details可确认 - 更隐蔽的是
MOVING_WINDOW基线：它默认绑定最近8天数据，若你刚把retention从8天改成30天，窗口不会自动扩大，旧快照仍被钉住，新快照却因空间不足无法生成 - 基线本身不删除快照，但它让
drop_snapshot_range失效——删完后dba_segments显示空间未释放，就是这个原因
真正难排查的不是“哪里丢了”，而是“为什么丢得悄无声息”：MMON不报错、DBA_HIST_SNAPSHOT没记录、ALERT.LOG里只有一行模糊的Errors in file ... mmon_*.trc。盯住v$bgprocess里的MMON状态、SYSAUX剩余空间、以及dba_hist_baseline_details这三处，比翻报告本身更有效。
