大事务卡住或报 ORA-01555 / ORA-30036 怎么办

遇到大事务卡住或者报出ORA-01555、ORA-30036这类错误，很多人的第一反应是“提交太慢了”。其实，这恰恰是数据库在履行它的核心职责：保护数据的一致性。问题的本质，往往是UNDO表空间被撑爆，或者查询所需的旧数据快照已经过期。这时候，盲目调大UNDO_RETENTION参数或者给UNDO表空间扩容，就像是给一个不断漏水的水池加高围栏，治标不治本。真正的解决思路，是学会如何科学地“切分事务”。

那么，事务该怎么切分？这里有几个关键点需要把握：

• 首先，COMMIT绝不能随意地加在循环体内。比如在FOR rec IN (SELECT ...)循环里每处理一条记录就提交一次，这确实能快速释放UNDO空间，但代价是破坏了业务的原子性。想象一下，如果循环到一半程序中断，数据就会处于一个“半成品”的中间状态，这往往是灾难性的。
• 真正的安全切分点，必须建立在逻辑上可独立提交的“批次”上。常见的策略包括：按主键ID范围分段（例如每次处理1万到10万个ID）、按时间范围截取（WHERE create_date BETWEEN ... AND ...），或者利用ROWNUM直接控制每次处理的行数（比如1000行）。
• 还有一个必须警惕的细节：显式记录断点。在每批处理完成后，务必用一个变量记录下最后处理成功的ID或者MAX(rowid)。这样，万一程序需要重跑，就可以从这个断点精准地“续传”，完美避免数据重复处理或遗漏的风险。

用 BULK COLLECT + FORALL 分批比逐行快多少

说到分批处理，就不得不提PL/SQL的性能利器：BULK COLLECT和FORALL。它们的速度提升可不是“快一点”那么简单，而是数量级的差异。传统的逐行处理（INSERT、UPDATE）需要在SQL引擎和PL/SQL引擎之间反复切换上下文，开销巨大。而BULK COLLECT一次性将数据抓取到内存的集合数组中，再由FORALL批量发送给SQL引擎执行，能轻松省去90%以上的上下文切换成本。

用好这套组合拳，有几个经验法则：

• 批量大小（LIMIT）设多少？1000是个经过大量实践检验的经验值。设得太小（比如10），批量优势荡然无存；设得太大（比如10万），则可能撑爆PGA内存，引发内存告警甚至垃圾回收延迟。
• 在FORALL语句中，推荐使用FORALL i IN INDICES OF collection_name的语法。它比FORALL i IN 1..collection_name.COUNT更安全，能够自动跳过集合中可能被DELETE操作留下的稀疏索引项，避免执行错误。
• 务必为FORALL加上SA VE EXCEPTIONS子句。否则，批量操作中任意一行数据出错，都会导致整个批次回滚，而你却无从得知究竟是哪条数据出了问题。

UNDO 表空间不够时，COMMIT 频率和 UNDO_RETENTION 怎么配

理解了分批，我们再来看UNDO空间的配置。一个常见的误区是认为COMMIT越频繁，UNDO空间就释放得越快。其实不然。频繁提交确实能缩短单个事务持有UNDO块的时间，但事务提交后，其产生的UNDO数据（旧镜像）并不会立即被覆盖，而是要等到不再被任何查询需要时才行。过于频繁的提交可能导致UNDO块更加碎片化，管理开销反而增加。

正确的调整思路应该是：

• 优先调整UNDO_RETENTION参数。将其设置为略长于单批任务的最长执行时间。例如，如果一批数据处理平均需要8秒，那么将UNDO_RETENTION设为12秒左右，可以有效预防因快照过旧而引发的ORA-01555错误。
• 不要一报警就急着给UNDO表空间扩容。先查询V$UNDOSTAT视图，关注UNXPSTEALCNT（非到期UNDO块被强制覆盖的次数）这个指标。如果它大于0，才说明UNDO空间确实紧张；如果为0，那么问题很可能出在批次大小不合理或者存在锁等待上。
• 对于需要精确断点续传的场景，记录时间点用SYSDATE并不可靠。更推荐使用DBMS_FLASHBACK.GET_SYSTEM_CHANGE_NUMBER获取起点的SCN（系统变更号）。时间是可能“跳动”的，但SCN的顺序是绝对可靠的。

为什么加了 COMMIT 还是 OOM 或 PGA 超限

有时候，明明已经加了COMMIT，程序却还是报出内存不足（OOM）或PGA超限的错误。这是因为存在一个关键认知差：COMMIT操作只负责释放UNDO段中的空间和相关的锁，它并不会自动释放PL/SQL程序中变量所占用的内存。

举个例子，你用BULK COLLECT一次性抓取了10万行数据到某个集合变量中，即使之后执行了COMMIT，这10万行数据依然驻留在PGA内存里。如果下一轮循环又向同一个集合填充新数据，内存占用就会只增不减，最终导致溢出。

破解之法在于主动管理内存：

• 每次COMMIT之后，必须显式清空之前使用的集合变量。正确做法是调用collection_name.DELETE，而不是简单地用collection_name := empty_collection_type()重新赋值（后者可能在某些情况下无法立即释放内存）。
• 避免在循环体内拼接巨大的动态SQL字符串（如v_sql := v_sql || '...'），这会导致内存不断分配且难以回收。应考虑使用DBMS_SQL包，或者先将中间数据写入临时表。
• 如果源数据量极其庞大（例如需要全表扫描几千万行），不要使用SELECT ... BULK COLLECT INTO一次性加载。应该使用显式游标，结合FETCH ... BULK COLLECT ... LIMIT ...的方式分页读取，严格控制单次驻留在内存中的数据量。

说到底，技术上的难点往往不在于写下COMMIT这个关键字，而在于如何准确地界定“这一批”数据是否构成了一个完整的、可独立提交的业务单元。UNDO空间告警通常只是一个表面症状，其背后反映的，常常是事务设计与实际业务逻辑未能对齐的问题。例如，硬要把“同步用户信息”、“更新全局统计”、“发送通知消息”这三个步骤塞进同一个大事务，而后两者其实完全可以通过异步机制来实现。这才是优化需要触及的本质。