awr load profile中的tps指oracle内部每秒提交/回滚事务数，仅统计commit和rollback，不含只读事务、未结束事务及隐式提交；逻辑读指每秒buffer cache块访问次数，反映“想读多少”而非i/o压力。
awr load profile里tps到底指什么
TPS（Transactions Per Second）在AWR的Load Profile部分，**不是应用层事务数，也不是SQL执行次数，而是Oracle内部提交/回滚事务的速率**。它只统计COMMIT和ROLLBACK语句触发的事务终点，不包含只读事务或未结束事务。
- 常见误解：看到TPS低就认为系统“不忙”——错，大量短连接+自动提交或应用层事务控制（如Spring
@Transactional）可能让TPS虚高；而长事务、批量DML后集中提交则会让TPS偏低但实际负载重 - 真实场景中，TPS需结合
Executes Per Second和Parse Calls Per Second看：如果TPS低但Execute高，大概率是单事务多SQL（如报表类）；反之TPS高但Execute低，可能是高频小事务（如订单支付） - 该值来自
DBA_HIST_SYSSTAT中user commits与user rollbacks两个统计项差值，按快照间隔归一化得出，**不是实时采样，也不含隐式提交（如DDL）**
逻辑读（Logical Reads）为什么经常被误读
Logical Reads是每个快照周期内buffer cache中完成的块访问次数（单位：次/秒），它反映的是Oracle“想读多少”，而不是“从哪读”。一次SQL可能产生上千逻辑读，但物理读为0——这完全正常。
- 容易踩的坑：
Logical Reads高 ≠ I/O压力大。如果Physical Reads很低，说明数据基本在buffer cache里，此时瓶颈更可能在CPU或latch争用（比如cache buffers chains） - 注意区分
db block gets（当前模式读，如UPDATE）和consistent gets（一致性读，如SELECT），两者都计入逻辑读，但含义不同；AWR汇总时不做拆分 - 参数
db_cache_size直接影响其基数：缓存太小会导致相同SQL反复重读块，逻辑读飙升但业务无变化；升级内存后逻辑读可能下降，但TPS未必变
怎么看才不算白看Load Profile
单独盯着TPS或逻辑读数字没意义，必须拉出时间维度比对，并关联其他指标。AWR默认按1小时粒度聚合，但关键问题往往藏在5分钟级波动里。
- 用
awr_report_text或awrddrpt.sql生成对比报告，重点看「两个快照间」的差值，而非绝对值；尤其关注TPS突增时段是否同步出现log file sync等待 - 逻辑读激增时，立刻查
DBA_HIST_SQLSTAT中buffer_gets_deltaTop SQL，90%的情况是某条SQL走了全表扫描或缺失绑定变量 - 别忽略
Recursive Calls：如果它占总Execute比例＞15%，说明数据字典争用或频繁硬解析，此时逻辑读高是副作用，根因不在SQL本身
用脚本快速定位异常区间（非图形界面下）
图形化AWR报告容易漏掉拐点，用SQL直接查DBA_HIST_SYSMETRIC_SUMMARY更快：
SELECT TO_CHAR(end_time, 'HH24:MI') tm,
ROUND(average, 2) tps,
ROUND(average2, 2) log_reads
FROM dba_hist_sysmetric_summary
WHERE metric_name IN ('User Transaction Per Sec', 'Logical Reads Per Sec')
AND end_time > SYSDATE - 1/24
ORDER BY end_time;
其中average对应TPS，average2对应逻辑读（字段名固定，不随语言变）。注意：该视图每5分钟一个点，但Load Profile是按快照（默认60分钟）算的，所以数值会更敏感——这也正是它能早于图形报告暴露问题的原因。
真正难的不是看懂这两个数，而是当TPS平稳但逻辑读翻倍时，得立刻想到是不是某个分区表的本地索引失效了，或者统计信息陈旧导致执行计划退化。这种时候，Load Profile只是个路标，不是答案本身。
