init.ora parameters显示的是oracle标记的可疑性能相关参数变更，需立即核查变更记录；重点关注sga_target、pga_aggregate_target、optimizer_mode、cursor_sharing及带下划线的隐藏参数。
awr报告里的init.ora parameters部分不是配置清单，而是oracle主动标记的“可疑修改点”——只要它出现在这里，基本意味着参数被改过，且oracle认为这次修改可能影响性能。
Init.ora Parameters里哪些参数必须立刻查变更记录
这部分只显示非默认值 + 有性能影响的关键参数，每一条都值得人工复核。重点关注以下几类：
-
sga_target和pga_aggregate_target：内存分配策略变更会直接导致硬解析增多、大表扫描变慢、临时段争用等，但不会在Top Events里报出来 -
optimizer_mode（如从ALL_ROWS改成FIRST_ROWS_10）：执行计划倾向突变，可能让原本走索引的SQL退化为全表扫描 -
cursor_sharing（尤其是设为FORCE）：看似缓解硬解析，实则引发绑定变量窥探失效、直方图失效、执行计划泛滥 - 带下划线的隐藏参数，例如
_optim_peek_user_binds、_serial_direct_read、_optimizer_adaptive_plans：它们出现在这里，99%是DBA手动调整过，必须查dba_audit_trail或变更日志确认时间点和原因
_optimizer_adaptive_plans开启后AWR里SQL统计失真
这个参数会让Oracle在运行时动态切换执行计划（比如Nested Loop → Hash Join），而AWR里SQL统计（elapsed_time、buffer_gets）是多个计划路径的混合结果，单条SQL的“平均耗时”失去可比性。
常见错误现象：
- 同一
sql_id在不同快照中executions暴涨，但elapsed_time / execution波动极大，且查不到明显瓶颈 - SQL Detail页面里
Plan Hash Value频繁变化，但v$sql_plan查不到对应历史计划
实操建议：
- 确认当前状态：
SELECT value FROM v$parameter WHERE name = '_optimizer_adaptive_plans'; - 若需稳定对比SQL性能，临时关闭它（需重启实例），或生成AWR报告时加
show_plan选项强制抓取每个快照的实际执行计划 - 别只盯
elapsed_time，配合iowait和cpu_time看占比——自适应计划常在I/O压力大时触发，cpu_time占比会突然下降
optimizer_dynamic_sampling=11 是解析时间飙升的隐形推手
设成11意味着对所有未分析表、无直方图列、甚至全局临时表，都强制做Level 11动态采样（即全表扫描采样）。这在AWR里表现为parse time elapsed飙升、DB CPU等待事件冲高，但Top SQL里找不到对应慢SQL。
使用场景与风险：
- 常被误用于“快速修复执行计划不准”，但代价是每次硬解析都要扫一遍大表
- 在批量作业前临时启用，但忘记还原，导致后续OLTP请求也受牵连
- 与
cursor_sharing=FORCE叠加时，采样行为会重复触发，CPU消耗呈指数级增长
排查方法：
- 在AWR报告“SQL Statistics”页找
SQL ordered by Parse Calls，看是否某几个SQL的Parse Calls远高于Executions - 查
v$sql中对应SQL的is_bind_sensitive和is_shareable是否为NO，结合child_number数量暴增判断
真正难识别的不是参数改了，而是改完之后没有立刻出问题——它可能潜伏在共享池老化周期后、统计信息刷新后、或并发量突破阈值时才爆发。所以每次看到Init.ora Parameters里有新增项，第一反应不该是“哦，有人调过”，而是“这个改动和最近哪次性能波动的时间点吻合？”
