收到告警短信: BOMC一般告警,告警2次,最后告警时间:03-03 22:21,监控对象:/XX系统/数据库/ORACLE数据库/XXX.XX.XX.XX*XXXDB_LE_DBS/ORACLE实例/XXX.XX.XX.XX*XXXDB2_LE_DBS,告警内容:实时检查,ip:XXX.XX.XX.XX,程序长时间持有锁数量大于1,当前值为2[BOMC] 一般数据库存在锁为正常情况,也可判断为瞬时值,但是持续收到三次的告警信息,于是登录数据库检查一下情况. 检查数据库等待事件: 查看到涉及到相…

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

enq: TX - row lock contention等待事件,这个是数据库里面一个比较常见的等待事件.enq是enqueue的缩写,它是一种保护共享资源的锁定机制,一个排队机制,先进先出(FIFO).enq: TX - row lock contention等待事件,OACLE将其归类为application级别的等待事件.有些场景是因为应用逻辑设计不合理造成的.下面我们看看enq: TX - row lock contention的英文介绍: This wait indicates 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“等待事件的处理   session1: SQL> conn scott/triger Connected. SQL> CREATE TABLE tx_eg ( num number, txt varchar2(10), sex varchar2 (10) ) INITRANS 1 MAXTRANS 1; INSERT into tx_eg VALUES ( 1, 'First','FEMALE' ); INSERT into tx…

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

最近使用物化视图同步的环境在大量刷新的时候频繁出现enq: JI – contention等待事件,经查: JI enqueue is acquired in exclusive mode on the mview base (container) table when more than one session refresh the same materialzed view. It ensures that two or more refresh processes do not try…

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…

依据开发反馈.近期每天早上7:30应用会报警.应用的日志显示数据库连接池满了.新的连接被拒绝. 首先.我做了ASH报告(报告区间:7:25 ~ 7:35),从ASH的等待事件发现enq: TX - row lock contention竟然高达76.54%.例如以下所看到的: Top User Events Event Event Class % Event Avg Active Sessions enq: TX - row lock contention Application 76.54 0…

根据事后在虚拟机中复现客户现场发生的情况,做一次记录(简化部分过程,原理不变) 客户端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,查询…