如何阅读AWR报告的Init.ora Parameters_关键隐藏参数与非默认参数对性能的影响

AWR报告Init.ora Parameters仅显示非默认值及有性能影响的关键参数，每项均需审慎核查；重点关注sga_target、pga_aggregate_target、optimizer_mode等，忽略db_name等标识类参数，警惕隐藏参数与_adaptive_plans等对统计的干扰。

怎么看 AWR 报告里的 Init.ora Parameters 部分

awr 报告末尾的 init.ora parameters 不是罗列所有参数，它只显示「非默认值 + 有性能影响的关键参数」。oracle 自动过滤掉没改过的、或公认安全的默认项。所以你看到的每一条，基本都值得多看一眼——不是“配置了”，而是“可能动过手脚，且 oracle 认为它值得被记录”。

实操建议：

• 重点扫视 sga_target、pga_aggregate_target、optimizer_mode、cursor_sharing、_optim_peek_user_binds 这类参数，它们直接挂钩执行计划稳定性与内存分配行为
• 忽略 db_name、control_files 这类纯标识/路径类参数，除非你怀疑控制文件路径异常导致归档卡住
• 注意带下划线的隐藏参数（如 _serial_direct_read），它们出现在这里，往往意味着 dba 主动启用或禁用过，必须查变更记录

_optimizer_adaptive_plans 开关对 AWR 中 sql 统计的干扰

这个参数开启后，Oracle 可能在运行时动态切分执行计划（比如把 Nested Loop 改成 Hash Join）。AWR 报告里看到的 SQL 执行统计（如 buffer_gets、elapsed_time）会混入多种计划路径的叠加结果，单条 SQL 的“平均”耗时失去可比性。

常见错误现象：

• 同一 SQL 在不同快照中 executions 暴涨，但 elapsed_time / execution 波动极大，查不到明显瓶颈
• SQL Detail 页面里 Plan Hash Value 频繁变化，但 V$SQL_PLAN 查不到对应历史计划

实操建议：

• 确认当前是否开启：select value FROM v$parameter WHERE name = '_optimizer_adaptive_plans';
• 若需稳定对比 SQL 性能，临时关闭它（需重启实例），或在 AWR 报告生成时加 awr_report_html 的 show_plan 选项，强制抓取每个快照的实际执行计划
• 别只盯 elapsed_time，配合 iowait 和 cpu_time 看占比——自适应计划常在 I/O 压力大时触发，CPU 占比会突然下降

为什么 optimizer_dynamic_sampling 设成 11 会让 AWR 里某些 SQL 的解析时间飙升

设成 11 意味着对所有未分析表、无直方图列、甚至临时表，都强制做深度动态采样（Level 11 = 全表扫描采样）。这在 AWR 报告的 Shared Pool Activity 部分体现为 parse time elapsed 异常高，尤其在批量作业启动期。

使用场景：

• OLAP 查询大量用到未 ANALYZE 的分区表，且统计信息严重滞后
• etl 脚本反复创建 GTT（全局临时表），又没手工收集统计信息

实操建议：

• 优先用 DBMS_STATS.GATHER_TABLE_STATS 补统计信息，而不是靠采样扛；动态采样是兜底，不是主力
• 若必须用，降级到 Level 4（对未分析表采样）或 Level 6（加直方图），避免 Level 11 的全表扫描开销
• 检查 AWR 中 sql_id 对应的 child_number 是否暴涨——每个采样结果可能生成新子游标，加剧 Shared Pool Latch 争用

AWR 里看不到 memory_target？它被自动转成 sga_target + pga_aggregate_target 了

当数据库用 memory_target 启动时，Oracle 内部会把它拆解为 SGA 和 PGA 的初始目标值，并在 AWR 的 Init.ora Parameters 部分只显示拆解后的两个参数。你不会看到 memory_target 本身，除非它被显式设为 0 或 unset。

性能影响：

• 如果 sga_target 和 pga_aggregate_target 之和远小于原 memory_target，说明 Oracle 在运行中回收了部分内存，可能触发频繁的内存重平衡（memory manager wait Event 上升）
• AWR 中 PGA Memory Advisory 的建议值可能失效，因为它只参考 pga_aggregate_target，不感知总 memory_target 的弹性空间

实操建议：

• 查真实内存策略：运行 SELECT component, current_size FROM v$memory_dynamic_components;，比看 AWR 参数更准
• 若发现 current_size 频繁抖动，且 memory_resize_ops 视图里操作密集，说明 workload 波动大，memory_target 反而不如固定 sga_target+pga_aggregate_target 稳定
• 别依赖 AWR 里这两个参数的值去估算总内存——它们只是起点，不是上限

真正难判断的，是哪些参数改动属于“被动响应问题”，哪些是“主动埋下隐患”。AWR 不告诉你上下文，只甩出结果。得对照 alert.log 时间戳、DBA_HIST_PARAMETER 历史快照，再翻运维记录，才能分清哪次调参救了火，哪次调参点了炸药包。