19c awr报告原生集成addm建议和ash摘要，支持pdb级指标展开及带时区时间戳，快照清理具备自适应机制；11g需分别执行多个脚本，无pdb概念且时间戳无时区信息。
Oracle 11g 和 19c 的 AWR 报告底层数据结构和快照机制基本一致，但报告内容的整合度、默认行为、诊断深度和可操作性存在实质性差异——不是“有没有”，而是“能不能一眼看到关键线索”。
AWR报告是否自动包含ADDM和ASH分析
11g 的 awrrpt.sql 默认只输出纯 AWR 数据（如 Load Profile、Top SQL、等待事件），ADDM 分析需单独运行 addmrpt.sql，ASH 细节则要查 v$active_session_history 或手动跑 ashrpt.sql。三者是割裂的，DBA 必须自己拼图。
19c 的标准 AWR 报告（HTML/TEXT）已原生嵌入 ADDM 建议和 ASH 摘要。比如在 “Automatic Database Diagnostic Monitor” 章节下，你会直接看到类似 “SQL ID 7yv2z6qk8x9b1 is consuming excessive CPU due to missing index on COL3” 的结论；ASH 相关统计（如会话分布热力图、Top Blocking Sessions）也集成在 “Active Session History” 小节里。
- 11g：必须分别执行
@?/rdbms/admin/awrrpt.sql、@?/rdbms/admin/addmrpt.sql、@?/rdbms/admin/ashrpt.sql - 19c：单次
@?/rdbms/admin/awrrpt.sql即覆盖全部，无需额外脚本 - 注意：19c 的 ASH 集成仅限摘要（如 Top Events by Wait Class），原始采样行仍需查视图；若需完整 ASH 时间线，仍得用
ashrpt.sql
快照保留策略与MMON行为差异
11g 默认快照保留 8 天，由 MMON 进程每小时采集一次，且清理逻辑较简单：过期快照被整批删除，不区分表空间压力。
19c 仍默认 8 天，但 MMON 增加了自适应清理机制：当 SYSAUX 表空间使用率超过 85% 时，会主动缩短快照间隔（如从 1 小时改为 2 小时）并提前清理旧快照，避免因空间不足导致 AWR 停摆。这在高负载系统中很关键——你不会突然发现 dba_hist_snapshot 里断层了。
- 检查当前保留策略：
SELECT retention FROM dba_hist_wr_control; - 19c 可动态修改：
EXEC dbms_workload_repository.modify_snapshot_settings(retention => 10080);（单位为分钟） - 11g 修改后需重启数据库才能生效；19c 实时生效，且会校验 SYSAUX 空间余量再决定是否接受该值
HTML报告中PDB级指标是否可直接展开
11g 无 PDB 概念，AWR 报告天然面向 CDB 实例，所有指标都是实例级汇总。即使你强行在 11g 上跑多租户（不可能），报告也无法识别容器边界。
19c 支持在生成 AWR 报告时指定 PDB 名称，HTML 报告会自动呈现该 PDB 的专属指标：包括 PDB 级别 Top SQL、PDB 内部等待事件占比、PDB 的 Buffer Gets/Executions 趋势图。更重要的是，“Instance Efficiency Percentages” 小节会按 PDB 分列，比如某个 PDB 的 Library Hit % 是 62%，而另一个是 99%，问题立刻定位到具体租户。
- 生成 PDB 级报告命令：
@?/rdbms/admin/awrrpt.sql→ 选 “PDB” → 输入 PDB 名称 - 19c 报告顶部明确标注 “Report for PDB: SALESPDB”，11g 报告只会写 “Report for Database DB11G”
- 若在 19c 中漏选 PDB，报告仍是 CDB 全局视图，不会报错也不会提示缺失上下文
真正容易被忽略的是：19c 的 AWR 报告里所有时间戳都带时区信息（如 07-JUL-26 14:30:00.000000 +08:00），而 11g 是纯本地时间。跨时区运维时，拿 11g 报告对齐应用日志可能差一两个小时——这个细节不看报告头部几乎意识不到。
