应重点分析AWR报告中Top 5 Timed Events和IO Profile的绝对值变化，确认SSD切换后db file sequential read、log file sync、db file scattered read三项等待事件的Waits与Time(s)是否显著下降，并核对快照时间是否准确覆盖变更窗口及业务高峰。
直接看 Top 5 Timed Events 和 IO Profile 部分的数值变化，而不是比“快了多少”——SSD替换后若仍出现高 db file sequential read 或 log file sync 等待，说明收益被其他瓶颈抵消了。
确认AWR报告时间范围是否对齐硬件变更点
SSD上线不是瞬间生效的，必须确保起始快照（begin_snap_id）在存储切换完成且数据库重启/缓存稳定之后，结束快照（end_snap_id）覆盖足够长的业务高峰时段（至少1小时以上）。常见错误是：用切换前10分钟和切换后5分钟生成报告，结果 DB Time 差异极小，误判无收益。
建议操作：
- 先查变更窗口：
SELECT * FROM dba_hist_snapshot WHERE begin_interval_time BETWEEN TIMESTAMP '2026-10-25 14:00:00' AND TIMESTAMP '2026-10-25 15:00:00';找到刚好跨过切换时刻的两个连续快照ID - 避免用刚切换后的第一个快照——此时
buffer cache还满是旧存储路径的脏块，可能引发大量free buffer waits - 对比时固定实例号（
l_inst_num），RAC环境尤其注意不要混入未切SSD的节点数据
重点盯住三类I/O等待事件的绝对值下降
SSD主要压缩随机I/O延迟，但AWR里不会直接写“SSD提升XX%”，得自己算差值。重点关注以下三项的 Waits 和 Time (s) 列：
-
db file sequential read：单块读（索引访问），SSD后平均延迟应从 8–15ms 降至 0.3–0.8ms；若下降不足50%，检查是否仍有大表全表扫描压着队列 -
log file sync：redo写入完成等待，直接受存储写延迟影响；从传统盘的 5–20ms 应压到 1ms 内；若仍 >3ms，可能是commit频率过高或未启用async commit -
db file scattered read：多块读（全表扫描），SSD对此提升有限（通常仅20–30%），若该值反升，说明SQL执行计划已转向更多全扫——这不是存储问题，是SQL或统计信息问题
用Load Profile验证真实负载转移
别只看“快”，要看“省了多少资源”。SSD替换后，CPU和内存压力应同步下降，否则说明瓶颈只是从I/O转移到了计算层。
- 对比两份报告的
DB CPU/s：若降幅 Physical reads/s 降了70%，大概率存在严重硬解析或低效SQL在抢CPU - 检查
Logical reads/s是否同步上升：SSD让应用敢发更多请求，逻辑读增20%属正常；但若翻倍，需查应用是否因响应变快而盲目增加并发 -
Redo generated/s若异常升高：可能是应用层开启更多事务日志（如审计开关被误开），和SSD无关
基线对比比单次报告更可靠
单次AWR容易受业务波动干扰。真正评估收益，必须用基线（BASELINE）锁定“换盘前典型工作负载”，再与换盘后同业务场景报告对比。
操作关键点：
- 创建基线时指定精确快照范围：
DBMS_WORKLOAD_REPOSITORY.CREATE_BASELINE(start_snap_id => 12345, end_snap_id => 12346, baseline_name => 'PRE_SSD_PEAK');，不能只用“最近1小时”这种模糊描述 - 生成对比报告用
@?/rdbms/admin/awrddrpt.sql脚本，它会自动对齐时间粒度，比手动挑两个快照更准 - 注意
Elapsed时间必须接近（误差
最常被忽略的是：SSD无法改善锁争用或闩锁（latch free）问题。如果换盘后 enq: TX - row lock contention 或 cache buffers chains 等等待上升，说明应用并发模型没适配新存储的低延迟特性，反而放大了竞争。
