Apress.Expert.Oracle.Database.Architecture.9i.and.10g.Programming.Techniques.and.Solutions.Sep.2005

CHAPTER 6 ■ LOCKING AND LATCHING 211
Here is a small example showing how this happens, using three V$ tables:
• V$TRANSACTION, which contains an entry for every active transaction.
• V$SESSION, which shows us the sessions logged in.
• V$LOCK, which contains an entry for all enqueue locks being held as well as for sessions
that are waiting on locks. You will not see a row in this view for each row locked in this
table by a session. As stated earlier, that master list of locks at the row level doesn’t exist.
If a session has one row in the EMP table locked, there will be one row in this view for
that session indicating that fact. If a session has millions of rows in the EMP table locked,
there will still be just one row in this view. This view shows what enqueue locks individual
sessions have.
First, let’s start a transaction (if you don’t have a copy of the DEPT table, simply make one
using a CREATE TABLE AS SELECT):
ops$tkyte@ORA10G> update dept set deptno = deptno+10;
4 rows updated.
Now, let’s look at the state of the system at this point. This example assumes a single-user
system; otherwise, you may see many rows in V$TRANSACTION. Even in a single-user system,
do not be surprised to see more than one row in V$TRANSACTION, as many of the background
Oracle processes may be performing a transaction as well.
ops$tkyte@ORA10G> 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
--------- ---- --- ---- ------ ----- -------
OPS$TKYTE 145 4 12 16582 6 0
ops$tkyte@ORA10G> select XIDUSN, XIDSLOT, XIDSQN
2 from v$transaction;
XIDUSN XIDSLOT XIDSQN
---------- ---------- ----------
4 12 16582