• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 850
  • Last Modified:

How to resolve a deadlock

I have been experiencing deadlock errors in my sql server 2000 database.  I have run DBCC TRACEON(1204) to identify whats causing the problem and the results are shown in the code snippet below.  I am now trying to identify what the problem is.  It seems that under Node 2, the stored procedure SnapPriceRateBuffers has requested an exclusive lock on TableA.  Under Node 1, stored procedure remote_GetDataAll is performing a SELECT INTO a temporary table (lets say #TableB).  This SELECT INTO statement is sourcing data from TableA in the FROM clause but I don't understand why this situation would cause a deadlock.  Is it possible to explain what is going on from the results of the error log?

Thanks
2007-11-29 11:13:09.16 spid2     Wait-for graph
2007-11-29 11:13:09.16 spid2     
2007-11-29 11:13:09.16 spid2     Node:1
2007-11-29 11:13:09.16 spid2     RID: 7:1:25386:11              CleanCnt:1 Mode: U Flags: 0x2
2007-11-29 11:13:09.16 spid2      Grant List 0::
2007-11-29 11:13:09.16 spid2      Grant List 1::
2007-11-29 11:13:09.16 spid2        Owner:0x5164a880 Mode: S        Flg:0x0 Ref:1 Life:00000000 SPID:53 ECID:0
2007-11-29 11:13:09.16 spid2        SPID: 53 ECID: 0 Statement Type: SELECT INTO Line #: 34
2007-11-29 11:13:09.18 spid2        Input Buf: RPC Event: remote_GetDataAll;1
2007-11-29 11:13:09.18 spid2      Requested By: 
2007-11-29 11:13:09.18 spid2        ResType:LockOwner Stype:'OR' Mode: X SPID:52 ECID:0 Ec:(0x76AFD578) Value:0x467028c0 Cost:(0/17A58)
2007-11-29 11:13:09.18 spid2     
2007-11-29 11:13:09.18 spid2     Node:2
2007-11-29 11:13:09.18 spid2     RID: 7:1:1830:27               CleanCnt:1 Mode: X Flags: 0x2
2007-11-29 11:13:09.18 spid2      Grant List 0::
2007-11-29 11:13:09.18 spid2        Owner:0x1ade6200 Mode: X        Flg:0x0 Ref:0 Life:02000000 SPID:52 ECID:0
2007-11-29 11:13:09.18 spid2        SPID: 52 ECID: 0 Statement Type: UPDATE Line #: 63
2007-11-29 11:13:09.18 spid2        Input Buf: RPC Event: SnapPriceRateBuffers;1
2007-11-29 11:13:09.18 spid2      Requested By: 
2007-11-29 11:13:09.18 spid2        ResType:LockOwner Stype:'OR' Mode: S SPID:53 ECID:0 Ec:(0x6A09D578) Value:0x462bdce0 Cost:(0/0)
2007-11-29 11:13:09.18 spid2     Victim Resource Owner:
2007-11-29 11:13:09.18 spid2      ResType:LockOwner Stype:'OR' Mode: S SPID:53 ECID:0 Ec:(0x6A09D578) Value:0x462bdce0 Cost:(0/0)

Open in new window

0
nicksbell
Asked:
nicksbell
  • 3
  • 3
1 Solution
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
Deadlocks happens when a query is locking a resource and tries to work with other resource that is already locked by another process and that process at same time tries to access the resource locked by 1st process. (I hope isn't confusing) :)

This is a programming issue and DBA can't do nothing about it. SQL Server will choose one of the process as victim and you kill it, freeing resources to the process that's kept alive.

It needs to change queries to use locking hints or create indexes to speed up queries.

Good luck
0
 
nicksbellAuthor Commented:
What I am trying to understand is why the following 2 sql statements might cause a deadlock.  This is a simplified example of what is happening in my actual situation.

Statement 1

UPDATE
    TableA
SET
    Column1 = 'xxx'

Statement 2

SELECT
    *
INTO
   #TempTable
FROM
    TableA

These are the 2 processes that are causing the deadlock and I am trying to understand how this could fit into the the scenario you describe for deadlocks to occur.
0
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
Well, UPDATE don't have a WHERE clause, so SQL Server will lock all table.
SELECT doesn't have a WHERE clause either, so to SQL Server guarantee that all records that will being copied to TempTable will be the same that are in TableA, will need to lock all table as well.

But that scenario should only cause a blocking lock and not a deadlock.
0
Introducing Cloud Class® training courses

Tech changes fast. You can learn faster. That’s why we’re bringing professional training courses to Experts Exchange. With a subscription, you can access all the Cloud Class® courses to expand your education, prep for certifications, and get top-notch instructions.

 
nicksbellAuthor Commented:
The situation is actually a lot more complicated than I described above as I was trying to simplify things.  There are more tables (e.g. TableC and TableD) involved through joins in the SELECT statement 2 and TableA has triggers that update TableC and TableD.  Is it possible to identify exactly which table is the locked resource from the error log?
0
 
Vitor MontalvãoMSSQL Senior EngineerCommented:
Ok. If there's more tables than it's like that you are having really deadlocks.
You should check if UPDATE and SELECT are using the best indexes. Usually deadlock happens when processing a big amount of data. Having the correct indexes, will be faster enough to process requests avoiding deadlocks.
If indexes are ok, then you can use a workaround, that's locking hints. The problem is that you never know if you'll work with dirty data.

Use SELECT columns FROM TableA with (nolock), TableB with (nolock), ...

This avoid locks on table, but will bring all data that wasn't be commited and can be rolled back.

Good luck
0
 
nicksbellAuthor Commented:
ok, I will try that.  It might take a while before I can be sure it worked as the deadlocks don't happen all the time but you have been very helpful so you can have the points.

Thanks for your help.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

Join & Write a Comment

Featured Post

Get your problem seen by more experts

Be seen. Boost your question’s priority for more expert views and faster solutions

  • 3
  • 3
Tackle projects and never again get stuck behind a technical roadblock.
Join Now