Transactions指标位于AWR报告的Report Summary→Load Profile区域，直接显示每秒事务数（如916.9 txn/sec），由(user commits + user rollbacks) / elapsed seconds计算得出，仅统计前台用户级事务，不包含后台进程。
awr报告里的transactions指标直接反映每秒事务数，不是累计值，也不需要换算——它已经是你最需要的那个数字。
Transactions指标在哪看？
在AWR报告的 Report Summary → Load Profile 区域，你会看到一行：
Transactions: 916.9
这个 916.9 就是该快照时间段内「平均每秒发生的事务数」，单位是 txn/sec。它由 Oracle 内部统计 user commits 和 user rollbacks 后自动计算得出，公式为：
(user commits + user rollbacks) / (elapsed seconds)
注意：它不包含后台进程事务（如SMON、MMON），只统计前台用户级事务。
为什么不能查v$transaction来算每秒事务数？
因为 v$transaction 只显示当前未提交的活跃事务，一提交就消失。你执行：
SELECT * FROM v$transaction;
结果为空，不代表没事务，只说明此刻没有未提交事务。靠它统计吞吐量完全不可行。
常见误操作包括：
- 用
v$sysstat中user commits的差值除以秒数，但没对齐快照时间点，导致跨快照误差 - 把
v$session的status = 'ACTIVE'当作事务在跑，混淆了会话状态和事务生命周期 - 在 RAC 环境下只查单实例
v$sysstat，漏掉其他节点的 commit 计数
Transactions高或低意味着什么？
数值本身无绝对好坏，关键看趋势和上下文：
-
Transactions > 1~2/sec是正常 OLTP 系统起点；若长期低于 0.1，可能应用连接池空闲、或业务停摆 - 突增（比如从 50 跳到 800）需结合
Top SQL和Wait Events看是否由批量作业触发（如 ETL 抽取） - 持续高位但
DB Time不高，说明事务轻量、效率高；若DB Time同步飙升，大概率存在锁争用或低效 SQL - 回滚率（
Rollback per transaction）超过 15%，要警惕应用逻辑缺陷或异常重试机制
特别注意：Transactions 是“前台事务”指标，和后台任务（如归档、日志切换、AWR 自身快照）无关——别把它和系统负载画等号。
如何验证Transactions数据是否可信？
AWR 的 Transactions 来自 DBA_HIST_SYSSTAT 基于快照的差值，可靠性高，但有两点必须核对：
- 确认所选快照区间内没有人工
TRUNCATE或DROPAWR 表（极少见，但发生过） - 检查报告头部的
Elapsed时间是否合理（比如显示 3600 秒，实际只跑了 5 分钟，说明快照被异常截断） - 对比同一时段的 Statspack 报告（如有），看
Transactions是否量级一致 —— 若偏差超 10%，优先怀疑采样丢失
真正容易被忽略的是：AWR 默认每小时打一个快照，而 Transactions 是该小时内的均值。如果你分析的是凌晨 2:00–3:00 的报告，但业务高峰在 2:45–2:55，这个均值会严重稀释峰值压力。此时应手动创建 10 分钟粒度快照再生成报告，而不是依赖默认设置。
