AWR报告中Transactions Per Second值仅反映快照内平均负载密度，不可信作瞬时指标；需用DBA_HIST_SYSMETRIC_SUMMARY查分钟级趋势，并对比基线差异，同时警惕维护事务干扰和RAC汇总失真。
看Load Profile里的Transactions Per Second是否可信
AWR报告中Transactions列的Per Second值，是快照窗口内事务总数除以采样时长（秒）得出的平均值。它不反映瞬时峰值，只适合判断整体负载密度。比如9:00–10:00之间共发生27万次事务，报告就显示75.0——但这掩盖了9:15可能有300 TPS、9:45却只有5 TPS的事实。
若需观察“变化趋势”，必须跨多个连续快照比对。单份AWR报告无法体现波动。
用DBA_HIST_SYSMETRIC_SUMMARY查每分钟粒度的事务速率
DBA_HIST_SYSMETRIC_SUMMARY视图按分钟保存了Transactions Per Second的滚动统计，比AWR快照细10倍。执行以下查询可拉出趋势线：
SELECT TO_CHAR(end_time, 'YYYY-MM-DD HH24:MI') AS minute,
ROUND(average, 2) AS tx_per_sec
FROM dba_hist_sysmetric_summary
WHERE metric_name = 'Transactions Per Second'
AND end_time BETWEEN SYSDATE - 1/24 AND SYSDATE
ORDER BY end_time;注意：average字段是该分钟内每秒事务数的均值，不是总和；end_time是该分钟的结束时间点。
- 该视图默认保留与AWR相同周期（通常8天），但数据粒度更密
- 若返回空，检查
V$SYSMETRIC确认当前是否启用该指标（19c默认开启） - 避免直接查
V$SYSMETRIC_HISTORY——它只存最近1小时，且未归档
对比正常时段与问题时段的Transactions值差异
孤立看一个Transactions Per Second = 120毫无意义。关键是比较：同一业务周期（如每日9:00–10:00）在不同日期的数值是否偏离基线。
用如下SQL快速提取过去7天同一窗口的均值与标准差：
SELECT TRUNC(end_time, 'HH24') AS hour_window,
ROUND(AVG(average), 2) AS avg_tx_sec,
ROUND(STDDEV(average), 2) AS std_tx_sec
FROM dba_hist_sysmetric_summary
WHERE metric_name = 'Transactions Per Second'
AND end_time >= SYSDATE - 7
AND TO_CHAR(end_time, 'HH24:MI') BETWEEN '09:00' AND '10:00'
GROUP BY TRUNC(end_time, 'HH24')
ORDER BY hour_window;若某日该窗口值超出avg_tx_sec + 2 * std_tx_sec，才值得怀疑是异常突增或衰减。
警惕Transactions值被“稀释”或“虚高”的情况
Transactions统计基于v$sysstat中的user commits和user rollbacks之和。它不区分业务事务与维护类事务，容易误导：
- 物化视图自动刷新、JOB定时任务、LOGON触发器中的隐式提交，都会计入该值
- 应用层短事务（如每秒上千次
INSERT ... COMMIT）会让Transactions Per Second飙升，但实际业务吞吐未必增加 - RAC环境下，若未按实例过滤，
DBA_HIST_SYSMETRIC_SUMMARY会汇总所有节点，掩盖单节点过载
真要看业务事务趋势，应结合SQL ordered by Executions页，筛选出EXECUTIONS高且ELAPSED_TIME_PER_EXEC稳定的DML语句，再用DBA_HIST_SQLSTAT按sql_id聚合其每分钟执行次数——这才是贴近业务的真实节奏。
