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 managerwait 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 历史快照，再翻运维记录，才能分清哪次调参救了火，哪次调参点了炸药包。
