ora-01628本质是undo段extents耗尽（达32765上限），非磁盘空间不足；根源在于undo表空间碎片化或小事务泛滥导致无法分配新extent，需通过定位活跃segment、启用event 64000临时缓解，并结合清理碎片、调优undo_retention及批量提交根治。
ORA-01628报错本质是undo段extents耗尽，不是磁盘空间不够
ORA-01628错误显示max # extents 32765 reached for rollback segment，这说明某个undo段已分配满32765个区（extents），但底层表空间仍有空闲空间。很多人误以为是undo表空间不足，直接扩容UNDOTBS1数据文件，结果仍报错——因为问题不在总容量，而在undo段无法再申请新extent，根源通常是碎片化或小事务泛滥。
查清到底是哪个undo段卡住了
先确认具体出问题的segment名，错误信息里带的RBS_1或_SYSSMU613$就是关键线索。执行以下查询定位活跃undo段及其extent分布：
SELECT segment_name, tablespace_name, status, COUNT(*) extent_count FROM dba_undo_extents WHERE status = 'ACTIVE' GROUP BY segment_name, tablespace_name, status ORDER BY extent_count DESC;- 若发现某段
extent_count接近32765，且status为ACTIVE，基本锁定目标 - 注意：不要只看
dba_undo_extents，还要结合v$rollname和gv$transaction关联查会话，比如SELECT sid, serial#, username, sql_id FROM gv$session WHERE saddr IN (SELECT ses_addr FROM gv$transaction WHERE xidusn = &usn);
快速缓解：临时绕过extents上限限制
Oracle 11gR2+支持通过event强制放宽undo段extent限制，这是最直接的应急手段（需重启实例生效）：
- 在
init.ora或spfile中添加：event="64000 trace name context forever, level 25" - 该event允许undo段突破32765限制，但必须配合补丁
17306264，否则可能引发内部错误 - 不建议长期依赖此方案——它掩盖了事务设计缺陷，应同步推动开发优化
根治方向：清理碎片 + 控制事务粒度
真正解决问题得从两头入手：一是释放undo表空间碎片，二是避免产生大量小undo extent：
- 执行
PURGE RECYCLEBIN，回收站对象会锁住undo空间 - 检查
UNXPBLKREUCNT指标：运行SELECT inst_id, BEGIN_TIME, UNXPBLKREUCNT FROM gv$undostat WHERE UNXPBLKREUCNT > 0 ORDER BY BEGIN_TIME DESC;，值高说明未过期块被反复重用，典型碎片信号 - 调低
UNDO_RETENTION（如从1800秒降到900），减少undo保留压力；但要避开业务高峰，避免ORA-01555 - 禁止应用层频繁提交小事务（例如循环里每条INSERT都COMMIT），改用批量提交（
COMMIT every 1000 rows）
undo段extents上限是硬编码限制，不能靠ALTER TABLESPACE修改。所谓“扩容”只是把问题延后，真正卡点永远在事务行为和空间管理策略上。
