10M这样一个语句：
UPDATE tabname a SET a.colx=NULL WHERE a.colx=‘0’;
colx的数据类型为VARCHAR2(32)；
tabname大小为13M，列一共100个，colx在90列的左右；表上的字段没有lob、long类型。colx列上没有索引；此表只有一个主键索引，在ID列。表总行数29944，colx='0’的行数为5000多。
select * from tabname where colx='0’的执行计划是走全表扫描的。
执行update时，经查询没有阻塞，等待事件为db file sequential read。因觉得这个表比较小，白天时执行了update，但执行了几分钟没执行完，就手动kill session了。晚上应用系统几乎没人使用时执行的update，半个小时都没有执行完，最后还是手动kill session了。
执行时undo的使用率很低，redo log几乎都是inactvie的。
请教专家们下，这个可能是什么原因导致的?或者需要做什么操作能确定为什么执行这么久都没执行完？要启用trace跟踪才能确定吗？
ctas当时做过了，执行update很快，几秒就完成了。
根据DBA_CONSTRAINTS这个查询没有外键。都是写check约束和一个主键，在ID列上。也没有其它表外键引用。
alert log里没有异常日志。
应该是触发器导致的，发现有个update before on tabname for each row.
多谢两位~
再请教下，这个更新慢，后来我根据ID更新，一次更新几十条，然后commit，这样不同样会触发那个触发器吗？几十条执行下来还是很快的，感觉时间差距很大，不过全部算下来两者时间说不定差不多。
评论
有用 0墨值悬赏