在对指定表做append *** 作,其他再做truncate时候,会产生锁表,如下验证步骤,
1、创建测试表,
create table test_lock(id number, value varchar2(200))
2、执行append语句;并且不做提交,insert /*+append*/ into test_lock values(1,1)
3、再次执行清表语句,truncate table test_lock报锁表错误,
4、查看锁表语句,发现被锁表,
select b.object_name, t.*
from v$locked_object t, user_objects b
where t.object_id = b.object_id
根据我之前接触到的此类问题,大致可以分为以下几种原因:1. 程序中非数据库交互 *** 作导致事务挂起
将接口调用或者文件 *** 作等这一类非数据库交互 *** 作嵌入在 SQL 事务代码之中,那么整个事务很有可能因此挂起(接口不通等待超时或是上传下载大附件)。
2. 事务中包含性能较差的查询 SQL
事务中存在慢查询,导致同一个事务中的其他 DML 无法及时释放占用的行锁,引起行锁等待。
3. 单个事务中包含大量 SQL
通常是由于在事务代码中加入 for 循环导致,虽然单个 SQL 运行很快,但是 SQL 数量一大,事务就会很慢。
4. 级联更新 SQL 执行时间较久
这类 SQL 容易让人产生错觉,例如:update A set ... where ...in (select B) 这类级联更新,不仅会占用 A 表上的行锁,也会占用 B 表上的行锁,当 SQL 执行较久时,很容易引起 B 表上的行锁等待。
5. 磁盘问题导致的事务挂起
极少出现的情形,比如存储突然离线,SQL 执行会卡在内核调用磁盘的步骤上,一直等待,事务无法提交。
综上可以看出,如果事务长时间未提交,且事务中包含了 DML *** 作,那么就有可能产生行锁等待,引起报错。
欢迎分享,转载请注明来源:内存溢出
评论列表(0条)