patternsqlMinor
Identify applications with locks
Viewed 0 times
withidentifylocksapplications
Problem
In my environment there is a database Sybase ASE 15, that I need to replace with a Microsoft SQL Server 2000-r2.
Many users access this database via some applications, that sometimes "forget" to commit a transaction, then idle indefinitely keeping the table lock. This has a terrible effect: all other applications queue to obtain a lock on the tables affected, and are effectively stuck.
In Sybase I use a query that tells me which user is causing the problem; I can then either kill the task, or even go to him/her and find and correct the problem in the application.
This is the Sybase query:
The output produced looks like this:
Unfortunately, syslocks does not exist in Mssql, at least not in the version I am using.
How do I convert the query to work on Mssql?
Of course, if there is an alternative way of achieving the same result that would be great.
Many users access this database via some applications, that sometimes "forget" to commit a transaction, then idle indefinitely keeping the table lock. This has a terrible effect: all other applications queue to obtain a lock on the tables affected, and are effectively stuck.
In Sybase I use a query that tells me which user is causing the problem; I can then either kill the task, or even go to him/her and find and correct the problem in the application.
This is the Sybase query:
select l.spid, SysLogin=s.name,SysObject=o.name, dbname
from master..syslocks l, master..sysprocesses p, SIAM..sysobjects o, master..syslogins s
where o.type='U'
and p.spid=l.spid
and l.id=o.id
and p.suid=s.suidThe output produced looks like this:
81 john authors maindb
88 mary authors maindb
88 mary books maindbUnfortunately, syslocks does not exist in Mssql, at least not in the version I am using.
How do I convert the query to work on Mssql?
Of course, if there is an alternative way of achieving the same result that would be great.
Solution
You might get it to work using only system procedure sp_lock. Although it's deprecated and it will be removed in a future version, it still works on SQL 2008 R2 and SQL 2012.
Another way is to use the DMV sys.dm_tran_locks.
I think that a more clearer way is to use Adam Machanic's procedure WhoIsActive which has a specific parameter for showing locks for a session.
Use them all and choose whatever suits you best, but the WhoIsActive procedure provides more info than just locks.
USE master;
GO
EXEC sp_lock;
GO
EXEC sp_lock 53; -- 53 is the spid for some specific user session;
GOAnother way is to use the DMV sys.dm_tran_locks.
Select *
from sys.dm_tran_locks dl
join sys.sysprocesses sp on dl.request_session_id = sp.spidI think that a more clearer way is to use Adam Machanic's procedure WhoIsActive which has a specific parameter for showing locks for a session.
Use them all and choose whatever suits you best, but the WhoIsActive procedure provides more info than just locks.
Code Snippets
USE master;
GO
EXEC sp_lock;
GO
EXEC sp_lock 53; -- 53 is the spid for some specific user session;
GOSelect *
from sys.dm_tran_locks dl
join sys.sysprocesses sp on dl.request_session_id = sp.spidContext
StackExchange Database Administrators Q#34129, answer score: 2
Revisions (0)
No revisions yet.