load profile是数据库吞吐量计量器，非性能快照；logical reads反映buffer cache块访问频次，physical reads才是真实磁盘读取，二者比值揭示缓存效率；tps仅统计commit/rollback，不含只读事务、未提交事务及隐式提交，不能等同业务qps，须结合executes per second分析事务粒度。
load profile不是性能快照，而是数据库吞吐量的原始计量表——它不告诉你“哪里慢”，但能精确告诉你“每秒在干多少事”。
Logical Reads 和 Physical Reads 怎么看才不误判
Logical Reads 是 buffer cache 中发生的块访问次数，单位是 blocks/s；Physical Reads 才是真正从磁盘读的次数。两者比值直接反映缓存效率。
- Logical Reads 高 + Physical Reads 低 → 缓存命中好，瓶颈可能在 CPU 或 latch（比如
cache buffers chains） - Logical Reads 和 Physical Reads 同步飙升 → 真实 I/O 压力，要查
DBA_HIST_SQLSTAT里buffer_gets_delta最高的 SQL - Logical Reads 突增但 Physical Reads 不变 → 很可能是某条 SQL 开始全表扫描，或绑定变量失效导致硬解析+重复逻辑读
TPS（Transactions per Second）为什么不能直接当业务 QPS 用
TPS 在 Load Profile 里只统计 COMMIT 和 ROLLBACK 触发的事务终点，不含只读事务、未提交事务、DDL 隐式提交，也不含应用层事务（如 Spring @Transactional 的嵌套事务）。
- 看到
TPS = 120，不代表每秒有 120 笔订单完成——可能是 10 个批量导入事务集中提交，也可能是 1200 次短连接自动提交 - 真正判断业务负载，得结合
Executes Per Second：如果TPS低但Executes高，说明单事务 SQL 多（如报表）；反之TPS高但Executes低，说明事务粒度细（如支付流水） -
TPS来自DBA_HIST_SYSSTAT的user commits和user rollbacks差值，按快照间隔归一化——不是实时流，无法捕捉秒级毛刺
Redo size 和 DB Time 的单位陷阱
Redo size 单位是字节/秒，DB Time 单位是秒/秒（即每秒消耗的数据库时间总量）。这两个数必须换算成硬件能力才能指导扩容。
-
Redo size > 20 MB/s→ 日志磁盘持续写入能力至少预留 25 MB/s（留 20% 余量），否则log file sync等待会上升 -
DB Time = 186.7 s/s表示数据库每秒“忙了 186.7 秒”，远超单核 CPU 的理论上限（1 s/s），说明并发高或等待严重；但若DB CPU = 1.5 s/s，就证明瓶颈不在 CPU，在别处（比如 I/O 或锁） - 注意
Elapsed时间是否匹配业务高峰：用 2 小时快照却只覆盖 15 分钟真实峰值，所有 per second 指标都会被稀释，按此扩容会低估 7 倍以上压力
Parse Calls 和 Recursive Calls 暴露的是配置问题，不是硬件问题
Parses 超过 300/s 或 Hard parses 超过 100/s，基本可判定是软件层配置缺陷，加内存、CPU 都无效。
-
Recursive Calls占总Executes> 15% → 数据字典争用或硬解析泛滥，根源常是没设session_cached_cursors或没用绑定变量 -
Logons > 2/s→ 连接池复用率低，可能触发library cache lock或shared poollatch 争用 - RAC 环境下 Load Profile 默认聚合全部节点，但若某节点
Block Changes占比 90%，说明写热点集中——按总值扩容会让其他节点闲置 30% 资源
Load Profile 的数字本身没意义，关键在差值、比值和时间粒度。5 分钟级波动里藏着 90% 的真实瓶颈，而默认 1 小时聚合只会让你看到一个平滑但失真的平均线。
