3,491
社区成员
发帖
与我相关
我的任务
分享引起enq: TM – contention等待事件原因有哪些
外键没建索引的不考虑，最近我就遇到这么一个问题：
生产环境很多session的等待事件为：enq: TM – contention，被阻塞的sql都为update 表A，通过v$session找出block_session，其正在执行的sql为update 表B，再
通过v$lock发现block_session对表A持有了级别为6的TM锁，导致其他session想要更新表A时都只能等待。可以肯定的是表A和表B在这期间都没有DDL操作。而且block_session
刚刚对表A有大数据量的插入，已知条件就这么多。请大家帮忙看下
生产环境很多session的等待事件为：enq: TM – contention，被阻塞的sql都为update 表A，通过v$session找出block_session，其正在执行的sql为update 表B，再
通过v$lock发现block_session对表A持有了级别为6的TM锁，导致其他session想要更新表A时都只能等待。可以肯定的是表A和表B在这期间都没有DDL操作。而且block_session
刚刚对表A有大数据量的插入，已知条件就这么多。请大家帮忙看下
...全文
请发表友善的回复…
发表回复
luckman100 2014-10-23
- 打赏
- 举报
表上只建了一般索引和唯一索引
还提供个线索:这个问题每次发生都是在表A大数据量更新，而且是循环更新，耗时很长的情况下
还提供个线索:这个问题每次发生都是在表A大数据量更新，而且是循环更新，耗时很长的情况下
不写代码的钦 2014-10-23
- 打赏
- 举报
表A上没有任何外键，[/quote]
那是不是A表上建了不合理的索引（比如oltp系统里面建了bitmap索引，很容易
引起大片数据更新插入死锁），导致update的时候引起锁。
bw555 2014-10-22
- 打赏
- 举报
7.1.4 执行direct/parallel load工作时
insert/*+*append/ into或sql*loader的direct path load之类的部分功能，对于相应表以exclusive模式获得tm锁，direct load
工作不经过sga,而是直接写入到数据文件里，所以在执行工作期间不运行对表进行任何修改。得到保障，工作才能得以继续。
direct load工作在执行期间，不运行对于表执行任何DDL或DML.因此事务多的时刻执行direct load工作时，需要确认TM锁
争用是否可能引发的问题。
bw555 2014-10-22
- 打赏
- 举报
根据你的描述，不考虑状况1，没有状况2，状况3可能性也不是很大，重点检查状况4的情况有没有吧
bw555 2014-10-22
- 打赏
- 举报
enq:TM-contention等待的发生，发生TM锁争用的情况如下：
1、修改无索引外键(foreign key)的父键时
2、DML与DDL之间的TM争用
3、LOCK TABLE 引起的TM锁争用
4、direct load工作引起的TM锁争用
http://blog.itpub.net/7194105/viewspace-704114/
luckman100 2014-10-22
- 打赏
- 举报
表A上没有任何外键，
luckman100 2014-10-22
- 打赏
- 举报
补充一下，程序也没有用到并行度
luckman100 2014-10-22
- 打赏
- 举报
这种情况我也知道会引发TM等待，但是程序里面并没有用/*+append*/这样的hint呀，还有其他可能性导致直接加载数据吗？？
wangwei 2014-10-22
- 打赏
- 举报
当Oracle 执行DML语句时，系统自动在所要操作的表上申请TM类型的锁。当TM锁获得后，系统再自动申请TX类型的锁,楼上bw55兄弟所说的/*+*append/加载或者直接路径加载会在表上以exclusive模式获得tm锁，那么你在update在获取TM锁的时候就需要等待了。就出现了enq: TM – contention事件
bw555 2014-10-22
- 打赏
- 举报
应该是楼主的表没有外键吧，或是已经建好了索引了
不写代码的钦 2014-10-22
- 打赏
- 举报
我还是想弱弱地问一句，为什么不考虑索引情况，最优可能的呀
