Oracle 19c AWR报告实现AWR、ADDM与ASH三合一集成，ADDM建议嵌入各章节，ASH数据用于交叉验证根因，大幅提升诊断闭环效率。
awr本身不自动调优，但19c的addm+ash整合让“诊断→定位→验证”闭环变短了——关键不是等报告生成，而是选对快照、看懂嵌入式addm建议、用ash数据交叉验证。
怎么选AWR报告的时间段才不会漏掉问题根因
选错时间段，再好的ADDM分析也白搭。常见错误是直接用用户说的“14:15卡顿”去截取14:15-15:15这个快照，结果发现报告里负载平平、等待事件也不突出。
- 必须向前延展：起始时间至少提前15–30分钟（比如问题发生在14:15，起始选13:45），因为很多瓶颈是缓慢积累的（如共享池碎片、游标泄漏）
- 必须向后延展：结束时间至少延后15分钟，避免把“问题爆发后的连锁反应”（如大量会话阻塞、队列堆积）切在报告外
- 避开实例重启点：用
SELECT snap_id, startup_time FROM dba_hist_snapshot ORDER BY snap_id DESC检查相邻快照的startup_time是否一致；若不一致，说明中间发生过重启，该区间不能用于连续性分析 - 测试期可临时调密快照：用
EXEC DBMS_WORKLOAD_REPOSITORY.MODIFY_SNAPSHOT_SETTINGS(interval => 15)把间隔从60分钟改为15分钟（注意保留期别缩太短，否则快照被自动清理）
怎么看懂19c AWR报告里嵌入的ADDM建议
19c的ADDM不是附在最后的独立章节，而是分散在各模块中——比如“Top 5 Timed Events”旁直接带一个“ADDM Findings”折叠块，点开才是具体建议。很多人只扫TOP SQL列表，却忽略旁边那个小箭头。
- ADDM建议里的
Impact值不是百分比，而是“如果采纳，预计能减少多少数据库时间（DB Time）”，单位是分钟；值为0.8表示可节省约0.8分钟DB Time，不是“提升80%性能” - 看到“Consider increasing
shared_pool_size”这类建议时，别急着改参数：先去报告的“Memory Statistics”页查Shared Pool Free %是否长期低于10%，再结合v$sgastat确认是否有free memory严重不足 - ADDM有时会建议“使用SQL Profile”，但没告诉你目标SQL的
sql_id在哪——得回到“SQL Statistics”页，按Executions或Elapsed Time排序，找到对应SQL后点进详情，才能拿到sql_id和plan_hash_value
为什么ASH数据必须和AWR报告一起看
AWR快照是每小时一次的“照片”，ASH是每秒一张的“视频”。单看AWR，你只知道“这小时IO很高”，但不知道是哪条SQL、哪个PDB、哪个会话在拖慢整个系统。
- 报告里“Top Segments by Logical Reads”下方常有“See ASH data for top sessions”的链接，点击后跳转的不是新页面，而是同一HTML报告内嵌的ASH摘要表格——注意看
SQL_ID、SESSION_ID、PDB_NAME三列，它们能直接定位到租户级问题 - 当ADDM指出“latch free”是主要瓶颈，别只查
v$latch；立刻翻到ASH部分，筛选EVENT = 'latch: shared pool'，看SQL_ID是否集中在某条硬解析频繁的语句上 - 多租户环境下，
PDB_NAME为空的ASH记录属于CDB$ROOT，而带具体PDB名的才代表租户真实负载——混淆这两者会导致误判为“全局问题”，实则只是某个PDB失控
真正卡住人的从来不是ADDM有没有建议，而是建议里提到的sql_id在报告里藏得太深，或者ASH采样中PDB_NAME列默认被折叠看不到。这些细节不手动展开核对，再智能的自动诊断也落不了地。
