解决项目中主键重复无法插入数据的问题

出现此问题是由于这样：表中之前有一些插入的数据，后期经别人导入数据，再次导入数据时出现如下问题：[img]http://dl.iteye.com/upload/picture/pic/69756/b3bc6f5a-6825-3d28-8f0a-d2dc80884489.jpg[/img]。
初步分析，是由于导入数据时，导入了自增的id，而数据库中自增的id始终停留在原始的那个值。印象中，小李同学曾经解决过此问题，是将开始自增的值由现在最大的值+1，即可解决。但苦于自己不是专业的数据库人员，也没有系统学习过这方面的知识。于是，先找了邱同学帮我解决。首先确定了确实是由于上述的情况造成的，则修改了表结构中自增字段的最小开始值，生成代码，然后开始commit。发现此处需要将数据先备份出来，然后再插入数据，才能解决此问题。如果数据库中数据量不大的情况下，这种解决办法还是可以的。但数据量大的情况下，光是导入数据就会很长时间。看来这不是最好的解决办法。于是乎，让系统慢慢的导数据。另外思考，db2应该会提供这种修改自增值开始的方法。于是我们继续查询资料。
经查找，找到如下资料：
[color=red] 对于自增序列(GENERATED by default）
　　GENERATED by default可以直接通过一般的导入方式加载数据，不过有时候会有一点点小问题，自增序列没有进行分配，也就是说，原来表有50条记录，自增序列的下一次分配值为50，当你已经导入了1000条记录进去了，然后发现自增序列的下一次分配值还是为50，这种事不经常发生，但是偶尔会发生一次，比较郁闷的是，当表继续插入数据的时候，下一次分配就会发生冲突，尤其是如果自增建为主键的时候，会违反唯一约束。

　　解决办法：首先找到这个序列分配的最大值，select max(id) from tablea;

　　然后用下边这个命令，alter table tablea alter column restart with max(id)+1[/color]
哈哈，终于找到这种解决办法。速度应该会比上一种解决办法快很对了吧。至少不用再次的插入数据。于是在下一张表中再次出现此问题时，使用如下的sql语句，“alter table QUESTIONNAIRE_RUBRIC_CL1 alter column RUBRIC_INST_ID SET GENERATED ALWAYS restart with 210;”，此语句一执行，那个速度真是超赞哦。看来以后再出现此种情况，就照此方法解决了。
另外，在测试自增id是否连续自增时，发现id虽然是顺序自增，但会出现不连续的情况。经邱同学研究，发现建表时，使用了cache。