Who Is Holding The Lock On The Table - DBA Paradise
Who Is Holding The Lock On The Table - DBA Paradise
Did you ever get an email or a phone call from a developer telling you they are
getting an error when trying to drop a table? It sounds something like this:
“What is going on, I cannot drop table A, I am getting an error:”
ERROR at line 1:
The mistake that some of us do initially, is to look for blocking sessions in the
database. But the above error that the developer is getting, most likely has
nothing to do with blocking. Rather it has all to do with locking.
Why do we have locks in the database?
The database locks are in place to prevent incorrect updates of the data, or
incorrect alters of the underlying object structures, while
multiple transactions are accessing the shared data in the database. Locks are
there to help maintain the database consistency and integrity.
There are two main categories of locks:
-exclusive locks
-shared locks
There is only one exclusive lock that can be obtained on a table or row at a time.
The exclusive locks prevents the resource to be shared. An exclusive lock is
obtained when the session modifies the data.
The transaction that locks the resource in exclusive mode is the only one that can
modify the resource, until the exclusive lock is released.
There are many shared locks that can be obtained on a table or row. The sessions
that read data usually get a shared lock on the resource.
Oracle is trying to lock the resource at the lowest level possible. There are locks at
the row level and there are locks at the table level.
When you want to modify data (update one row of a table), Oracle is locking
exclusively that one row, and is locking the table in shared mode.
Other sessions can access the data (read), modify other rows in the table, but
cannot alter the structure of the table, or drop the table.
When someone is altering the resource (table), then an exclusive table lock is
obtained. If another session has already an exclusive lock on the resource, then
the exclusive table lock cannot be obtained.
Now that the locking has been understood, the error message the developer was
getting is more clear.
What you need to do to help the developer out, is to find who is holding the lock,
and in what mode. Once that information is known, you have 2 options:
– ask the “locking” user to release the lock
– kill the “locking” user’s session.
Below is a script to provide you the answer to the question: Who is locking the
table?
select
c.object_type,
DECODE(a.locked_mode, 0, NONE
, 1, '1 - Null'
, locked_mode, ltrim(to_char(locked_mode,'990'))) lo
b.inst_id as node,
b.sid,
b.serial#,
b.status,
b.username,
b.osuser
from
gv$locked_object a ,
gv$session b,
dba_objects c
and a.inst_id=b.inst_id;
--Sample Output
If you enjoyed this article, and would like to learn more about databases, please
sign up below, and you will receive
The Ultimate 3 Step Guide To Find The Root Cause Of The Slow Running SQL!
–Diana
Start Solving Database
Performance ChallengesToday
4 Comments
Mahmoud Darwish says:
October 13, 2018 at 10:41 pm
Hi Diana,
Thank you for this great article, I have a correction for the query in the decode line
as it was not working with me, so I corrected the line to be:
DECODE(a.locked_mode, 0, ‘NONE’
Also, I have a question, In most mission-critical environments, we can identify
locks, but we can’t kill the corresponding sessions because it might hold an
important financial transaction, my question is, do we have a way to unlock these
locks without killing the session?
dianarobete says:
October 25, 2018 at 10:24 am
I don’t think you will be able to release the locks without killing the session
(not that I am aware of)