Database Reference
In-Depth Information
We're now blocked in this session. If we run the
V$
queries again, we see the following:
EODA@ORA12CR1> select username,
2 v$lock.sid,
3 trunc(id1/power(2,16)) rbs,
4 bitand(id1,to_number('ffff','xxxx'))+0 slot,
5 id2 seq,
6 lmode,
7 request
8 from v$lock, v$session
9 where v$lock.type = 'TX'
10 and v$lock.sid = v$session.sid
11 and v$session.username = USER;
USERNAME SID RBS SLOT SEQ LMODE REQUEST
--------------- ---------- ---------- ---------- ---------- ---------- ----------
EODA 17 2 27 21201 0 6
EODA 22 2 27 21201 6 0
EODA 17 8 17 21403 6 0
EODA@ORA12CR1> select XIDUSN, XIDSLOT, XIDSQN from v$transaction;
XIDUSN XIDSLOT XIDSQN
---------- ---------- ----------
2 27 21201
8 17 21403
What we see here is that a new transaction has begun, with a transaction ID of (8,17,21403). Our new session,
SID=17
, has two rows in
V$LOCK
this time. One row represents the locks that it owns (where
LMODE=6
). It also has a
row that shows a
REQUEST
with a value of 6. This is a request for an exclusive lock. The interesting thing to note here is
that the
RBS/SLOT/SEQ
values of this request row are the transaction ID of the
holder
of the lock. The transaction with
SID=22 is blocking the transaction with SID=17. We can see this more explicitly simply by doing a self-join of
V$LOCK
:
EODA@ORA12CR1> select
2 (select username from v$session where sid=a.sid) blocker,
3 a.sid,
4 ' is blocking ',
5 (select username from v$session where sid=b.sid) blockee,
6 b.sid
7 from v$lock a, v$lock b
8 where a.block = 1
9 and b.request > 0
10 and a.id1 = b.id1
11 and a.id2 = b.id2;
BLOCKER SID 'ISBLOCKING' BLOCKEE SID
--------------- ---------- ------------- --------------- ----------
EODA 22 is blocking EODA 17
Search WWH ::
Custom Search