load profile异常偏高需结合业务基线、实例配置和时间窗口综合判断；logical reads高未必缓存差，buffer hit%>99%说明问题在“读得多”而非“读得慢”；db time远高于db cpu表明等待为主，应查top 5 timed events定位资源争用。
Load Profile 异常偏高不是单一指标的问题，而是多个关键指标同步失衡的信号。直接看数值大小没意义，必须结合业务基线、实例配置和时间窗口判断是否真异常——比如 Logical Reads 达到 50 万/秒，对 OLTP 系统是严重问题，对夜间跑批的数仓可能完全正常。
先确认是不是真偏高：对比基线 + 检查快照窗口
AWR 报告里一堆数字，但“高”是相对的。没基线，所有数值都是废纸。
- 必须拿同一业务时段（比如工作日 9:00–10:00）的历史 AWR 报告做横向对比，而不是跟凌晨 3 点比
- 检查报告起止
SNAP_ID是否跨了非业务期（如备份窗口、统计信息收集任务），这类快照会拉高Physical Reads和Redo size - 单次快照间隔太短（DB Time 或
Execute Count出现尖峰假象 - 多实例 RAC 环境下，确认你分析的是问题节点的报告，别把 node2 的
Block Changes偏高当成 node1 的问题
Logical Reads 高但 Buffer Hit% > 99%？重点查 SQL 执行路径
Logical Reads 高 ≠ 缓存差。如果 Buffer Hit % 超过 99%，说明数据基本都在内存里，问题出在“读得太多”，而不是“读得慢”。
- 去
SQL Statistics → SQL ordered by Logical Reads，排序后看前 5 条 SQL 的Executions和Logical Reads per Exec - 如果某条 SQL
Logical Reads per Exec> 10 万，且Executions> 1000/小时，大概率是全表扫描（FULL TABLE SCAN）或索引未覆盖查询字段 - 用
DBMS_XPLAN.DISPLAY_AWR('<sql_id>')</sql_id>查执行计划，特别注意access_predicates和filter_predicates—— 后者意味着大量数据被扫出来再过滤，逻辑读必然飙升 - 警惕“伪高效”SQL：
WHERE status = 'A' AND create_time > SYSDATE - 1这类条件，若status基数低、create_time无索引，优化器很可能放弃索引走全表
DB Time 高但 DB CPU 低？等的不是 CPU，是别的资源
当 DB Time 显著高于 DB CPU（比如 DB Time 120s/s，DB CPU 只有 8s/s），说明数据库大部分时间在等，而不是算。
- 立刻翻到
Top 5 Timed Events，重点关注db file sequential read（单块读）、enq: TX - row lock contention（行锁）、latch: shared pool（共享池争用） - 如果 Top 1 是
SQL*Net break/reset to client，别急着查磁盘，先看Load Profile里的Logons per second—— 曾有系统每秒建 280 个连接，全是应用短连接未复用，每次登录触发 5 次后台 SQL，逻辑读虚高 -
Parse CPU to Parse Elapsd %parse count (hard) 每小时超 500 次，基本可断定是绑定变量缺失或 NLS 参数漂移 - 注意
DB Time单位是“秒/秒”，数值大于 1 就代表并发请求已超过单核处理能力；12 核机器上看到 15s/s，说明平均有 15 个会话同时在消耗数据库时间
Physical Reads 不高，但 Logical Reads 暴涨？小心“重复读同块”
物理读少说明磁盘不慢，但逻辑读暴涨，常见于应用层反复读取相同数据块，而没做缓存或批量处理。
- 检查应用代码是否在循环里执行
SELECT ... WHERE id = ?（N+1 查询），每轮都触发一次逻辑读，哪怕数据已在 buffer cache - 看
SQL ordered by Gets per Exec，如果某语句Gets per Exec稳定在几百但Rows processed只有 1–2，就是典型的低效访问模式 - 确认是否启用了
RESULT_CACHE或应用级缓存（如 Redis），避免数据库重复计算 - 批量提交缺失也会推高逻辑读：比如单条
INSERT后立即COMMIT，导致 undo block 频繁修改、buffer busy waits 上升，间接拉高逻辑读统计
真正难的不是看出哪个数高，而是判断这个“高”是业务增长带来的合理上升，还是执行计划劣化、应用误用、配置偏差引发的异常放大。尤其要注意 plan_hash_value 在不同快照间的突变——AWR 报告本身不标红提示，但它是逻辑读暴增最隐蔽也最常见的根因。
