大型数据库迁移爆出的问题

[tzcddshiren]

公司在做一个数据库迁移的项目，将数据从老系统转换到新系统的一套关系表中，其中一个存储过程涉及到需要插入的数据量大约20亿左右，我建立的游标每次差不多300w提交一次，然后就会提示一个错误，快照过旧：回退段号29 过小 。自己百度了一下，可能是表空间太小，也可能是频繁提交，百度的都不太专业，所以请教大家有没有遇到过类似的问题，然后要怎么解决？比较着急 先谢过大家

[碧水幽幽泉]

报错的具体信息发下。

[tzcddshiren]

[tzcddshiren]

上面这个是报错截图

[tzcddshiren]

之前百度上看到可能是undo表空间 太小，现在让同事加到了一个T ,还是提示这个问题，这个程序它不是马上报错，它是运行几个小时后才提示的，这才是最烦的

[卖水果的net]

我建立的游标每次差不多300w提交一次、 你的代码中，没有看到 COMMIT 语句。

[tzcddshiren]

先感谢各位大佬回复，回复五楼 commit是在代码的最后啊，所有表的字段赋值之后再提交，我贴出来的只是代码的开头。回复6楼 我这个没有涉及到并发，我只是在做迁移数据这个工作，原来的业务还是在老表的基础上进行，等正式上线才会切换到新的这套数据表中，因此我迁移数据是不影响业务的，保留时间已经增大了一倍。回复 8,9 楼 undo表空间大小现在是一个T ，问题依旧没有解决，每次提交量降到60w左右，希望不要在报错了

[学海无涯-回头是岸]

你们的业务还在正常运作是吧? 试一下加并发，和增大默认的保留时间15分钟 到30或者更大试试

[minsic78]

查下几个东西：
1、你的undo表空间的大小；
2、查下实例参数undo_retention的值；
3、查下这个，UNDOTBS1请用你的UNDO表空间名来代替：

select tablespace_name,RETENTION from dba_tablespaces where tablespace_name='UNDOTBS1';

[minsic78]

另外，可以大致估算下你的300万数据占用空间的大小：
比如：20亿的那表空间大小可以这么来算，查询20亿表所在是数据库：select sum(bytes)/1024/1024/1024 from dba_segments where segment_name='20亿那张表的表名'; 300万数据大小：(3000000/2000000000)*刚刚那个sql查出来的大小

[学海无涯-回头是岸]

select中 可以加并发的。你如果用工具的话，就看工具有没有加并发的参数了。 你这种在线迁移还得考虑 迁移时间点的查询结果，和你后面新交易产生的增量问题。

[minsic78]

引用 10 楼 tzcddshiren 的回复:

先感谢各位大佬回复，回复五楼 commit是在代码的最后啊，所有表的字段赋值之后再提交，我贴出来的只是代码的开头。回复6楼 我这个没有涉及到并发，我只是在做迁移数据这个工作，原来的业务还是在老表的基础上进行，等正式上线才会切换到新的这套数据表中，因此我迁移数据是不影响业务的，保留时间已经增大了一倍。回复 8,9 楼 undo表空间大小现在是一个T ，问题依旧没有解决，每次提交量降到60w左右，希望不要在报错了

注意到你使用了dblink，报错的时候是不是还有dblink相关的错误？如果是，你的ORA-01555实际上是发生在源库的，而不是目标库，检查下源库undo相关的配置

[tzcddshiren]

回复11 楼 迁移数据不是直接从生产库取的数据，是先将生产库数据存入一个中间库（避免开库操作），然后再转的，所以其实不是在线迁移。 昨天减小提交量之后就没有报错了，看来的确是一次性提交数据量过大造成的。

[minsic78]

引用 13 楼 tzcddshiren 的回复:

回复11 楼 迁移数据不是直接从生产库取的数据，是先将生产库数据存入一个中间库（避免开库操作），然后再转的，所以其实不是在线迁移。 昨天减小提交量之后就没有报错了，看来的确是一次性提交数据量过大造成的。

如果是你说的这种流程，那么你的源库就是你说的中间库，这种中间库如果是临时搭建的话，那么undo配置有问题的可能性更高。
另外，如果你迁移个上百万数据就需要1T的unod，那么你十有八九触到BUG了

[tzcddshiren]

中间库的数据应该不会有问题，中间库的数据是从源表利用数据抽取工具直接抽取过来的，中间库不涉及undo表空间的问题。遇到bug的可能性也不大，通过查询转过来的表每秒数据确实是在几万几万的增加。我这个存储过程里面的逻辑相对是比较复杂的，好几个关系表，主键相互关联，根据业务逻辑1对多，甚至1对几百，所以我游标上面只有10000，但是我实际提交的几个表加起来就是几百w

[minsic78]

引用 15 楼 tzcddshiren 的回复:

中间库的数据应该不会有问题，中间库的数据是从源表利用数据抽取工具直接抽取过来的，中间库不涉及undo表空间的问题。遇到bug的可能性也不大，通过查询转过来的表每秒数据确实是在几万几万的增加。我这个存储过程里面的逻辑相对是比较复杂的，好几个关系表，主键相互关联，根据业务逻辑1对多，甚至1对几百，所以我游标上面只有10000，但是我实际提交的几个表加起来就是几百w

你之前贴的代码里可没什么复杂逻辑……
但就几百万数据的处理弄死1T undo，说明你的SQL要优化了