大事务异常终止后SMON回滚会引发undo资源争用，典型标志是AWR中latch: undo global data占比超5%、wait for a undo record进Top 5且Avg Wait>10ms、fast_start_parallel_rollback为LOW/MEDIUM，并伴随enq: TX争用突升及ASH中同INSERT语句高buffer busy waits。
大事务异常终止后，SMON进程启动回滚，不是“慢”，而是数据库在疯狂争抢undo资源——latch: undo global data、wait for a undo record、enq: TX - row lock contention会直接冲进Top 5，此时看DB CPU或IO等待全是干扰项。
怎么一眼识别是大事务回滚在作祟
别等用户投诉再翻报告。只要AWR报告里出现以下任意组合，基本可以锁死：
-
latch: undo global data占DB Time >5%，且latch misses中频繁出现ktudba: KSLBEGIN -
wait for a undo record进入Top 5，Avg Wait >10ms，同时fast_start_parallel_rollback参数值为LOW或MEDIUM -
enq: TX - row lock contention或enq: TX - index contention突然跃升，但对应SQL只是简单INSERT或SELECT，没有明显DML逻辑 - ASH中大量会话堆在同一条
INSERT语句上，却伴随高buffer busy waits和read by other session
注意：SQL*Net message from client这类空闲事件如果也进了Top 5，且Avg Wait >100ms，说明应用层已开始超时重试，是回滚拖垮响应链的佐证，不是网络问题本身。
为什么不能只看DB CPU和IO等待
回滚过程CPU消耗不高（SMON不干计算活），物理读也不多（CR块来自buffer cache），所以DB CPU占比低、db file sequential read没上榜，不代表系统健康。真实瓶颈在内存结构争用：
-
latch: undo global data本质是多个会话并发访问SGA中undo segment header时抢同一个闩锁，跟CPU无关 -
wait for a undo record是会话在找前镜像数据做CR构建，等待的是undo block的可用性，不是磁盘IO - 回滚期间，哪怕只执行
SELECT COUNT(*)，也会触发大量CR构造，导致逻辑读暴涨但物理读不变——这时Logical Reads/sec飙升而Physical Reads/sec平稳，就是典型信号
回滚期间该查哪些关键视图和参数
AWR报告只是起点，必须立刻补查实时状态：
- 确认回滚进度：
SELECT usn, state, undoblocksdone, undoblockstotal FROM v$transaction;——undoblockstotal远大于undoblocksdone说明还在卡着 - 检查并行回滚是否失控：
SELECT * FROM v$fast_start_servers WHERE STATE = 'RECOVERING';—— 如果数量远超CPU_COUNT，大概率已互相阻塞 - 验证undo表空间压力：
SELECT tablespace_name, status, sum(bytes)/1024/1024 MB FROM dba_undo_extents GROUP BY tablespace_name, status;——UNEXPIRED占比过高（>80%）说明undo retention设置过长，加剧争用 - 临时缓解可调参数：
ALTER SYSTEM SET fast_start_parallel_rollback=FALSE;（慎用，需评估业务容忍度）
真正危险的不是回滚本身，而是回滚过程中新事务持续写入，不断生成新undo记录，把undo段头争用推到临界点。这时候任何高并发INSERT都可能瞬间雪崩。
