SQL SERVER – Detailed Explanation of Transaction Lock, Lock Type, Avoid Locks

Loyal reader of this blog and “Great SQL Expert” Imran Mohammed always have good attitude towards any problem. Many times his answers very interesting to read and details are very accurate. I came across his two interesting comment on this blog and I would like to share this all of you.

Priyank asked following question.

Can u tell us something about how to find which sql table is having the lock and of what type. also please tell us how to remove a lock from a locked table

Imran Mohammed answered in great depth to this question. I personally enjoyed it very much.


In SQL Server 2000 (Enterprise Manager)

1. Expand server – management-currentActivity-expand
locks/processid and you will be able to see all the locks related information.

2.Expand server – management-currentActivity-expand Locks/object you can see locks by object information.

In SQL Server 2005 (SSMS, object Explorer)
Expand-server-management-double click Activity Monitor.
on left side you have three options to choose from, select those options and you can see all the locks related information.

run this stored procedure in the database.

1. sp_lock

to know the running process in the sql server, run this query,

2. select * from sysprocesses ( in sql server 2000)
3. select * from sys.sysprocesses ( in sql server 2005)

4. sp_who
5. sp_who2 will also give you some good information.

To work around the locks, you can run profiler to check which query is is creating a lock and if that is necessary.

Types of locks on object level, ( general idea)

Database : Database.
Extent : Contiguous group of eight data pages or index pages.
Key: Row lock within an index.
Page: 8-kilobyte (KB) data page or index page.
RID :Row ID. Used to lock a single row within a table.
Table: Entire table, including all data and indexes.

Types of locks;
Shared (S) – more than one Query can access the object.
Exclusive lock (X) – only one Query can access the object.
Update lock (U)
Intent share (IS)
Intent Exclusive (IX)

Just to give you a brief idea about locks, We have something called as transaction levels in sql server databases.


level 0 is the lowest level isloation level, if your database is set in this isolation level, no query will lock any resources,Under this level, there will be no locks on the database, not even shared locks.

This data will also read uncommitted data. Data which you have not comitted, you can still read that data.

level1 is the default isolation level of the database.
Under this category you will not be able to read uncomitted data, this is also called as dirty data. Under this we will have shared locks.

As the level increases the locks also increases. The highest is the serializable.

To make you understand in detail, lets see an example of what is committed data and what is uncomitted data.

use pubs
create table example1 ( eid int, ename varchar(10))

begin tran T1
insert into example1 values ( 1, ‘example’)

select * from example1 — this is uncomitted data.

The above is uncomitted transaction, because you started the transaction with a begin, you have to commit the transaction, untill then the transaction will not be uncommitted.

to commit the same transaction

commit tran T1

select * from example1 — this is committed data.

To check what is the current isolation level of your database, run this command,

Dbcc useroptions — check for isolation level.

If you dont want your query to put locks on objects you might want to use something like this,

select * from example1_1 with (nolock)

This will not keep any lock, not even a shared lock on the table.

This is indepth concept try looking BOL.

Hope this helps,

Reference : Pinal Dave (https://blog.sqlauthority.com)

SQL Error Messages, SQL Scripts, SQL Server Security, SQL Transactions
Previous Post
SQL SERVER – 2005 – Best Practices Analyzer (August 2008)
Next Post
SQL SERVER – Disable All the Trigger of Current Database

Related Posts

28 Comments. Leave new

  • Hi Pinal Dave…. Hi All,

    hope you can help :(

    I have developed a little application for testing dead locks. I have seen in different forums that READ UNCOMMITTED allows read data even though has not been committed.

    Well, that is not working for me. I am executing the application with only one session or one database connection with with the oledb isolation level set to Read Uncommitted.

    For example, I insert a record ‘A’ to table AUTHORITY, then I delete records from table X, Y and Z, then I try to read from the table AUTHORITY again and I get X and IX dead locks. All under the same atomic transaction (And no others transactions accessing the database)

    My program is more complex than that, but in essence is what I am doing.

    So, why I am getting dead locks with Read Uncommitted under this scenario. Have I misunderstood something with the theory???

    Thanks for your Help……. Jorge

  • Subhankar Maiti
    March 2, 2017 12:53 pm


    As per my knowledge sql server default Isolation level is Read Committed but here you mentioned default is Read UnCommitted. If I am wrong please correct me.


Leave a ReplyCancel reply

Exit mobile version