Oracle大规模数据迁移最优解是BULK COLLECT + FORALL分批提交，每1万条一次；需配LIMIT防内存溢出、用ROWID/主键避免全表扫描、禁用触发器、确保索引与权限。
oracle大规模数据迁移用游标循环批量提交，核心不是“能不能做”，而是“怎么控节奏、防锁表、避内存溢出”。直接上 forall + bulk collect 是最优解；纯隐式游标逐行 update 或 insert 只适合调试或万级以下数据，生产环境慎用。
用 BULK COLLECT + FORALL 实现每 1 万条提交一次
这是目前 Oracle 批量迁移最稳、最快的方式。它把数据一批批拉进 PL/SQL 内存数组，再一次性发给 SQL 引擎执行，避免了逐行解析开销。
-
BULK COLLECT INTO必须配合LIMIT使用，比如LIMIT 10000，否则可能撑爆 PGA 内存 -
FORALL i IN 1..l_data.COUNT中的索引范围必须和数组实际长度一致，不能写成1..10000—— 否则最后一批不足 1 万时会报ORA-06533: Subscript beyond count - 更新语句里尽量用
ROWID或主键，避免全表扫描；如果目标表有唯一约束，FORALL会批量校验，比单条快但失败时错误位置难定位
DECLARE
TYPE t_id_tab IS TABLE OF your_table.id%TYPE;
l_ids t_id_tab;
CURSOR c_data IS SELECT id FROM source_table WHERE status = 'NEW';
BEGIN
OPEN c_data;
LOOP
FETCH c_data BULK COLLECT INTO l_ids LIMIT 10000;
EXIT WHEN l_ids.COUNT = 0;
FORALL i IN 1..l_ids.COUNT
INSERT INTO target_table (id, name, created_at)
SELECT id, name, sysdate FROM source_table WHERE id = l_ids(i);
COMMIT;
END LOOP;
CLOSE c_data;
END;
为什么别用隐式游标 FOR rec IN (SELECT ...) 做大批量更新
这种写法看着简洁，但每轮循环都触发一次 SQL 解析 + 执行 + 日志写入，IO 和 latch 竞争剧烈，10 万行可能比 BULK 慢 5–10 倍。
- 容易触发
ORA-04030（PGA 耗尽），尤其当SELECT返回字段多、有大对象时 - 事务日志（redo）生成量翻倍：每条
UPDATE单独记 log，而FORALL是合并记 - 锁粒度不可控：隐式游标默认不加
FOR UPDATE，但如果更新逻辑依赖前序结果，可能产生不可预期的并发问题 - 异常后已提交批次无法回滚，只能靠幂等设计兜底（比如加
WHERE status != 'PROCESSED'）
COMMIT 频率不是越小越好，1 万是经验平衡点
太小（如每 100 条提交）→ 提交开销占比过高，整体耗时反而上升；太大（如每 10 万条）→ 单次事务 redo 太大，可能触发检查点风暴，甚至被 DBA 杀会话。
- 1 万条对多数 OLTP 表是安全阈值：通常对应 2–5 MB redo，不会明显拖慢 checkpoint
- 若目标表有大量索引或触发器，建议降到 5000 或更低——每多一个索引，DML 的 CPU 和 IO 成本线性增加
- 别在循环里加
DBMS_LOCK.SLEEP（如某些模板写的），这只会延长总耗时，不缓解锁竞争 - 确认业务允许“部分成功”：已提交批次不可逆，迁移中途失败需从断点续跑，不是重头再来
迁移前必须检查的三件事
再好的批量逻辑，踩中这三点中的任一坑，都会让迁移卡住、变慢或失败。
- 源表和目标表的关联字段是否都有索引？没索引的
WHERE条件会让每次INSERT或UPDATE变成全表扫描 - 目标表是否有启用的触发器？有就先
DISABLE，迁移完再ENABLE，否则每个FORALL行都触发一次，性能归零 - 用户是否有
INSERT/UPDATE目标表权限，且配额足够？常见错误是ORA-01536（空间配额超限），尤其用/*+ APPEND */时
真正麻烦的从来不是“怎么写循环”，而是“怎么让每次批量操作都落在数据库能高效响应的区间里”。参数调得再细，不如先看清执行计划里有没有 FULL TABLE SCAN 或 TABLE ACCESS BY INDEX ROWID BATCHED 的缺失。
