我得到了一个带有自动增量列的表,它看起来像:
ALTER TABLE SOMESCHEMA.SOMETABLE
ALTER COLUMN ID
SET DATA TYPE INTEGER GENERATED BY DEFAULT
SET INCREMENT BY 1
SET NO ORDER
SET NO CYCLE
SET MINVALUE 1
SET MAXVALUE 2147483647
SET NO CACHE;只要我让DBMS生成Id,一切都可以正常工作,我可以通过以下方法获得生成的Id:
SELECT IDENTITY_VAL_LOCAL() FROM sysibm.sysdummy1但有时,我需要插入一行我选择的ID,在那里,我陷入了麻烦。
假设我们在表中有一个ID为1的行。
现在,我插入一个新行,它的手动分配id为2。
下一次尝试插入一个没有预设ID的新行时,我会得到一个错误SQL0803“复制键”。
假设自动增量列的内部"NextId“字段不更新自己,如果行的Id是手动设置的。
所以我试着用:
ALTER TABLE SOMESCHEMA.SOMETABLE ALTER COLUMN ID RESTART WITH 3但这会导致永久表锁,我不知道如何解锁。
我怎样才能让这个“混合模式”ID列工作?它是否有可能像MySQL那样工作,其中DBMS在手动Id插入时自动更新"NextID“?如果不是,如果我试图重置NextId,如何释放{insert -起誓-word}锁?
发布于 2013-11-26 17:45:44
SQL0913不是在创建锁,而是报告存在一个锁。ALTER需要表上的独占锁才能重置ID号。一个表可以被打开的另一个进程锁定,如果有未提交的行,它也可以被这个进程锁定。
使用该表的另一个原因是软关闭(或伪关闭)。出于性能原因,DB2 For I将游标保存在内存中,以便尽可能有效地重用游标。因此,即使您说关闭游标,DB2也会将其保存在内存中。这些软关闭游标可以通过命令ALCOBJ OBJ((SOMSCHEMA/SOMETABLE *FILE *EXCL)) WAIT(1) CONFLICT(*RQSRLS)关闭,冲突(*RQSRLS)参数告诉DB2关闭所有软关闭游标。
因此,问题的根源在于DB2希望对表进行独占访问。这是一个设计问题,因为通常一个人在工作日不会操纵表格的结构。听起来这个表有时是父表,有时是子表,当涉及到ID号时。如果是这样的话,我可以建议你再换一次桌子吗?
我认为如果使用触发器而不是自动增量,实现可能会更好。在插入时启动触发器。如果提供了ID,则什么也不做。如果没有提供ID,则选择MAX( ID )+1,并将其用作提交给数据库的实际ID号。
发布于 2016-04-13 13:35:05
ALTER TABLE table_name ALTER COLUMN column_name RESTART WITH 99999;解决了我的问题。例如,"99999“是下一个要使用的ID。
https://stackoverflow.com/questions/20190220
复制相似问题