I'm going thru my application log, and just seeing what errors are popping up. I have a relatively intense search feature, thats causing alot of deadlocks.
Exception type: SqlException
Exception message: Transaction (Process ID 105) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
In general, what's the best way to resolve this ?
Should I see if I can apply "WITH (NOLOCK)" to my data ?
I need to discover the actual order in which locks are acquired on a table during a query.
This with a goal of analyzing the lock order of queries against the same table to prevent deadlocks.
I'm using SQL Server 2008 R2.
From Management Studio I execute:
begin transaction <my query> exec sp_lock rollback transaction
In the output I see interesting information about which locks are acquired, but:
- are this locks ordered by the time they're acquired? That is, can I be sure that lock at row n is acquired before lock at row n+1? - if not, how can I get this information?
Our system is reasonably complex with a lot of non-trivial stored procedures. As the load on our DB increased we're now getting more and more deadlocks (10 per day or so from about a million stored proc executions).
We try to avoid transactions where we can, and we do attempt to optimse stored procs to steer clear of deadlock conditions, but with the sheer number of stored procedures we can't possibly avoid all deadlock conditions.
One solution I'm considering is to re-run stored procs that failed because of a deadlock. In the .net code we'll run the stored proc, check for a deadlock error and if one happened, wait 100ms and try again.
we have a production inviremont that is running for about 10 months. Since a couple of weeks we are having problems with "Deadlocks".
This cant be due to an increase in data size on the tables that are having the issues because these are cleaned in the same transaction that populates them.
These tables are used to store temporary data that the production system needs to calculate the correct price for any given order. This transaction takes between 0.5 to 1 second to commit.
We are running on a dual processor machine with 1 Gb of RAM with SQL Server 7 - sp 3, Windows NT 4 sp 6, Microsoft Transaction Server.
In all our queries and stored procedures we use the optimizer hints (nolock) for select statements and (rowlock) for updates or deletes.
Is there any way to totally avoid deadlocks. In some critical applications we have removed transactions entirely, counting on other means to maintain database consistency. We still get deadlocks in this area. These are mainly inserts, and the only thing I can think is that updates to the indexes are causing multiple page locks which result in deadlocks. Is this true?
Will deadlocks be eliminated in 7.0 with row level locking for this situation? Or will index page splits still cause a possibility of deadlock contention?
I have a problem with a SP in 6.5. When i try to run a Stored Proc which is a simple select statement dumped into a temp table in a particular database, I lock other users who are tring to log into other databases some in tempdb database. When i try to kill the process the rollback takes almost 45 mins or so..till then no one can log on to the server.
The SP works fine when no one is logged into the Great Plains server. One more thing i observed is that, the SP when run results on a deadlock only when the owner is a user. If the owner is DBO it works fine.
I've got a deadlock problem. The log below has been generated. The problem is that during one day, I have more than 300 deadlocks like it. Before, the were not so many deadlocks. During past year, the number of users has grow (from 100 before to 500 or 700 now)
*** Deadlock Detected *** - Requested by: SPID 360 ECID 0 Mode "S" - Held by: SPID 113 ECID 0 Mode "S" Index: aaaaa_PK Table: TABLE_1 Database: MYDB == Lock: KEY: 22:325576198:1 (ff009ae5078d) - Requested by: SPID 113 ECID 0 Mode "S" - Held by: SPID 374 ECID 0 Mode "X" Index: aaaaa_PK Table: TABLE_1 Database: MYDB == Lock: KEY: 22:325576198:1 (ff009ae5078d) - Requested by: SPID 374 ECID 0 Mode "IX" - Held by: SPID 360 ECID 0 Mode "S" Table: TABLE_2 Database: MYDB == Lock: PAG: 22:1:2428 == Deadlock Lock participant information: Input Buf: S E L E C T the_rest_of_the_query SPID: 360 ECID: 0 Statement Type: UNKNOWN TOKEN Line #: 1 Input Buf: s p _ e x e c u t e 8 Input Buf: s p _ c u r s o r 8Ā B 8 8f į @ Table I Input Buf: S E L E C T the_rest_of_the_query SPID: 360 ECID: 0 Statement Type: SELECT Line #: 1 == Session participant information: == Deadlock Detected at: ==> Process 360 chosen as deadlock victim
I have done : - rebuild indexes on all tables (fillfactor 90) - analysed memory activity
Could a lack of memory be at the origin of the problem ? Which counters in perfmon are significant for memory lack ?
Could the index fill factor could be at the origin of the problem ? At time, it is at 90 percent.
Config : Winnt4 Server, MS-SQL 7 SP4 , 2 GB of RAM , 2 x Xeon 700
I have an application built on top of a questionable DB design which requires overcomplicated selects. The application is experiencing deadlocks regularly, in some cases with only one concurrent user.
I set the trace flag 1204 but am not seeing anything in the Error.log and I initiated a trace in profiler which does not seem to show any deadlock. Despite having recreated the problem which show my browser hanging indefinitely. When I run the following queries:
SELECT spid, waittime, lastwaittype, waitresource FROM master..sysprocesses WHERE waittime > 10000 AND spid > 50
SELECT spid, cmd, status, loginame, open_tran, datediff(s, last_batch, getdate ()) AS [WaitTime(s)] FROM master..sysprocesses p WHERE open_tran > 0 AND spid > 50 AND datediff (s, last_batch, getdate ()) > 30 ANd EXISTS (SELECT * FROM master..syslockinfo l WHERE req_spid = p.spid AND rsc_type <> 2)
I get:
55860978LCK_M_XPAG: 13:1:2573
54AWAITING COMMANDsleeping sa 11499 55UPDATE sleeping sa 21499
We have a SQL 2005 transaction database server that suddenly started to issue deadlock errors last week on most of the databases on that server and a lot of timeout errors. Before that, that database server performed very well and timeouts were minimal to zero. I am not sure what changed for it to have these performance problems.
The only major change we did was to convert several varchar columns to nvarchar in several tables (as part of internationalization initiatives). We did not modify the procs from varchar to nvarchar though but would be doing that phase by phase.
There is also one proc in which we used the snapshot isolation level of sql server 2005. These are only 2 major changes done within the past 2 weeks. Would these be the cause for these deadlocks and timeouts on our web-based application?
Hi EverybodyI am new to sqlserver 2000.I know basics of locks.but i dont know how toresolve deadlock issues.I am cofusing by reading articles with 90%information and remaining 10% missing.Can any one help me which is the goodsite to learn and resolve deadlocks.Note: I create deadlock. when i try to trace deadlock using dbcc traceon(1205,3604,-1).In error log showing nothing about the deadlock.showing created traceon.........Any help would be appreciated.--Message posted via http://www.sqlmonster.com
We have a problem with a table giving us deadlock issues and we can'tfigure out why.It's a table we write to fairly often perhaps 50 times a minute. Andalso do a select of 200 rows at a time from 4 servers every 5 minutes or so.We are only keeping 48 hours worth of rows in the table which averagesat 30000 a day on a busy day.This table has 1 PK and 2 FKs plus one TEXT column which does notparticipate in the WHERE clause.We are using binded variables.We have applied the latest patch to SQL2003 server running onWindows2003. The patch is supposed to resolve deadlock issues.Anyone have any advice on how to alleviate this problem.Thanks
Morning All, Am getting the following error from a number of users and am sort of wondering where to start in terms of diagnosing the problem. If anyone could give me any pointers on where to start in diagnosing the issue I would be grateful. "System.Data.SqlClient.SqlException: Transaction (Process ID 282) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction."
I know blocks and Deadlocks are different but how related are they? Seems like when I get reports of deadlocks I always have blocks and the blocks grow as time passes.
My database has been in production for 10 months with no deadlock problems. Three weeks ago I had to restore the database and I am now experiencing several deadlocks. SQL server is suppose to handle this and kill a process to resolve the deadlock but it is not. The deadlock occures on a stored procedure which is a simple select on a table with 187 records. DBCC ran with no problems. Any ideas what might be causing this? Any why is SQL not handling? Your help is greatly appreciated!
I need some help in reducing deadlocks in 6.5 I have tested with `Insert Row Locking` turned off and it reduced the number of deadlocks. What i need to know is if removing the foreign key relationships on tables reduces/eliminates Deadlocks. If any of you have any info on this please let me know.
i have an issue regarding the following error message:
[Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID ##) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
this is caused on a couple of ASP pages, which are using:
This is happening fairly frequently, which can't be a good thing, so would it be worth changing the lock or cursor types to a different one, in particular, adLockPessismistic?
Any pointers or comments would be very welcome.
This is happening on a windows server os, sql server 2000 using classic asp (.asp) pages, connecting to sql server using ado within the asp pages.
I am conducting stress testing for my website and keep getting deadlocks with the following message when one process is adding about 100 records per second and another process is trying to access the data:
Transaction (Process ID 499) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
What do I need to do in my stored procedures to avoid this? I only have ONE stored prcoedure that locks a row while incrementing an ID value. I am not doing any other locks, so is this a SQL Server system lock?
I have a search function, which searches across many tables.
It's a pretty heavy SPROC, I'm wondering in general, what are the best way to reduce deadlocks ? Its used a fair bit, and altho I haven't noticed problems with it myself, there are definately a decent amount of deadlocks showing up in the logfiles.
I've always assumed this is something really difficult, and avoided it like the plague.
Problems in a 2008 R2 environment, database grows quickly and deadlocks occure somtimes.When I checked the database the tables lacked completely of indexes.How can I find out which indexes that should be created and how to manage the deadlocks?
I face alot of DeadLocks in my SQL Server. the server is SQL 2000 SP3 with Windows 2000 sp4. I have all kinds of locks and i really don't understand none of them. I tried to restart the server and it didn't help - the locks id and locks objects are still there - about 15 objects. what to do?
I'm trying to diagnose deadlocks in SQL Profiler. The deadlocks weregenerated by Loadrunner scripts (stress testing) simulating applicationSQL via an ODBC DSN connection.2 things are puzzling me in the SQL Profiler traces that I have logged1) There are a large number of Lock:Timeout events but the 'locktimeout' setting is the default 'wait forever' so I dont know what istiming out.2)When say 2 distinct SPIDs are in a Deadlock Chain, they are using thesame ClientProcessId at the time of deadlock. What is theClientProcessId and is it relevant to the deadlock?Thank you in advance for any replies.
I am getting lot of deadlocks in my application. As it is very complexti avoid deadlocks at this stage of application we have done few stepsto lessen the impact.We have added retries after deadlock is capturted.We have added select * from TABLE with (nolock) wherever possible.But interestingly second step is not working. I have few simple selectstatements where i am using nolock criteria still I am gettingdeadlock victim error. Any idead why it happening. I thought as soonas I put nolock in the query it will ignore all the locks.My sp isCREATE procedure sp_Check_denomination@supply_till_idint,@product_codechar(4),@iso_currency_codechar(3),@denominationmoneyasdeclare @product_id numeric(5)select @product_id = product_id from product with (nolock) whereproduct_code = @product_codeif exists (select *from transaction_inventory TI with (nolock),product_ccy_denom PCD with (nolock)where TI.supply_till_id = @supply_till_idand TI.product_id = @product_idand TI.iso_currency_code= @iso_currency_codeand TI.denomination = @denominationand TI.product_id = PCD.product_idand TI.iso_currency_code = PCD.iso_currency_codeand TI.denomination = PCD.denominationand PCD.product_id=@product_idand PCD.denomination = @denominationand PCD.iso_currency_code=@iso_currency_codeand PCD.tradeable = 1)beginreturn(1)endelsebeginreturn(0)endGO
Hi All,I have read about deadlocks here on Google and I was surprised to readthat an update and a select on the same table could get into adeadlock because of the table's index. The update and the selectaccess the index in opposite orders, thereby causing the deadlock.This sounds to me as a bug in SQL Server!My question is: Could you avoid this by reading the table with a'select * from X(updlock)' before updating it? I mean: Would thisresult in the update transaction setting a lock on the index rowsbefore accessing the data rows?Merry Christmas!/Fredrik Möller
HiI'm having a problem with deadlocks in a table in SQL server whentrying to update it through Biztalk 2004. There is no problem when Iuse the same Biztalk solution to update a similar dummy table, butwhen I try updating the original table in the production database,some transactions are updated successfully whereas others become thevictim of the deadlock (Transaction (Process ID 185) was deadlocked onlock resources with another process and has been chosen as thedeadlock victim. Rerun the transaction). The table that is updated isalso being used by another application that just selects rows from it.As a workaround, I have used recursion in the code that updates thetable. The function is put through a recursive loop whenever thedeadlock exception(#1205) is caught. It keeps on trying to update thetable until the updation is successful or another exception (not thedeadlock one) is caught. i.e.Bool Update_IVR(string amount, string customer_id){Try{//updation code}}Catch (exception ex){If( ex.message == deadlock message){Bool succ =Update_IVR (amount, customer_id) //recursionReturn succ;}Else //error handling code}After introducing this code, the problem did not occur for the next13000 transactions. Then I got the error again four times along with atimeout error (Timeout expired. The timeout period elapsed prior tocompletion of the operation or the server is not responding). Howeverfor the next 17000 transactions (to date) this error has not showedup.ThanksHasan
We've found deadlocks in the trace file that were not captured by ourPowerbuilder application. Some deadlocks are trapped or, at least,reported to the user as a db error, and others are completely silent.We've also seen evidence of strange data that would be explained byunprocessed deadlocks, although we've not yet proven that theunreported deadlocks are killing updates to the db.Putting a raiserror into various parts of the same code (and codereview) appears to prove that we are error checking after each dbupdate. That is, it looks like we're checking, and a raiserror alwaysbubbles up to the app.Can anyone shed some light on a.) How this could happen and b.) WhatShould We Do?Some of one of the traces below (with minor anotations.ThanksDeadlock encountered .... Printing deadlock information2004-11-11 10:33:57.77 spid42004-11-11 10:33:57.77 spid4 Wait-for graph2004-11-11 10:33:57.77 spid42004-11-11 10:33:57.77 spid4 Node:12004-11-11 10:33:57.77 spid4 TAB: 6:1739869265 (cbo1023p) []CleanCnt:2 Mode: X Flags: 0x02004-11-11 10:33:57.77 spid4 Wait List:2004-11-11 10:33:57.77 spid4 Owner:0x60e085e0 Mode: ISFlg:0x0 Ref:1 Life:00000000 SPID:88 ECID:02004-11-11 10:33:57.77 spid4 SPID: 88 ECID: 0 Statement Type:SELECT Line #: 1232004-11-11 10:33:57.77 spid4 Input Buf: Language Event: selectcbord.cbo1000p_item.longname as itemname,cbord.cbo4002p_itemevent.eventdate,cbord.cbo4002p_itemevent.eventstatus,cbord.cbo4002p_itemevent.unitid,cbord.cbo4004p_eventlist.itembin_intid,cbord.cbo4004p_eventlist.itemu2004-11-11 10:33:57.77 spid4 Requested By:2004-11-11 10:33:57.77 spid4 ResType:LockOwner Stype:'OR' Mode:IS SPID:84 ECID:0 Ec:(0x4F9B3A00) Value:0x4a0e9400 Cost:(0/0)2004-11-11 10:33:57.77 spid42004-11-11 10:33:57.77 spid4 Node:22004-11-11 10:33:57.77 spid4 TAB: 6:1739869265 (cbo1023p) []CleanCnt:2 Mode: X Flags: 0x02004-11-11 10:33:57.77 spid4 Grant List 2::2004-11-11 10:33:57.77 spid4 Owner:0x4de9a8a0 Mode: XFlg:0x0 Ref:742 Life:02000000 SPID:121 ECID:02004-11-11 10:33:57.77 spid4 SPID: 121 ECID: 0 Statement Type:UPDATE Line #: 142004-11-11 10:33:57.77 spid4 Input Buf: RPC Event:cbord.p_pur002_replacecost;12004-11-11 10:33:57.77 spid4 Requested By:2004-11-11 10:33:57.77 spid4 ResType:LockOwner Stype:'OR' Mode:IS SPID:88 ECID:0 Ec:(0x4F259A70) Value:0x60e085e0 Cost:(0/0)2004-11-11 10:33:57.77 spid42004-11-11 10:33:57.77 spid4 Node:32004-11-11 10:33:57.77 spid4 KEY: 6:2134298663 (cbo1000p_item):1(96006e2bf95f) CleanCnt:1 Mode: U Flags: 0x02004-11-11 10:33:57.77 spid4 Grant List 2::2004-11-11 10:33:57.77 spid4 Grant List 3::2004-11-11 10:33:57.77 spid4 Owner:0x4dc088a0 Mode: SFlg:0x0 Ref:1 Life:00000000 SPID:84 ECID:02004-11-11 10:33:57.77 spid4 SPID: 84 ECID: 0 Statement Type:CONDITIONAL Line #: 632004-11-11 10:33:57.77 spid4 Input Buf: Language Event: selectcbord.cbo1000p_item.longname as itemname,cbord.cbo4002p_itemevent.eventdate,cbord.cbo4002p_itemevent.eventstatus,cbord.cbo4002p_itemevent.unitid,cbord.cbo4004p_eventlist.itembin_intid,cbord.cbo4004p_eventlist.itemu2004-11-11 10:33:57.77 spid4 Requested By:2004-11-11 10:33:57.77 spid4 ResType:LockOwner Stype:'OR' Mode:X SPID:121 ECID:0 Ec:(0x5F719A70) Value:0x48286aa0 Cost:(0/B9654)2004-11-11 10:33:57.77 spid4 Victim Resource Owner:2004-11-11 10:33:57.77 spid4 ResType:LockOwner Stype:'OR' Mode:IS SPID:88 ECID:0 Ec:(0x4F259A70) Value:0x60e085e0 Cost:(0/0)2004-11-11 10:34:02.77 spid4
I'm working on a system now where the workflow is as follows:
1. A user uploads a batch of some fairly large number of items (1000, say) to a holding table. 2. We run an SP against the holding table to test those items; some get flagged as valid, some as invalid. 3. We run a subsequent SP that inserts the valid items into the main table and then deletes them from the holding table.
In our concurrency testing, we're encountering deadlocks, and I'm struggling to figure out why. In step 2, for instance, the SP code looks like this:
BEGIN TRANSACTION UPDATE HoldingTable SET Valid = CASE WHEN <condition1> THEN 0 WHEN <condition2> THEN 0 ... ELSE 1 END, Reason = CASE WHEN <condition1> THEN 'reason1' WHEN <condition2> THEN 'reason2' ... ELSE 'valid' END
WHERE BatchID = @BatchID COMMIT
Each contending process has its own batch of items, marked with an identifying batch ID. And they deadlock.
Our first thought was that the contending processes are deadlocking over pages containing rows from both batches. This seemed unlikely, but we thought, what the heck, let's create a clustered index on BatchID, PK, which should keep batch 1's rows out of the same pages that batch 2's rows are in. That had no discernable effect: we still got deadlocks.
Our next thought was that the number of rows involved is large enough that both processes are escalating from page locks to table locks during the update. It seems to us that this would create a deadlock.
Before I go into this in much more detail: are we on the right track here? Is it reasonable to be encountering deadlocks when two processes perform an UPDATE against different rows in the same table?
Any help with deadlocks ? I keep getting deadlocks..and can't figure out why.... version of sql server: 8.00.2040 (SP4). [Microsoft][ODBC SQL Server Driver][SQL Server]Transaction (Process ID 73) was deadlocked on lock resources with another process and has been chosen as the deadlock victim. Rerun the transaction.
ok, about a few months ago I brought up the issues we were having with deadlocks. My company is running a .net data entry application hitting against a sql 2000 box. Forget hardware since we have more then enough hardware to handle the load.
The issue we are seeing is we get a process that blocks a table, and the bulding up of block process that cause timeouts/deadlocks etc. A couple of things we see when this happens is that .net on the web server seems to open up more and more connections(it seems to double or triple the connections as the blocking begins), we start to see deadlocks and we see alot of timeouts in the app due to the blocking.
The blocking aways happen on an insert of an order or a customer. One thing I keep wondering about is how we handle the unique id for our tables. Our DBA had us put in the following:
Begin Trans select max(id) + 1 insert.... commit trans
I've heard from a few here and in other forums this is the wrong way to go. I'm still get a gut feeling that this could start causing issues like what we are seeing. My problem is I'm not knowledgable enough to make a strong enough case with it.
What I need help is getting enough information to either point to how we manage ID's or at the very least rule them out. I've done searchs in google and some other search engines but there doesnt seem to be any good articles on how best to handle unique ids and show a good case for it. I do know I can use sql identity, or even guid with the newid() function but I need solid proof before my boss will move to one of these methods. Any links you guys can give or even your own write up will really help my case and hopefully help my headache.
