awr报告不直接显示“扩展瓶颈”，但可通过oos和nospaceerrcnt持续上升确认物理空间耗尽；unxpstealcnt与ssolderrcnt共现且autoextensible为no，表明弹性不足；enq: us - contention等待时间＞5ms则反映段分配卡顿。
awr报告本身不直接显示“扩展瓶颈”，但能通过三类关键指标交叉验证undo表空间是否因无法及时扩展而引发争用或错误。
看 OOS 和 NOSPACEERRCNT 是否持续上升
这两个计数器是物理空间真正耗尽的硬证据，不是配置警告，而是Oracle已拒绝分配的实锤。
-
OOS（Out of Space）出现在 AWR 报告的「Undo Segment Stats」小节，值 > 0 表示某次事务申请 Undo 段时，表空间连一个新区（extent）都分不出来 -
NOSPACEERRCNT来自V$UNDOSTAT，在 AWR 的「Instance Activity Stats」里搜不到，必须单独查：SELECT begin_time, end_time, nospaceerrcnt FROM v$undostat WHERE nospaceerrcnt > 0 ORDER BY begin_time DESC；只要它非零，说明那一刻表空间已满且未启用自动扩展，或自动扩展被阻塞（如磁盘满、maxsize 到顶） - 若
OOS和NOSPACEERRCNT在同一时段密集出现，基本可排除“只是保留时间不够”，直接锁定为扩展能力问题
比对 UNXPSTEALCNT 与 SSOLDERRCNT 的关系
这两项同时升高，往往意味着Undo表空间虽未完全耗尽，但因扩展滞后导致旧块被强制覆盖——这是“伪扩展瓶颈”：空间还有剩，但Oracle不敢等，提前回收。
-
UNXPSTEALCNT> 0：说明事务被迫覆盖未过期的 Undo 块，undo_retention形同虚设 -
SSOLDERRCNT> 0：一致性读失败，用户报 ORA-01555，典型症状是长查询突然报错 - 两者共现，且
DBA_DATA_FILES中对应 Undo 表空间的AUTOEXTENSIBLE为NO，或MAXBYTES已达上限，则是扩展策略跟不上负载节奏，不是空间总量问题，而是弹性不足
检查 AWR 中 Undo 相关等待事件是否集中于 enq: US - contention
这不是空间不足的直接信号，但它是扩展瓶颈的前置表现：多个会话排队等同一个 Undo 段头加锁，本质是段分配慢于事务生成速度。
- 在 AWR 的「Top 5 Timed Events」里搜
enq: US，若排进前 5 且平均等待时间 > 5ms，说明 Undo 段分配路径存在争用 - 进一步查「Wait Event Histogram」，看
enq: US - contention的等待时间是否集中在 1–16ms 或更高区间；越长，越说明底层扩展动作（如分配新区、初始化回滚段）卡顿 - 注意区分
enq: US - contention和enq: TX - row lock contention，后者是业务锁冲突，前者才是 Undo 管理层瓶颈
真正容易被忽略的是：UNDO 扩展瓶颈常藏在“看似有空间”的假象里——比如表空间还有 5% 空闲，但所有空闲区都是零碎的 64KB，而当前事务需要一次性分配 1MB 的新区。此时 V$UNDOSTAT 的 NOSPACEERRCNT 会跳，但 DBA_FREE_SPACE 显示仍有余量。盯住 NOSPACEERRCNT 和 OOS，比看百分比管用得多。
