Oracle数据库中，一个事务从第一条DML语句开始到提交或回滚结束，期间产生的undo记录、redo日志以及持有的行级锁都不会释放。当事务涉及的数据量达到百万级甚至千万级时，单个事务运行数小时会带来严重问题：undo表空间膨胀、锁竞争激化、实例恢复时间变长。把大事务拆分为若干个小事务，让每个小事务处理固定行数或固定业务范围后立即提交，是解决这类问题的常用手段。拆分事务并不是简单地在循环里加COMMIT，还需要考虑游标稳定性、异常恢复、批量操作的性能以及业务一致性。
从数据库内部机制来看，事务开始后执行的第一条DML会分配一个事务槽，后续对该事务中所有数据块的修改都会指向这个事务槽。Oracle为了保证读一致性，会在undo表空间中保存修改前的数据镜像。如果事务长时间不提交，这些undo数据会一直保留，同时事务涉及的undo块无法被覆盖。如果是删除或更新大量行的操作，undo使用量可能达到几GB甚至几十GB，最终出现ORA-01555快照过旧或者undo表空间无法扩展的错误。另外，事务持有的行级锁只会在提交或回滚时释放，其他会话对相同行的修改只能等待，严重时形成锁队列，数据库响应速度急剧下降。
一、大事务对Oracle资源和并发的影响
大事务最直接的代价是undo段持续膨胀。以删除一千万行数据为例，假设每行平均长度200字节，undo中需要记录删除前的整行数据以及指向数据块的元信息，如果所有删除操作放在一个事务中，undo表空间至少需要预留2GB到4GB的空间。即使undo表空间配置了自动扩展，磁盘写入压力也会在事务执行期间持续上升。更隐蔽的问题是，Oracle的undo保留策略通常基于时间，而不是基于事务是否已经提交，未提交事务的undo块在undo段中不可重用，会迫使数据库不断分配新的undo区，进一步加剧空间消耗。
锁竞争是另一个容易被低估的隐患。Oracle的行级锁存储在数据块内部，事务修改某一行时会在该行上标记锁信息。大事务处理的往往是某个业务范围内的所有数据，比如一个分区、一段时间范围内的订单、或者满足特定状态条件的记录。如果这些行同时被其他在线业务访问，锁等待会迅速蔓延。即使其他会话只读取这些行，Oracle的多版本读一致性机制可以避免读阻塞，但如果其他会话也要更新其中某些行，就会遇到enq: TX - row lock contention等待事件。在线业务通常要求毫秒级响应，而大事务可能让这些更新等待几十分钟甚至几小时，业务端会表现为大面积超时。
大事务还会增加实例恢复的时间。Oracle在实例异常崩溃后，需要利用redo日志前滚已提交的修改，再利用undo回滚未提交的修改。如果一个大事务运行了很久但没有提交，实例恢复时必须扫描并回滚其全部变更，恢复时间与事务大小成正比。在某些容灾场景下，这种恢复耗时可能导致RTO指标不达标。将大事务拆分成多个小事务，每个小事务快速提交，能够显著缩短恢复窗口，因为已经提交的小事务无需回滚，只有最后未提交的小事务才需要处理。
二、拆分事务的核心思路：游标分批提交
拆分事务最常见的方式是使用PL/SQL游标配合BULK COLLECT和FORALL。游标查询出需要处理的行，按照固定行数分批获取，每批执行DML后立即提交。这样每个小事务只处理有限的数据量，undo和锁的持有时间都被控制在很小的范围内。下面是一段基于游标分批提交的更新示例，它从large_table中分批读取状态为PENDING的记录，每次处理1000行，处理完成后提交。
DECLARE
CURSOR c_data IS
SELECT rowid, id
FROM large_table
WHERE status = 'PENDING'
ORDER BY id;
TYPE t_rowid_tab IS TABLE OF ROWID;
TYPE t_id_tab IS TABLE OF NUMBER;
l_rowids t_rowid_tab;
l_ids t_id_tab;
v_batch_size NUMBER := 1000;
BEGIN
OPEN c_data;
LOOP
FETCH c_data BULK COLLECT INTO l_ids, l_rowids LIMIT v_batch_size;
EXIT WHEN l_ids.COUNT = 0;
FORALL i IN 1..l_ids.COUNT
UPDATE large_table
SET status = 'DONE'
WHERE rowid = l_rowids(i);
COMMIT;
END LOOP;
CLOSE c_data;
END;
/
这段代码的核心在于LIMIT v_batch_size，它让FETCH每次只取1000行到PL/SQL集合中，处理完这一批后立即执行COMMIT。提交之后，这一批行上的锁和undo都可以被释放，后续批次处理时不会累积资源压力。游标在循环期间保持打开状态，但Oracle的游标并不会因为提交而失效，只要游标定义本身不包含FOR UPDATE子句，读取一致性不会受到提交影响。这里通过rowid精确定位每一行，避免在更新时重复查找，提高更新效率。
批量大小的选择需要结合表和业务特点进行调整。如果每批行数太小，比如一次只处理10行，虽然锁持有时间很短，但提交过于频繁，会产生大量redo日志和lgwr写盘操作，整体性能反而下降。如果每批行数太大，比如一次处理100万行，又没有达到拆分事务的效果，undo和锁仍然会累积。通常从500行或1000行开始测试，观察单批执行时间和undo使用量，找到一个平衡点。对于行长度较大、更新涉及索引较多的表，批量大小可以适当调低，避免单批执行时间过长。
需要注意的是，显式提交会改变事务边界，因此拆分事务只适用于那些允许部分提交的业务场景。如果业务要求整批数据要么全部成功要么全部失败，那么这种逐批提交的方式会破坏原子性。在这种情况下，可以考虑使用SAVEPOINT配合异常处理来实现可恢复的操作，或者将拆分粒度放到更高层的业务服务中，由调用方决定哪些小事务必须同时成功。
三、使用FORALL和BULK COLLECT提升拆分效率
游标分批提交虽然解决了事务过大问题，但如果每批内部仍然使用逐行DML，性能会非常糟糕。Oracle提供了BULK COLLECT和FORALL两个PL/SQL特性，分别用于批量读取和批量写入。批量读取可以把多行数据一次性加载到集合里，减少SQL引擎和PL/SQL引擎之间的上下文切换；批量写入则可以把多行DML一次性发送给SQL引擎执行。两者的配合可以让小事务的每批处理时间从秒级降低到毫秒级，从而提高整体吞吐量。
下面是一段删除操作的批量处理示例。假设需要删除一张大表中已经过期的数据，每次取出500行rowid，通过FORALL批量删除，每批完成后提交。这样既保证了小事务的快速提交，又避免了逐行删除时的性能损失。
DECLARE
CURSOR c_expired IS
SELECT rowid
FROM archive_table
WHERE expire_date < SYSDATE - 365
ORDER BY expire_date;
TYPE t_rowid_tab IS TABLE OF ROWID;
l_rowids t_rowid_tab;
v_batch_size NUMBER := 500;
BEGIN
OPEN c_expired;
LOOP
FETCH c_expired BULK COLLECT INTO l_rowids LIMIT v_batch_size;
EXIT WHEN l_rowids.COUNT = 0;
FORALL i IN 1..l_rowids.COUNT
DELETE FROM archive_table WHERE rowid = l_rowids(i);
COMMIT;
END LOOP;
CLOSE c_expired;
END;
/
在PL/SQL中，BULK COLLECT会把查询结果直接填充到集合中，减少了行级处理时的SQL引擎调用次数。FORALL则把集合中的每一行绑定到SQL语句中，一次性执行。需要注意的是，集合的大小受限于内存，使用LIMIT可以避免集合过大导致PGA占用过高。在Oracle 10g及之后的版本中，FORALL已经成为批量DML的标准写法，相比传统的FOR循环加单条DML，性能可以提升数倍到数十倍。
还有一个容易忽略的细节：FORALL语句后面的DML不能直接使用COMMIT，提交必须放在FORALL之后单独一行。如果尝试在FORALL内部提交，PL/SQL编译器会报错。另外，FORALL执行时如果遇到约束冲突，默认会抛出异常并终止。对于数据质量不确定的场景，可以使用SAVE EXCEPTIONS子句记录全部异常，然后决定是回滚整个批次还是跳过有问题的行。
四、拆分过程中的异常恢复与SAVEPOINT管理
分批提交加强了资源的可管理性，但也带来了一个新的问题：如果某一批执行失败，之前批次已经成功提交，整体数据处于部分完成状态。为了让拆分过程具备可恢复性，通常有两种策略。第一种是在每个小事务内部使用SAVEPOINT，当批次内某条语句失败时可以回滚到该保存点，而不是回滚整个批次。第二种是在外部维护一个进度表，记录已经处理完成的分批标识或游标位置，失败后可以从下一个批次继续执行，而不需要重复处理已提交的数据。
下面这段代码展示了如何在小事务内使用SAVEPOINT和异常捕获。每一批开始时创建一个保存点，执行FORALL时如果出现错误，就回滚到保存点，跳过当前批次并继续处理后续数据。同时增加一个最大错误次数限制，避免无限跳过导致全部数据无法处理。
DECLARE
CURSOR c_data IS
SELECT rowid
FROM staging_table
WHERE status = 'NEW'
ORDER BY load_time;
TYPE t_rowid_tab IS TABLE OF ROWID;
l_rowids t_rowid_tab;
v_errors NUMBER := 0;
v_max_errors NUMBER := 50;
BEGIN
OPEN c_data;
LOOP
FETCH c_data BULK COLLECT INTO l_rowids LIMIT 300;
EXIT WHEN l_rowids.COUNT = 0;
SAVEPOINT batch_sp;
BEGIN
FORALL i IN 1..l_rowids.COUNT
DELETE FROM staging_table WHERE rowid = l_rowids(i);
COMMIT;
EXCEPTION
WHEN OTHERS THEN
ROLLBACK TO batch_sp;
v_errors := v_errors + 1;
IF v_errors > v_max_errors THEN
RAISE;
END IF;
END;
END LOOP;
CLOSE c_data;
END;
/
这个例子中，SAVEPOINT batch_sp在每批开始前创建，如果批次内删除失败，就回滚到保存点，这样之前已经提交的批次不受影响，当前批次也可以被整体跳过。但如果错误是由于数据本身的问题，比如违反外键约束，那么跳过当前批次后后续批次可能仍然失败。此时需要根据错误信息判断是否应该中止程序，或者把错误记录写入日志表供人工检查。
还有一种更稳健的做法是使用DBMS_PARALLEL_EXECUTE包，它可以将大表按ROWID范围或键值范围分成若干小块，每个小块作为一个独立任务执行，任务失败时便于定位和重试。不过对于简单的一次性清理任务，自制游标分批提交通常已经足够。关键是在设计时明确失败恢复策略，不要放任拆分过程中途中断导致的数据不一致。
五、拆分小事务的适用场景与注意事项
大事务拆分并不适合所有情况。对于金额转账、库存扣减这类对原子性要求极高的业务，拆分提交会破坏ACID特性，必须通过其他方式保证一致性，比如使用最终一致性的补偿机制、或者把大事务拆成多个独立的小事务但由上层服务统一调度。Oracle数据库中的大事务拆分更多应用于历史数据归档、大表清理、批量状态更新、数据迁移和ETL加载等允许部分提交的场景。这些场景的共同特点是每一条数据的处理相对独立，没有跨批次的强依赖关系。
在实施拆分之前，还需要考虑索引维护的开销。批量更新或删除会同步维护目标表上的所有索引，如果表上存在大量索引，每批数据处理的代价会增加。此时可以评估是否先禁用非必要的索引，等批量操作完成后再重建。对于分区表，可以按分区逐区处理，每个分区内部再按行数分批提交，这样锁和undo只影响单个分区，同时可以利用分区裁剪减少扫描范围。如果数据量特别大，还可以结合并行执行，但要注意并行度和资源竞争之间的平衡。
最后要强调的是，拆分小事务的核心不是简单地在代码里加COMMIT，而是围绕业务边界和资源控制进行设计。每一批处理的行数、执行频率、异常处理策略、进度记录方式都需要提前规划。通过合理的游标分批、BULK COLLECT和FORALL批量操作，再加上适当的SAVEPOINT保护，可以让大事务从不可控的资源黑洞变成一系列快速提交的小任务，从而保障在线业务的稳定运行和数据库的长期健康。