一个比较妖的表锁定问题

ShineCQY

  环境：oracle 11.2.0.3 for RHEL 5.5 X64
  table:1600W行左右数据，无任何约束和索引。
故障现象：应用程序跑任务的时候已经持续了4个小时，以前只需15分钟，貌似永远跑不完。同事查询了一下发表现有锁定，于是乎开始 alter system kill session ' ' immediate;然后接着就报错 ORA-00031:session marked for kill 。让我这个dba来搞定，我并没有什么高明的方法:操作系统中kill -9 。但是在系统中kill 掉进程后并没有解决问题（会生成另外一个session同样是锁定）。由于应用重启后有可能起不来，所以重启了数据库，最后问题解决。
  为了解决表锁定竟然重启了数据库，我觉得自己不是一个合格的dba，肯定是没有摸清楚根本原因。
  请大师们帮忙看下。谢谢。
  再次说明下我的问题和疑问：
  1、为了kill -9 解决了锁定的session 但是马上又出来 被锁定的session？比如发现sid为1180 kill 掉后重新出现sid 1182锁定。
  2、表并没有 主键 唯一约束 唯一索引等，insert into 语句能造成锁定吗？
  3、此锁定是应用造成的，但是应用只会对该表做insert into 操作，有什么改进的方法？
备注：附件中为，AWR\ASH\表锁定信息查询

lock.zip (59.31 KB, 下载次数: 897)

2013-4-25 10:46 上传

点击文件名下载附件

  

laobu

有锁被持有，不一定是问题吧，有人等这个锁才是问题
而且，能确认当时等待的就是这个锁吗

Maclean Liu(刘相兵

对这种问题 AWR 没有太大的用处

enq: TX - contention        5        61        12132        1.49        Other

并不是 行锁 后者 index contention

ShineCQY

老大，为什么kill 掉sid后，马上又出来一个锁定的sid ? 还有，为什么会有index contention ，这与索引有关系吗？表上是没有索引的。

repentance

从你的lock info中没看到数据库中有锁请求不到的情况，没有会话被阻塞。
再出现情况，使用下面SQL查询一下
SELECT /*+rule*/
B.INST_ID, L.SID, L.TYPE, L.ID1, L.ID2, L.LMODE, L.REQUEST, L.BLOCK,
L.CTIME, C.SQL_ID, B.USERNAME, B.MACHINE, B.TERMINAL, B.PROGRAM, B.EVENT,
B.OSUSER, B.INST_ID
        FROM GV$LOCK L, GV$SESSION B, GV$PROCESS E, GV$SQLSTATS C
WHERE (L.ID1, L.ID2, L.TYPE) IN
                         (SELECT /*+unnest*/
                                 D.ID1, D.ID2, D.TYPE
                                        FROM GV$LOCK D
                                 WHERE D.REQUEST > 0)
         AND L.SID = B.SID
         AND L.INST_ID = B.INST_ID
         AND B.INST_ID = E.INST_ID
         AND B.PADDR = E.ADDR
         AND B.INST_ID = C.INST_ID(+)
         AND B.SQL_ID = C.SQL_ID(+)
ORDER BY L.ID1, L.ID2, L.REQUEST

wqqzlm

学习了。

knowwinter

你要找出持有锁的那个session 要把那个干掉  你干掉那些等待者有啥用