故障描述:与客户沟通,初步确认故障范围大概是在上午的8:30-10:30之间,反应故障现象是Tomcat的连接数满导致应用无法连接,数据库alert中无明显报错,需要协助排查原因. 1.导入包含故障时刻的数据 2.创建m_ash表,明确故障时刻 3.确定异常时刻的top n event 4.确定最终的top holder 5.总结 6.reference 1.导入包含故障时刻的数据 为了便于后续分析,我向客户索要了从昨天下午13:00到今天18:00的awrdump,导入到自己的实验环境进行分析…

上周二早上,收到项目组的一封邮件: 早上联代以下时间点用户有反馈EDI导入"假死",我们跟踪了EDI导入服务,服务是正常在跑,可能是处理的慢所以用户感觉是"假死"了,请帮忙从数据库中检查跟踪以下时间点是否有"异常"操作,多谢!         2012-11-20 9:10:10~~~~9:55:13,这个时间点内一共反馈了3次,大概是10~20分钟"假死"一次,请帮忙跟踪检查,多谢!         这是一套Windows…

enq: TX - row lock contention等待事件,这个是数据库里面一个比较常见的等待事件.enq是enqueue的缩写,它是一种保护共享资源的锁定机制,一个排队机制,先进先出(FIFO).enq: TX - row lock contention等待事件,OACLE将其归类为application级别的等待事件.有些场景是因为应用逻辑设计不合理造成的.下面我们看看enq: TX - row lock contention的英文介绍: This wait indicates ti…

enq是一种保护共享资源的锁定机制,一个排队机制 排它机制从一个事务的第一次改变直到rollback or commit 结束这个事务, TX等待mode是6,当一个session 在一个表的行级锁定时另一个会话总是等待,一般发生在一些用户insert or update,而另一个用户同样也在insert or update 这同一批数据时发生.这种类型的等待通常就是eventenq:TX-rowlockcontention.解决方法是让第一个会话commit or rollback 结束这个事…

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…

一个非常easy的问题,之所以让我对这个问题进行总结.一是由于没我想象的简单,在处理的过程中遇到了一些磕磕碰碰,甚至绕了一些弯路.二是引发了我对故障处理时的一些思考. 6月19日,下午5点左右.数据库出现了大量的enq: TX - row lock contention等待事件,依照以往的经验,这类等待一般与业务逻辑有关.DBA可以做的事情.一般就是将锁等待着的连接信息,等待锁的SQL语句.甚至等待的详细数据行,还有就是锁持有者的连接信息,造成锁等待的SQL语句等一些基本信息提交给开发者,改动业…

根据事后在虚拟机中复现客户现场发生的情况,做一次记录(简化部分过程,原理不变) 客户端1执行update语句 SQL> select * from test; ID NAME ---------- -------------------------------- b c b SQL where name = 'c'; row updated. 客户端2执行另外一条update语句 SQL where name = 'c'; 这个时候第二条update卡住了,证明发生了hanganalyze,查询…

公司用户反馈一系统在14:00~15:00(2016-08-16)这个时间段反应比较慢,于是生成了这个时间段的AWR报告, 如上所示,通过Elapsed Time和DB Time对比分析,可以看出在这段时间内服务器并不繁忙.分析Top 5 Timed Events,我们可以看到前五的等待事件 可以看到等待事件enq: TX - row lock contention占了所有等待事件17.3%的比例,猜测有可能是锁等待(enqueue等待)引起的阻塞导致,但是这个还不能下定论,因为毕竟CPU Ti…

今天要给一张日志表(6000w数据)建立索引,导致生产系统行锁部分功能卡住 create index idx_tb_cid on tb_login_log(user_id); 开始执行后大概花费了20分钟 中途功能卡住无法使用 SQL> select sid,event from v$session_wait where event='enq: TX - row lock contention'; SID EVENT ---------- ----------------------------…

enq: TX - row lock contention三个参数,例如,下面的等待事件 * P1 = name|mode          <<<<<<< name一般都为0x5458代表TX锁; mode为4代表共享锁 mode为6代表排他锁  * P2 = usn<<16 | slot      <<<<<<< v$transaction.xidusn  和 v$transaction.xidslot  …