I am getting deadlock error when updating a table :
Transaction (Process ID 67) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
All other works perfectly fine. The thing making me uncomfortable is I have restarted the server itself 4-5 times how is the dead lock still on table.
Any suggestions?
Transaction (Process ID 67) was deadlocked on lock | communication buffer resources
This is probably caused by a bug while running a parallel query. Upgrade SQL Server to a later version, or disable parallelism for this query or the whole server.
Related
I have running a concurrent SQL job to update the data in the same table. Which is making deadlock on the server-side. I have tried the locking method which does not solve my problem.
I use MS SQL Server 2014 for my Java-based web app. I saw a few database-related exceptions in the web log. Each one looks like the following:
Transaction (Process ID 138) was deadlocked on lock | communication buffer resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
From the above info, I am not able to see which tables are involved. How can I find out the tables in question based on the above information?
We are experiencing the mentioned dead lock exception while doing CRUD on two SQL Server tables from parallel threads by calling Stored Procedures, here is the detailed scenario:
We have a desktop application where we are spinning up a code block in 100 - 150 parallel threads, the code block does insertion in TableA using SQL Bulk Copy and makes calls to three Stored Procedures, The stored procedures do insertion, updation and deletion in TableB based on some selection from TableA.
Soon as the application starts execution of the threads, SQL Server starts throwing the mentioned dead lock exception for a certain number of threads while some of the threads do run fine.
Exception Message:
Transaction (Process ID 160) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
Any help in this regard is appreciated in advance.
Thanks.
Is this SQL Server or SQL Azure/Azure SQL DB? If it's "box" SQL Server, you might consider ALTER DATABASE SET READ_COMMITTED_SNAPSHOT ON. This will enable read versioning. It's still possible to encounter deadlocks in this state, but it's as close to a silver bullet as you're likely to get.
Read versioning changes the concurrency model in some subtle ways, so be sure to read about it first and make sure it's compatible with your business logic: https://msdn.microsoft.com/en-us/library/tcbchxcb(v=vs.110).aspx
Otherwise, Srivats's other suggestion about minimizing transaction scope is not always simple to implement but is still solid. To that list, I would add: Ensure that you have well-indexed query access paths, and verify that none of the queries within your transactions require full table or index scans.
The message is clearly evident that Transaction (Process ID 160) was deadlocked on lock resources with another process.The lock could be on different levels. The locks are not getting released before another thread could lock that particular resource. Try to kill that Process Id and check the workflow if there are any lock conflicts.
Why would sql-server lock monitor thread would not resolve deadlocks?
I don't have much details about this, but my friends complain about deadlocks occuring from time to time on SQL Server (2005 & 2008) databases.
As I know, Sql Server deadlock detection mechanism handles deadlock scenarios pretty well by choosing one of the processing as the victim and terminating/rolling it back, so the other process can complete, so no deadlocks would be left there to resolve.
Are there any conditions where SQL Server deadlock handling might fail, or it might be turned off?
thanks in advance
Deadlock handling can only result in one connection being killed.
This is the only resolution to a deadlock sitution, which happens when 2 process are blocking each other. So neither can proceed and one must be aborted
When shutting down my project's WebSphere-based JavaEE application, distributed transactions are sometimes left alive in the SQLServer 2005 database. These retain their locks forever and must be killed manually. They are described generally in this very good article.
The article talks about how the transaction coordinator is unable to co-ordinate the distributed transaction participants and so flags the transaction with a process ID of -2.
Given that we get this issue infrequently, but that it always happens when we shut down the application, I am not convinced it is a failure of the MSDTC. It is more likely to have something to do with WebSphere and how it terminates applications.
I would like to test it. But I cannot reliably make it happen.
Is there any way to force the MSDTC to orphan a SQLServer distributed transaction?
My question was misleading, because I wasn't quite sure what the problem actually was. I suspect MSDTC is assisting WebSphere in transacting with MQ and SQLServer. The problem occurs when we perform an unclean shutdown of the WAS server and the vendor-provided part of our application tries to do some sort of cleanup and fails.
I suspect this question is not helpful to anyone else (unless they are using the Misys Message Manager in WebSphere on Windows) so apologies, dear reader, for wasting your time.
Orphaned DTC transactions can occur in case SQLServer sessions with open but not yet prepared DTC or XA transactions are closed. This may happen because of network interruption or due to unexpected application abort.
In this case SQLServer keeps the transaction with DTC and the SPID is -2.
The post on SQLServerCentral mentions that following query can be used to identify the orphaned transactions:
Select req_transactionUOW
from master..syslockinfo
where req_spid = -2
Exeuting "kill" with the UOW given as argument, will remove the active ransaction.
This behavior of SQLSever is very uncommon. Usually a session loss will abort any XA transaction.
The good news is that SQLServer provides an option that changes this behavior.
The trace flag 3924 can be set in order to achieve this. Just exec DBCC TRACEON(3924,-1) with "sa" privileges and SQLServer automatically removes transactions in case sessions get lost.
The trace flag will be lost on SQLServer restart. In order to get it set during SQLServer startup automatically add it in SQLServer configuration manager:
SQLServer Configuration Manager sceenshot