ADDM报告为空的三大主因：一是STATISTICS_LEVEL非TYPICAL/ALL导致关键统计缺失；二是指定快照区间DB Time＜5秒，ADDM主动跳过分析；三是DBA_HIST_*视图（如ASH）数据不完整，使ADDM无法构建资源链路。

ADDM报告为空或无建议，根本不是AWR报告“没生成”

这里有个常见的误解需要先澄清：ADDM和AWR报告，其实是两个独立产物。AWR报告是快照对比的统计汇总，而ADDM报告则是基于同一组快照、调用dbms_addm分析引擎生成的根因诊断。所以，即便AWR报告能正常输出，ADDM那一栏仍可能完全空白——这恰恰说明问题不在报告生成流程本身，而在于ADDM的输入数据或者运行前提压根就没满足。

STATISTICS_LEVEL不是TYPICAL，ADDM直接静默失效

ADDM的诊断能力，强制依赖于数据库级别的统计采集。如果STATISTICS_LEVEL这个参数被设成了BASIC，那么AWR快照中那些关键维度——比如SQL执行计划、等待事件的细分、内存结构的争用情况——就会全部缺失。巧妇难为无米之炊，ADDM失去了分析依据，甚至连“找不到瓶颈”都懒得报，直接就返回一个空结果给你。

• 检查命令：SHOW PARAMETER statistics_level，确认结果必须是TYPICAL或ALL。
• 临时修正：执行ALTER SYSTEM SET statistics_level = TYPICAL SCOPE=BOTH;（注意，对于需要重启后生效的参数要谨慎操作）。
• 重要提醒：修改参数后，并不会自动补全历史快照的数据，这个改动只对后续生成的新快照生效。

快照区间内DB Time过低，ADDM判定“无需分析”

ADDM有个默认的“脾气”：它只对数据库时间（DB Time）大于等于5秒的时段，才会触发深度分析。如果你指定的begin_snap到end_snap之间，数据库几乎处于空闲状态（比如测试库的夜间维护窗口），那么即使快照存在、参数也正确，ADDM也会主动跳过，不生成任何FINDING。这不是它“没运行”，而是它判定“这点工作量，不值得分析”。

• 验证方法：先查询指定区间的DB Time总量：SELECT dbid, snap_id, db_time FROM dba_hist_sysmetric_summary WHERE snap_id BETWEEN :beg AND :end ORDER BY snap_id;
• 如果db_time这一列多数为0或只是个位数，那ADDM必然没有输出。
• 对策：更换一个业务高峰期的快照范围进行分析，或者手动创建一些负载后再打快照。

DBA_HIST_*视图数据不完整，ADDM读不到关键链路

ADDM的分析深度远超想象，它不止查询DBA_HIST_SNAPSHOT，还重度依赖一系列历史视图，比如DBA_HIST_ACTIVE_SESS_HISTORY（ASH采样）、DBA_HIST_SEG_STAT（段级I/O）、DBA_HIST_SYS_TIME_MODEL（时间模型）。只要其中任何一个视图，在目标快照范围内的数据为空或被截断，ADDM就无法拼凑出完整的资源消耗路径，最终也只能输出一个“no findings”。

• 快速排查：执行SELECT COUNT(*) FROM dba_hist_active_sess_history WHERE snap_id BETWEEN :beg AND :end; 如果结果为0，则说明ASH数据丢失了。
• 常见原因：SYSAUX表空间满了，导致底层的WRH$_表写入失败；或者_ASH_DISK_FILTER_RATIO参数被调得过高，丢弃了大量内存中的采样数据。
• 核心要点：不要只看dba_hist_snapshot有没有记录——那只是AWR的“外壳”，ADDM要的是里面的“数据血肉”。

说到底，当ADDM建议缺失时，最容易被忽略的一点是它对“有效工作量”的苛刻定义：既要求数据存在，又要求数据够多、够细、够准。哪怕只是ASH采样率掉了一半，或者某张WRH$_表因为空间不足被清空了最近三天的记录，ADDM都会选择沉默，而不是给你一个明确的错误提示。这才是问题的关键所在。