Académique Documents
Professionnel Documents
Culture Documents
in Oracle 11g
Blocking sessions occur when one sessions holds an exclusive lock on an object and
doesn't release it before another sessions wants to update the same data. This will
block the second until the first one has done its work. It mainly happens when a session
issues an insert, update or delete command that changes a row. When the change
occurs, the row is locked until the session either commits the change or rolls the change
back.
From the view of the user it will look like the application completely hangs while waiting
for the first session to release its lock. You'll often have to identify these sessions in
order to improve your application to avoid as many blocking locks as possible.
.You can see where problems might occur, for example a user might make a change
and then forget to commit it and leaves for the weekend without logging off the system.
Oracle provide views like, DBA_BLOCKERS and V$LOCK using which we can easily
find the blocking locks. Here, we will try to find blocking locks using V$LOCK view which
is faster to query and makes it easy to identify the blocking session.
SQL> select * from v$lock ;
ADDR KADDR
SID TY
ID1
ID2
LMODE REQUEST
BLOCK
-------- -------- ---------- -- ---------- ---------- ---------- ---------- ---------------------------------------------AF8E2C4C AF9E2C50
419 TX 141028
15289
0
6
0
ADDF7EC8 ADDF8EE0 542 TM 77529
0
3
0
0
ADDF7F74 ADDF7F8C 419 TM 77529
0
3
0
CTIME
675
687
675
0
ADEBEA20 ADEBEB4C 542 TX
1
141028
152899
687
Here we are interested in the BLOCK column. If a session holds a lock that's blocking
another session, BLOCK=1. Further, you can tell which session is being blocked by
comparing the values in ID1 and ID2. The blocked session will have the same values in
ID1 and ID2 as the blocking session, and, since it is requesting a lock it's unable to get,
it will have REQUEST > 0.
In the query above, we can see that SID 542 is blocking SID 419. SID 542 corresponds
to Session 1 in our example, and SID 419 is our blocked Session 2. To avoid having to
stare at the table and cross-compare ID1's and ID2's, put this in a query:
Query to find Blocking sessions using v$lock
SQL> select l1.inst_id,l1.sid, ' IS BLOCKING ',
l2.sid,l1.type,l2.type,l1.lmode,l2.lmode,l2.inst_id
from gv$lock l1, gv$lock l2
where l1.block =1 and l2.request > 0
and l1.id1=l2.id1
and l1.id2=l2.id2;
l2.id2 = l2.id2 ;
externally.
Identify the Session to be Killed
ALTER SYSTEM KILL SESSION
ALTER SYSTEM DISCONNECT SESSION
The Windows Approach
The UNIX Approach
SQL> ALTER SYSTEM KILL SESSION 'sid,serial#' IMMEDIATE;
This does not affect the work performed by the command, but it returns control back to
the current session immediately, rather than waiting for confirmation of the kill.
In a RAC environment, you optionally specify the INST_ID, shown when querying the
GV$SESSION view. This allows you to kill a session on different RAC node.
SQL> ALTER SYSTEM KILL SESSION 'sid,serial#,@inst_id';
SQL> ALTER SYSTEM DISCONNECT SESSION 'SID,SERIAL#' IMMEDIATE;
The DISCONNECT SESSION command kills the dedicated server process, which is
equivalent to killing the server process from the operating system
kill -9 spid
To identifying blocked objects
The view v$lock we've already used in the queries above exposes even more
information. There are differnet kind of locks - check this site for a complete list:
http://download.oracle.com/docs/cd/B13789_01/server.101/b10755/dynviews_1123.htm
#sthref3198
If you encounter a TM lock is means that two sessions are trying to modify some data
but blocking each other. Unless one sessions finished (commit or rollback), you'll never
have to wait forever.
The following queries shows you all the TM locks: