I have a scheduled job with a SP running on daily basis (SQL Server 2005). Recently I frequently encounter deadlock problem for this SP. Here is the error message:
Message
Executed as user: dbo. Transaction (Process ID 56) was deadlocked on thread |
communication buffer resources with another process and has been chosen as the deadlock
victim. Rerun the transaction. [SQLSTATE 40001] (Error 1205). The step failed.
The SP uses some inter joined views to some tables, one of them is a large size data table with several million rows of data(and keep growing). I am not sure if any job or query against to the table will cause the SP un-accessible to the table? I am going to investigate who is on line by using the query. That may expose some query or person on SQL server during that time.
Not sure if any one have similar issue or this is known SQL 2005 issue? Any additional way I should do in my SP or on SQL server to avoid the deadlock?
Use the SQL Server Profiler to track all the queries that are running. I put the output into SQL Server. This will help you figure out which ones are accessing your particular table / tables. Post your findings, and we can help you with that.
Deadlocks are when two transactions are each holding onto some resources and want a resource that the other one has as well - neither can proceed as they are both waiting for each other. They cannot be completely eliminated, but a lot can be done to mitigate them. Remus and Raj suggest capturing more information about them in Profiler - which I also recommend - generally optimizing your queries (if you know which ones are involved) can also help. Here is an MSDN article that can help get you going: "Minimizing Deadlocks".
Related
using MS SQL server 2016, we have sporadic transaction timeouts due to locking issues (once every 2 days).
The statement failing is select ... (nolock) from table where id in (...,...,...,...).
The activity is high and we couldn't find the cause of the issue.
My question: how is it possible, in case of rollback/timeout, to record in a log (event viewer, trace file, text file, anything) the statements run by the sessions causing the issue, so that we can figure out afterward what happened?
Thanks.
We use monitoring software SentryOne and Solarwinds offers the ability to monitor and record activity in the spids involved in blocking/deadlocks. I am not advocating using this software and running SQL profiler or extended events might give you the same results, I am just posting that this is how we do it.
I'm newbie as a SQL Server DBA , everyday at least once I've got a deadlock issue in SQL Server 2012 server which is using Merge statement. There are no clause like NOLOCK, UPDLOCK, HOLDLOCK has been used in the merge statement. It's a multi user environment where the Biztalk reads the xml and save data into SQL Server.
Per minute, Biztalk reads 300 xml messages. Since its a production server I can't implement anything just like that without doing research, but I haven't got any idea on how to resolve this issue. Recently I had an issue with two xml messages trying to update data in a table and trying to use the same index and error-ed out. Could anyone help me how to get away with this issue?
The scan phase of MERGE is performed with a shared lock (S), optimized for the case of a single session running MERGE and concurrent sessions running SELECT. In the case of multiple concurrent MERGE statements, this can lead to deadlocks or failures.
The solution you should add a HOLDLOCK hint on the target table. This is a little bit inconsistent with other read-for-update patters which use UPDLOCK on SELECT.
The bane of my existence is when the MERGE on a table partition gets deadlocked and eventually loses.
I've tried setting the deadlock_priority to high.
I have code that kills each query hitting the tables beforehand, but sometimes I still get a query in there during those milliseconds.
I'm at a loss. Is there a good way to do this?
You must use hints in order to lock the objects that are used by the merge statement -xlock,holdlock.
My advice is to start the sql Profiler with event Deadlock Graph and try to reproduce the deadlock with a tool (I use this tool) and then to figure out why it is happening. Read this as initial information.
I am using SQL server 2005, SQL server studio client. I am having a long stored procedure (it does a bunch of table joins, some delete, some insert and some updates) periodically running (approximately every other 2 minutes).
After I have this sp, I noticed that my database is sometimes not responding (it happens a few times when the SP is not running, and many times during the SP is running). When the DB is not responding, i can't open new connection from the SQL server studio client, if i run a query/sp the status will become running and stays that forever, until i manually reset the SQL service from control panel admin-tools.
Have you seen similar problems?
Is it perhaps because the SP I newly created is doing too much things and cause the DB to crash?
A few more quick tips:
You can use the sp_who2 command to view current sessions on the DB and determine if the SP is blocked, or blocking other processes.
Check the estimated execution plan for the SP, and look for sources of slowness, like table scans.
Your SP might be making too many changes in a single transaction and filling up the transaction log or causing it to grow. Inspect your DB's recovery mode, and whether backups are occurring regularly so that transaction log space can be reused. Consider batching large modifications into smaller chunks.
It sounds like your SP might be causing locks. You could use SQL Profiler to try and dig deeper into what might be happening. Here's a link providing further info -
http://www.simple-talk.com/sql/learn-sql-server/how-to-track-down-deadlocks-using-sql-server-2005-profiler/
Every morning we have a process that issues numerous queries (~10000) to DB2 on an AS400/iSeries/i6 (whatever IBM calls it nowadays), in the last 2 months, the operators have been complaining that our query locks a couple of files preventing them from completing their nightly processing. The queries are very simplisitic, e.g
Select [FieldName] from OpenQuery('<LinkedServerName>', 'Select [FieldName] from [LibraryName].[FieldName] where [SomeField]=[SomeParameter]')
I am not an expert on the iSeries side of the house and was wondering if anyone had any insight on lock escalation from an AS400/Db2 perspective. The ID that is causing the lock has been confirmed to be the ID we registered our linked server as and we know its most likely us because the [Library] and [FileName] are consistent with the query we are issuing.
This has just started happening recently. Is it possible that our select statements which are causing the AS400 to escalate locks? The problem is they are not being released without manual intervention.
Try adding "FOR READ ONLY" to the query then it won't lock records as you retrieve them.
Writes to the files on the AS/400 side from an RPG/COBOL/JPL job program will cause a file lock (by default I think). The job will be unable to get this lock when you are reading. The solution we used was ... don't read the files when jobs are running. We created a big schedule sheet in excel and put all the sql servers' and as/400's jobs on it in times slots w/ color coding for importance and server. That way no conflicts or out of date extract files either.
You might have Commitment Control causing a lock for a Repeatable Read. Check the SQL Server ODBC connection associated with <linkedServerName> to change the commitment control.