必须用 awrddrpt.sql 对比启用/禁用隐含参数前后的时段，因其强制快照对齐、容器一致、时段等长，并按“per txn”归一化，才能暴露如 mutex 等待翻倍、Logical Reads per Txn 推高 40% 等结构性变化。
直接用 awrddrpt.sql 对比启用/禁用隐含参数前后的两个时段，是发现其真实影响的唯一可靠方式；人眼翻两份 awrrpt.sql 报告几乎必然漏掉关键变化——因为隐含参数常只扰动“每事务”类指标或触发特定等待事件，而这些在未对齐归一化基准时根本不可见。
为什么必须用 awrddrpt.sql 而不是手动对比
隐含参数（如 _optimizer_adaptive_plans、_kgl_hot_block_search_limit）的影响往往是细微但结构性的：可能不改变总 DB Time，却让 library cache: mutex X 等待翻倍，或把 Logical Reads per Txn 推高 40%。手动对比两份 awrrpt.sql 极易踩坑：
- 快照边界错位：比如参数生效后你选了 snap_id 12350–12360，但基线误用了 12280–12290，中间跳过 69 个快照，
mutex等待的渐进式上升趋势被完全切断 - 并发漂移掩盖效果：若参数启用时段并发会话从 80 涨到 120，
Execs per Sec看似下降，实则是Execs per Txn暴增——awrddrpt.sql强制按 “per txn” 归一化，直接标出 +62% - ASH采样偏差：隐含参数引发的瞬时争用（如
enq: SQ - contention）持续仅 3–5 秒，若两份报告起止时间差 47 秒，该事件大概率被平均抹平，awrddrpt.sql对齐快照后能稳定捕获
运行 awrddrpt.sql 前必须验证的三个硬条件
隐含参数变更常伴随实例重启或 PDB 切换，稍不注意就对比了不同上下文的数据：
- 确认两个时段属于同一
dbid且同一容器：SELECT sys_context('userenv', 'con_name'), dbid FROM v$database；跨 PDB 必须先ALTER SESSION SET CONTAINER = pdb_name，否则默认查 CDB$ROOT，数据混杂 - 检查是否发生实例重启：
SELECT snap_id, startup_time FROM dba_hist_snapshot WHERE snap_id IN (start_snap, end_snap)；若startup_time不一致，整个对比失效 - 时段长度必须相等（如都是 1800 秒）；否则
DB Time per Sec、Physical Reads per Sec等指标因分母不同失真——隐含参数若影响 I/O 调度策略，这种失真会直接掩盖真相
重点盯哪些差异行才能抓到隐含参数痕迹
awrddrpt.sql 输出里真正暴露隐含参数作用的，往往不是最大数值变化，而是特定组合：
- 看带 ↑ 箭头的等待事件：
library cache: mutex X↑+Parse CPU to Parse Elapsed %↓组合，大概率指向_kgl_hot_block_search_limit调整引发的硬解析链雪崩 - 盯
SQL Statistics页中Buffer Gets per Txn和Executions per Txn的同步变化：若前者 +35%、后者 -12%，且 Top SQL 中出现大量recursive SQL，说明_optimizer_use_feedback导致计划反复演进 - 忽略
%Diff绝对值小的项（如CPU Usage Per Sec: +1.2%），但关注Row Cache Hit %: -4.8%这类基础命中率下降——它常是_row_cache_cool_down类参数调整的直接后果
隐含参数的影响从来不在表面数字里，而在指标间的逻辑关系断裂处；awrddrpt.sql 的 %Diff 和 ↑↓ 箭头，本质是帮你把这种断裂可视化——但前提是快照对齐、容器一致、时段等长，缺一不可。
