AWR之-enq TX - row lock contention的性能故障-转
1 对这一个小时进行AWR的收集和分析,首先,从报告头中看到DB Time达到近500分钟,(DB Time)/Elapsed=8,这个比值偏高:
Snap Id |
Snap Time |
Sessions |
Cursors/Session |
|
Begin Snap: |
15142 |
20-11月-12 09:00:05 |
62 |
5.8 |
End Snap: |
15143 |
20-11月-12 10:00:56 |
74 |
8.3 |
Elapsed: |
60.85 (mins) |
|||
DB Time: |
492.88 (mins) |
2 再看TOP 5事件:
看到排在第一位的是enq: TX - row lock contention事件,也就是说系统中在这一个小时里产生了较为严重的行级锁等待事件。
Top 5 Timed Events
Event |
Waits |
Time(s) |
Avg Wait(ms) |
% Total Call Time |
Wait Class |
CPU time |
21,215 |
71.7 |
|||
enq: TX - row lock contention |
12,232 |
6,013 |
492 |
20.3 |
Application |
gc cr multi block request |
14,696,067 |
1,675 |
0 |
5.7 |
Cluster |
gc buffer busy |
441,472 |
719 |
2 |
2.4 |
Cluster |
db file sequential read |
4,191 |
25 |
6 |
.1 |
User I/O |
通常,产生enq: TX - row lock contention事件的原因有以下几种可能:
· 不同的session更新或删除同一条记录;
· 唯一索引有重复索引;
· 位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值;
· 并发的对同一个数据块上的数据进行update操作;
· 等待索引块完成分裂;
同时,从段的统计信息章节中,也看到下面的信息:
Segments by Row Lock Waits
· % of Capture shows % of row lock waits for each top segment compared
· with total row lock waits for all segments captured by the Snapshot
Owner |
Tablespace Name |
Object Name |
Subobject Name |
Obj. Type |
Row Lock Waits |
% of Capture |
SUNISCO |
SUNISCO_DATA1 |
BIND_PROCESS_LOG_REFNO |
INDEX |
159 |
67.66 |
|
SUNISCO |
FDN_EDI_I01 |
IDX_EDI_WORK_QUEUE_1 |
INDEX |
29 |
12.34 |
|
SUNISCO |
SUNISCO_DATA1 |
IND_EDI_CUSTOMER_TYPE_CODE |
INDEX |
15 |
6.38 |
|
SUNISCO |
SUNISCO_DATA1 |
IDX_EDI_MESSAGE_1 |
INDEX |
14 |
5.96 |
|
SUNISCO |
FDN_BASE_T01 |
BSE_NUM_LIST |
TABLE |
6 |
2.55 |
看到row lock waits发生在索引上。
3那么,究竟是什么操作导致了这个enq: TX - row lock contention等待事件呢? 查看系统中,当前有哪些会话产生了enq: TX - row lock contention等待事件?
1 2 3 4 5 6 7 8 9 10 |
|
看到SID为224,238,247,248,253的会话产生enq: TX - row lock contention等待事件。
4 查看系统中的当前会话,是在哪个对象上产生了产生了enq: TX - row lock contention等待事件?
1 2 3 4 5 6 7 8 9 10 11 12 13 |
|
5 那么这个数据库对象为369195的对象究竟是什么呢?
1 2 3 4 5 6 7 8 9 10 11 |
|
可以看到,定位到的结果同上述AWR报告中段统计信息吻合,是SUNISCO这个用户下的一个索引。
6接下来,继续看看SID为224,238,247,248,253的会话到底在执行哪些操作导致enq: TX - row lock contention等待事件?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 1 |
|
看到有SQL_ID不同的SQL在同时向EDI_MESSAGE_PROCESS_LOG这张表执行INSERT操作。
7 接下去看看EDI_MESSAGE_PROCESS_LOG这张表和索引BIND_PROCESS_LOG_REFNO之间有没有什么关系?
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 |
|
发现,这个索引BIND_PROCESS_LOG_REFNO是位于EDI_MESSAGE_PROCESS_LOG这张表的REFNO字段上的一个位图索引,而且是2012/11/05 10:18:28创建的,也就是说是近期才创建的1个位图索引。
问题定位到这一步基本比较清晰了,产生enq: TX - row lock contention事件的原因就是上述的第2个可能原因:位图索引同时被更新或同时并发的向位图索引字段上插入相同字段值。
8 那么,解决的办法也比较简单了,就是干掉这个位图索引,因为这个位图索引在这种应用场景下确实不太适合。事后,经过同客户方沟通确认,该索引是他们的一个DBA当初看到系统比较慢,而加上去的一个位图索引。
9补充,从当时的ADDM报告中,也可以看到数据库给我们的建议:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 |
|
10 最后,从本案例中,可以看到在日常的数据库维护中,添加或修改一些对象信息时,务必要经过严格的测试,尤其是在生产系统上做调整更应如此。同样,可以看出,数据库的一些理论基础知识对于DBA还是蛮重要的。
AWR之-enq TX - row lock contention的性能故障-转的更多相关文章
- 解决一则enq: TX – row lock contention的性能故障
上周二早上,收到项目组的一封邮件: 早上联代以下时间点用户有反馈EDI导入"假死",我们跟踪了EDI导入服务,服务是正常在跑,可能是处理的慢所以用户感觉是"假死" ...
- ORACLE AWR结合ASH诊断分析enq: TX - row lock contention
公司用户反馈一系统在14:00~15:00(2016-08-16)这个时间段反应比较慢,于是生成了这个时间段的AWR报告, 如上所示,通过Elapsed Time和DB Time对比分析,可以看出在这 ...
- ORACLE等待事件:enq: TX - row lock contention
enq: TX - row lock contention等待事件,这个是数据库里面一个比较常见的等待事件.enq是enqueue的缩写,它是一种保护共享资源的锁定机制,一个排队机制,先进先出(FIF ...
- 记录一则enq: TX - row lock contention的分析过程
故障描述:与客户沟通,初步确认故障范围大概是在上午的8:30-10:30之间,反应故障现象是Tomcat的连接数满导致应用无法连接,数据库alert中无明显报错,需要协助排查原因. 1.导入包含故障时 ...
- Tuning “enq:TX – row lock contention” events
enq是一种保护共享资源的锁定机制,一个排队机制 排它机制从一个事务的第一次改变直到rollback or commit 结束这个事务, TX等待mode是6,当一个session 在一个表的行级锁定 ...
- 大表建立索引引发enq: TX - row lock contention等待
今天要给一张日志表(6000w数据)建立索引,导致生产系统行锁部分功能卡住 create index idx_tb_cid on tb_login_log(user_id); 开始执行后大概花费了20 ...
- enq: TX - row lock contention 参数P1,P2,P3说明
enq: TX - row lock contention三个参数,例如,下面的等待事件 * P1 = name|mode <<<<<<< ...
- [Oracle] enq: TX - row lock contention 优化案例
依据开发反馈.近期每天早上7:30应用会报警.应用的日志显示数据库连接池满了.新的连接被拒绝. 首先.我做了ASH报告(报告区间:7:25 ~ 7:35),从ASH的等待事件发现enq: TX - r ...
- enq: TX - row lock contention“等待事件的处理
enq: TX - row lock contention“等待事件的处理 session1: SQL> conn scott/triger Connected. SQL> CRE ...
随机推荐
- jquery中判断选择器,找没找到元素用$().size()==0
jquery中判断选择器,找没找到元素用$().size()==0
- UGUI之Canvas Group
可以通过Canvas Group影响该组UI元素的部分性质,而不需要费力的对该组UI下的每个元素逐个调整.Canvas Group是同时作用于该组UI下的全部元素. 参数:Alpha:该组UI元素的透 ...
- Unity3D工程源码目录
2-0 暗黑破坏神3 链接:http://pan.baidu.com/s/1dEAUZoX 密码:cly4 2-1 炉石传说 客户端加服务器端 链接:http://pan.baidu.co ...
- spring配置文件中bean标签
<bean id="beanId"(1) name="beanName"(2) class="beanClass"(3) parent ...
- c#接口作为参数传递、返回
接口做为参数传递,传递的是实现了接口的对象: 接口作为类型返回,返回的是实现了接口的对象. 接口的传递与返回就是围绕着上面的两句话展开的.
- CUGBACM Codeforces Tranning 1 题解
链接:http://acm.hust.edu.cn/vjudge/contest/view.action?cid=61581#overview 描写叙述:非常老的CF题,题不错,拿来训练正好. 做的时 ...
- 使用select多选标签笔记
之前一直用checkbox做多选,其实 select也可以多选,只要多给一个属性即可.标签属性 http://www.w3school.com.cn/tags/att_select_multiple. ...
- linux 添加交换分区
[操作简介] 增加swap分区方法: 1.新建磁盘分区作为swap分区 2.用文件作为swap分区 (操作更简单,我更常用) 下面介绍这两种方法:(都必须用root权限,操作过程应该小心谨慎.) ...
- hive与hbase的联系与区别
hive与hbase的联系与区别: 共同点: 1.hbase与hive都是架构在hadoop之上的.都是用hadoop作为底层存储. 他们的底层是要通过mapreduce分布式计算的,hbase.hi ...
- C#中的抽象类与重写
今天的我们学习了好多,最初上午学习了文件流的方法,老师告诉我们是选修,可能以后不怎么用吧,但是还是想学下,似乎用个小程序读写文件很快地节奏,所以有点小兴趣学习,明天我再看看啦!今天之后学习了多态,继承 ...