All entries for Wednesday 16 February 2011
February 16, 2011
create table test (id number) insert into test values (1);
Before commit or rollback, check the v$lock table.
First one’s lock type is TM (DML enqueue), Lock mode is 3 – row-x(SX), Request is 0 (none)
Second one’s lock type is TX (Transaction enqueue), Lock mode is 6 – exclusive (X), Request is 0 (none).
Check v$locked_object table. It displays the similar information as wellStep 2
In the same session
update test set id = 2
The locks in v$lock and v$locked_objects show same information as step 1.Step 3
Open a new session
update test set id = 3
Now check the v$lock table
The lock associated with the first session is still same: two locks.
But the “block” column in the “TX” lock is 1 , means it is blocking another session.
The “block” column in “TM” lock is still 0.
Session 2 has two locks now:
TM lock, Lmode is 3 (SX), request is 0
TX lock, LMode is 6 (X), request is 6 (X – exclusive X)
Check the v$locked_object
The row attached to session 1 is same.
A new row attached to session 2 has same (locked_mode, object_id), but XIDUSN, XIDSLOT, XIDSQN are all zero.
v$locked_object is very useful. It displays 1) user 2) object_id information 3) blocker & waiter
how to find out locked object in v$lock?
- dba_waiters: including waiters and blocker, mode_held & mode_requested
- dba_blockers: just one column holding_session.
- dba_lock_internal: Very slow to access
- v$access : Very slow to access