addmrpt.sql无法定位根因，仅输出孤立建议；其适用场景限于已确认性能退化后复核ADDM判断或导出文本供非DBA审阅，且不支持PDB级分析与ASH联动。
直接执行 addmrpt.sql 无法定位根因，它只输出孤立建议
很多人以为运行 addmrpt.sql 就能拿到“根因结论”，结果打开报告发现全是泛泛而谈的“consider increasing shared_pool_size”或“sql may benefit from an index”。这不是addm不准，而是你绕过了它真正的上下文——awr快照的对比逻辑和ash的会话证据。单独跑 addmrpt.sql 生成的是纯addm分析报告，不带任何awr原始数据支撑，也没有ash采样点交叉验证，等于让医生只看化验单结论、不看血常规数值和心电图波形。
addmrpt.sql 的适用场景非常有限
它只在两类情况有用：
- 你已经通过AWR报告确认了某段区间存在严重性能退化（比如DB Time突增300%），且想快速复核ADDM是否给出过相同判断
- 你需要把ADDM建议导出为独立文本供非DBA同事审阅（比如给开发看“这条SQL被标记为高负载”）
但注意：addmrpt.sql 不支持PDB级分析，也不显示ASH会话堆栈；如果问题发生在某个特定PDB，必须用 awrrpt.sql 并在交互中选择该PDB，才能触发嵌入式ADDM+ASH联动分析。
为什么嵌入式ADDM比独立 addmrpt.sql 更可靠
Oracle 19c的真正能力藏在 awrrpt.sql 生成的HTML报告里：
- ADDM建议直接挂在“Top 5 Timed Events”旁，点开就能看到对应ASH采样中哪些会话、哪个SQL_ID、在哪个PDB里持续占用CPU或产生大量I/O
- Impact值（如
0.8）是基于该快照区间内实际DB Time计算出的分钟数，不是估算比例；而addmrpt.sql里的Impact缺少时间基准，容易误读 - 当ADDM说“存在游标共享问题”，HTML报告里会同步链接到“SQL Statistics → Parse Calls vs Executions”表格，你能立刻验证是否存在硬解析飙升
换句话说，addmrpt.sql 是ADDM的“摘要页”，而 awrrpt.sql 报告才是带源数据、可钻取、能回溯的“病历本”。
执行 addmrpt.sql 前必须确认三件事
否则生成的报告基本无用：
- 当前数据库未发生实例重启：运行
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (:begin_snap, :end_snap)，确保两个快照的startup_time一致 - 目标时间段内ASH采样完整：检查
SELECT COUNT(*) FROM dba_hist_active_sess_history WHERE sample_time BETWEEN :begin_time AND :end_time，结果应远大于0（通常每秒至少1条） - 没有启用
_optimizer_adaptive_plans=FALSE等禁用ADDM核心规则的隐含参数——这类参数会让ADDM跳过关键路径分析
最常被忽略的一点：ADDM的根因判断高度依赖快照起止时间的选择精度。哪怕只差一个快照ID，就可能错过连锁阻塞的起点。别省那两分钟，手动查 dba_hist_snapshot 确认时间边界，比依赖脚本自动推荐更稳妥。
