1、阻塞及其类型
a、什么是阻塞
一个会话持有某个资源的锁,而另一个会话在请求这个资源,就会出现阻塞(blocking)。也就是说新的会话会被挂起,直到持有锁的会话放弃锁定的资源。大多数情况下,在一个交互式应用中被严重阻塞,即可表明应用逻辑有问题,这才是阻塞的根源。
b、阻塞得类型
数据库中有5条常见的DML语句可能会阻塞,即:INSERT、UPDATE、DELETE、MERGE 和SELECT FOR UPDATE。
2、几种不同类型阻塞的处理办法
a、INSERT阻塞主要是由于有一个带主键的表,或者表上有惟一的约束,在两个会话试图用同样的值插入一行时引发阻塞。多表通过引用完整性约束相互链接时,在其依赖的父表正在创建或删除期间,对子表的插入可能会阻塞。对于该类情形建议使用序列来生成主键/惟一列值。
b、对于UPDATE、DELETE、MERGE 和SELECT FOR UPDATE阻塞,只要有任一session使用这些操作已经锁定行,其余的必须处于等待状态。直到当前锁定行上的锁(排他锁)释放。对于该类情形,建议尽可能快速提交事务,或采用批量SQL方式提交。
c、对于一个阻塞的SELECT FOR UPDATE,解决方案很简单:只需增加NOWAIT 子句,它就不会阻塞了。
3、演示阻塞--更新表,注,提示符scott@CNMMBO表明用户为scott的session,用户名不同,session不同。
scott@CNMMBO> update emp set sal=sal*1.1 where empno=7788;
1 row updated.
scott@CNMMBO> @my_env
SPID SID SERIAL# USERNAME PROGRAM
------------ ---------- ---------- --------------- ------------------------------------------------
11205 1073 4642 robin oracle@SZDB (TNS V1-V3)
--另起两个session更新同样的行,这两个session都会处于等待,直到第一个session提交或回滚
leshami@CNMMBO> update scott.emp set sal=sal+100 where empno=7788;
goex_admin@CNMMBO> update scott.emp set sal=sal-50 where empno=7788;
--下面在第一个session 查询阻塞情况
scott@CNMMBO> @blocker
BLOCK_MSG BLOCK
-------------------------------------------------- ----------
pts/5 ('1073,4642') is blocking 1067,10438 1
pts/5 ('1073,4642') is blocking 1065,4464 1
--上面的结果表明session 1073,4642 阻塞了后面的2个
--即session 1073,4642是阻塞者,后面2个session是被阻塞者
--下面查询正在阻塞的session id,SQL语句以及被阻塞的时间
scott@CNMMBO> @blocking_session_detail.sql
'SID=' A.SID 'WAITCLASS=' A.WAIT_CLASS 'TIME=' A.SECONDS_IN_WAIT CHR(10) 'QUERY=' B.SQL_TEXT
-------------------------------------------------------------------------------------------------------
sid=1067 Wait Class=Application Time=5995
Query=update scott.emp set sal=sal+100 where empno=7788
sid=1065 Wait Class=Application Time=225
Query=update scott.emp set sal=sal-50 where empno=7788
--下面的查询阻塞时锁的持有情况
scott@CNMMBO> @request_lock_type
USERNAME SID TY LMODE REQUEST ID1 ID2
------------------------------ ---------- -- ----------- ----------- ---------- ----------
SCOTT 1073 TX Exclusive None 524319 27412
LESHAMI 1067 TX None Exclusive 524319 27412
GOEX_ADMIN 1065 TX None Exclusive 524319 27412
--可以看到LESHAMI,GOEX_ADMIN 2个用户都在请求524319/27412上的Exclusive锁,而此时已经被SCOTT加了Exclusive锁
--查询阻塞时锁的持有详细信息
scott@CNMMBO> @request_lock_detail
SID USERNAME OSUSER TERMINAL OBJECT_NAME TY Lock Mode Req_Mode
---------- -------------------- --------------- ------------------------- -------------------- -- ----------- --------------------
1065 GOEX_ADMIN robin pts/1 EMP TM Row Excl
1065 GOEX_ADMIN robin pts/1 Trans-524319 TX --Waiting-- Exclusive
1067 LESHAMI robin pts/0 EMP TM Row Excl
1067 LESHAMI robin pts/0 Trans-524319 TX --Waiting-- Exclusive
1073 SCOTT robin pts/5 EMP TM Row Excl
1073 SCOTT robin pts/5 Trans-524319 TX Exclusive
--转自