需定位精确重启时间点，再选取前后稳定期且时长一致的AWR快照对比；重点分析Top 5 Timed Foreground Events中Avg Wait(ms)变化、新SQL上榜及Baseline启用状态，避免误判性能退化。
怎么看重启前后的AWR快照时间点是否匹配
oracle重启会重置内部时钟和部分统计计数器，但awr快照本身不会自动对齐“重启时刻”。直接比对两个任意快照（比如重启前1小时 vs 重启后1小时）容易误判——可能把业务低谷期和高峰期对比，得出“变慢”的假结论。
关键动作是定位准确的重启时间点，再选取前后各一段稳定运行期的快照：
- 用
SELECT STARTUP_TIME FROM V$INSTANCE;查出精确到秒的启动时间 - 在
DBA_HIST_SNAPSHOT中找该时间点前后最近的快照ID：SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT WHERE BEGIN_INTERVAL_TIME > TO_DATE('2024-06-15 14:22:33', 'YYYY-MM-DD HH24:MI:SS') ORDER BY BEGIN_INTERVAL_TIME FETCH FIRST 3 ROWS ONLY; - 确保对比的两组快照时长一致（例如都选30分钟窗口），且避开自动任务（如统计信息收集、备份）活跃时段
用AWR报告对比Top 5 Timed Foreground Events是否真有变化
很多人只看“Elapsed Time”总耗时增长就断定变慢，但真正影响用户体验的是前台会话等待。必须聚焦 Top 5 Timed Foreground Events 部分。
常见误导现象：重启后 log file sync 等待陡增，但实际是应用批量提交变多，而非数据库本身变慢；或者 db file sequential read 时间升高，实则是执行计划退化导致物理读暴增。
- 对比时重点看等待事件的“Avg Wait (ms)”列——如果数值翻倍以上，才说明I/O或锁响应真变差
- 注意
SQL ordered by Elapsed Time里是否有新SQL突然上榜，它可能是触发慢查询的源头（比如应用未绑定变量，重启后首次硬解析生成了差计划） - 若
DB CPU占比异常下降、而DB time上升，大概率是等待类问题，不是CPU瓶颈
为什么Shared Pool和Buffer Cache大小变化会导致重启后性能抖动
Oracle实例重启后，SGA_TARGET 或 MEMORY_TARGET 虽然配置没变，但内存实际分配受当前系统负载、大页（HugePages）可用性、甚至OS内存碎片影响，可能导致 shared_pool_size 或 db_cache_size 实际值低于预期。
这种差异不会报错，但会引发连锁反应：Shared Pool不足 → 游标频繁老化 → 硬解析增多 → CPU飙升；Buffer Cache偏小 → 物理读上升 → db file scattered read 等待堆积。
- 查重启后真实内存分配：
SELECT COMPONENT, CURRENT_SIZE/1024/1024 MB FROM V$MEMORY_DYNAMIC_COMPONENTS WHERE COMPONENT IN ('shared pool', 'DEFAULT buffer cache'); - 对比
V$SGASTAT中free memory项，若 shared pool 剩余长期低于 50MB，基本确认内存紧张 - 不建议盲目调大池大小——先确认是否因大量匿名PL/SQL或未使用绑定变量导致内存浪费
如何快速验证是不是SQL Plan Baseline或SPM失效引起的退化
重启后，如果之前靠SQL Plan Baseline强制走索引扫描的语句突然改走全表扫描，性能会断崖下跌。这不是AWR默认报告直接标红的问题，得主动查。
Baseline本身不随实例重启丢失，但启用状态、演化状态、或底层对象统计信息变更，都可能导致其“失效”——即优化器拒绝使用已批准的计划。
- 查某条慢SQL是否用了Baseline：
SELECT SQL_HANDLE, PLAN_NAME, ENABLED, ACCEPTED, FIXED FROM DBA_SQL_PLAN_BASELINES WHERE SQL_TEXT LIKE '%your_sql_pattern%'; - 确认当前执行计划是否匹配Baseline：
SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE('SQL_abc123', 'PLAN_456def'));再和V$SQL_PLAN对应SQL_ID的实际计划比对 - 若
ENABLED=NO或ACCEPTED=NO，需手动DBMS_SPM.ALTER_SQL_PLAN_BASELINE启用；若统计信息刚更新过，考虑锁定旧统计或重新evolve
重启本身不破坏Baseline，但它是暴露隐性配置问题的“压力测试”——很多性能倒退，根源不在重启这个动作，而在重启前就存在的参数漂移、统计陈旧或Plan控制松动。
