根本原因是事务未分段导致undo生命周期失控，而非数据量大；oracle因长事务被迫全程保留所有前镜像，直至提交才释放，须通过分批提交、逻辑拆分、异步化及禁用非必要触发器等手段控制undo占用。
根本原因不是“数据量大”，而是事务没分段、Undo生命周期失控。 Oracle 不会因为你更新 100 万行就报 ORA-01555 或 ORA-30036，而是因为你把这 100 万行塞进一个事务里，Undo 段被迫全程保留所有前镜像，直到 COMMIT 或 ROLLBACK 才能释放。
PL/SQL 循环中不提交 = Undo 持续累积
常见写法如 FOR i IN 1..100000 LOOP UPDATE t SET x = x+1 WHERE id = i; END LOOP;，表面看每行只改一条，但整个循环在同一个事务上下文中——Oracle 必须为每一行变更都保留旧值，直到循环结束。哪怕单行 Undo 占 200 字节，10 万行就是 20MB 连续占用，且无法复用。
- 显式
COMMIT放在循环内（如每行都 commit）看似“释放”，实则引入大量 redo 日志刷盘和 latch 争用，性能更差 - 正确做法是批量控制提交节奏：用
MOD(i, 5000) = 0触发COMMIT，确保单次事务 Undo 消耗可控 - 避免在循环中混入
DBMS_OUTPUT.PUT_LINE、SLEEP或远程调用——它们延长事务时间，却不产生业务价值
BULK COLLECT + FORALL 能减少 Undo 吗？
能，但不是靠“少生成”，而是靠**降低上下文切换频次和减少解析开销**，间接缓解 Undo 压力。单次 FORALL UPDATE 仍会产生完整 Undo，但它比逐行执行快 5–10 倍，意味着 Undo 占用时间窗口大幅缩短，被其他长事务挤占的风险下降。
- 必须配合
SAVE EXCEPTIONS和分批大小控制（如LIMIT 1000），否则一次失败全回滚 - 若表上有触发器或外键级联，
FORALL仍会逐行触发，Undo 并不节省——此时应先禁用触发器（ALTER TRIGGER ... DISABLE），操作完再启用 -
BULK COLLECT INTO本身不写 Undo，但后续FORALL更新时 Undo 量与手工循环一致，别误以为“批量=省 Undo”
为什么加 UNDO_RETENTION 或扩表空间常无效？
因为问题不在“空间不够”，而在“空间被无效占着”。比如一个 PL/SQL 过程执行 2 小时，中间有 1.8 小时在等外部接口响应，这期间 Undo 段不能回收，哪怕你把 UNDO_RETENTION 设成 3600 秒、表空间扩到 100GB，它照样报 ORA-30036。
- 查真实压力源：
SELECT sql_id, undoblks FROM v$transaction t JOIN v$session s ON t.ses_addr = s.saddr JOIN v$sqlarea a ON s.sql_id = a.sql_id ORDER BY undoblks DESC - 确认是否真需要事务一致性：报表类更新（如标记“已导出”）可改用
INSERT /*+ APPEND */ INTO temp_export_log绕过 Undo - 异步化非核心逻辑：把发消息、写审计日志等移出主事务，用
DBMS_SCHEDULER.CREATE_JOB延后执行
最易被忽略的点是：PL/SQL 中的隐式游标（如 SELECT ... INTO）也会开启一致性读，若配合 FOR UPDATE 或长时间持有结果集，同样延长 Undo 生命周期。别只盯着 DML，读操作在高并发下也是 Undo 消耗者。
