共计 2704 个字符,预计需要花费 7 分钟才能阅读完成。
这篇文章主要介绍了 LOCK 中如何实现模拟锁等待现象,具有一定借鉴价值,感兴趣的朋友可以参考下,希望大家阅读完这篇文章之后大有收获,下面让丸趣 TV 小编带着大家一起了解一下。
1. 模拟“锁等待”现象
1)开启一个终端创建测试表 test_lock,插入一条数据,模拟更新该条数据,但不提交
sys@orcl conn sec/sec
Connected.
sec@orcl create table test_lock (a int);
Table created.
sec@orcl insert into test_lock values (1);
1 row created.
sec@orcl commit;
Commit complete.
sec@orcl select * from test_lock;
A
———-
1
sec@orcl update test_lock set a = 2;
1 row updated.
2)再另外开启一个终端,对同样的行进行另外的更新,随即出现锁等待的现象
sys@orcl conn sec/sec
Connected.
sec@orcl
sec@orcl
sec@orcl update test_lock set a = 3;
因为更新都是 test_lock 表中 1 这行的记录,第一个用户提交了修改但是没有提交,在这里会出现无法继续执行的现象,这种现象就是“锁等待”,千万不要再说这个现象是“死锁”啦,“死锁”Oracle 是会自己处理的,有兴趣的朋友可以查询死锁产生的四个条件,我们这个实验只是讨论最容易出现的“锁等待”现象的处理方法。
2. 检测“锁等待”方法
sys@orcl @lock
lock lock
holder holder lock lock request blocked
username session id SERIAL# type id1 id2 mode mode BLOCK session id
—————— ———– ———- —— ———– ———– ——— ——— ———- ———-
SEC 148 23007 TM 303038 0 3 0 0
SEC 153 18219 TM 303038 0 3 0 0
SEC 153 18219 TX 262159 306200 6 0 1 148
165 1 TS 3 1 3 0 0
166 1 CF 0 0 2 0 0
166 1 RS 25 1 2 0 0
166 1 XR 4 0 1 0 0
167 1 RT 1 0 6 0 0
8 rows selected.
通过上面脚本的执行可以清楚的看出,首先,存在锁等待现象,因为最后一列存在不为空的会话 id 信息,其次,可以通过上面所列出来的锁的信息判断出因为 153 会话中执行的 SQL 语句导致 148 会话的 SQL 语句无法执行。
3.“锁等待”处理方法
1)温柔方法
通过个人魅力找到 153 会话操作的弟兄,温柔的提醒他请将未提交的 SQL 语句做提交或回滚处理,以便释放相应的行级锁。
2)暴力方法
直接杀死 153 会话,方法如下:
sys@orcl alter system kill session 153,18219
System altered.
到此,向你抱怨长时间未运行完成的 SQL 语句神奇般的恢复了本应有的速度。
4.OK,是该隆重推出我用来检测“锁等待”的脚本的时候了,大家请看
—————————————————
— Script. Function: Query the lock info —
— Script. Name: lock.sql —
— Author: secooler —
— Date: 2008.3.6 —
—————————————————
set pages 1000 lin 126
col kaddr heading lock|address
col username heading lock|holder|username for a18
col sid heading lock|holder|session id format 9999999999
col type heading lock|type format a6
col id1 heading id1 format 9999999999
col id2 heading id2 format 9999999999
col lmode heading lock|mode format 99999999
col request heading request|mode format 99999999
col blocking_sid format 999999 heading blocked|session id
select /*+rule*/
— a.kaddr, —
(select username from v$session where sid = a.sid) username,
a.sid,
(select serial# from v$session where sid = a.sid) serial#,
— (select ctime from v$lock where KADDR = a.kaddr) ctime, —
a.type,
a.id1,
a.id2,
a.lmode,
a.request,
a.block,
b.sid blocking_sid
from v$lock a,
(select * from v$lock
where request 0
and type MR
) b
where a.id1 = b.id1(+)
and a.id2 = b.id2(+)
and a.lmode 0
and a.type MR
order by username,a.sid,serial#,a.type
/
column sid clear
column type clear
column request clear
column username clear
5. 总结
“锁等待”现象是一种常见的数据库问题,往往出现在多人(往往是技术支持人员)同时操作数据库的时候。在出现此类问题的时候,要沉着、认真、快速、准确的定位问题,排除故障。当然如果能采用非常严格的数据库操作制度以便防止此类问题的发生的话,那是最好不过的了,所以说七分管理三分处理。
好运!
感谢你能够认真阅读完这篇文章,希望丸趣 TV 小编分享的“LOCK 中如何实现模拟锁等待现象”这篇文章对大家有帮助,同时也希望大家多多支持丸趣 TV,关注丸趣 TV 行业资讯频道,更多相关知识等着你来学习!