Showing posts with label index. Show all posts
Showing posts with label index. Show all posts

Tuesday, March 27, 2012

Deadlocks "again"

Hi
I am getting the same deadlock on our SQL 2K server but with different SPID
Ids throughout the day.
I know what tables and Index information from the KEY: information , and
that is it performing an exclusive lock. What i cannot figure out is what
to do to help resolve this.
Do anyone have any tips? Here is the deadlock results: -
Deadlock encountered ... Printing deadlock information
Wait-for graph
Node:1
KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
Grant List 1::
Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec0x77D6D550)
Value:0x46951760 Cost0/F08)
Node:2
KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
Grant List 2::
Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
Value:0x51983620 Cost0/714)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
Value:0x51983620 Cost0/714)
Many Thanks
Hi Hush
Have you identified the SQL statements that cause the deadlock and tried to
optimize the queries/indexes so that the locks resolve faster. The dump
specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
Regards
Charl
http://www.sqlserver.co.za
"Hush" wrote:

> Hi
> I am getting the same deadlock on our SQL 2K server but with different SPID
> Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec0x77D6D550)
> Value:0x46951760 Cost0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
>
> Many Thanks
>
>
|||See if these help:
http://msdn.microsoft.com/library/de...tabse_5xrn.asp
Troubleshooting Deadlocks
http://www.support.microsoft.com/?id=224453 Blocking Problems
http://www.support.microsoft.com/?id=271509 How to monitor SQL 2000
Blocking
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:uzWvhdOSGHA.5156@.TK2MSFTNGP10.phx.gbl...
> Hi
> I am getting the same deadlock on our SQL 2K server but with different
> SPID Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0
> Ec0x77D6D550) Value:0x46951760 Cost0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
>
> Many Thanks
>
|||Hi Charl
Thanks for your reply:
I am currently running a SQL Profiler - How do i look for the RPC event? I
have included Excution Plan and the SQL locks events in the profiler.
What i am alittle concerned about is that the table in question has on index
(Clustered Index) and out of the 7 Columns in the table 6 of them is
assigned to clustered index. Is that good practice?
I am a non SQL Developer DBA....so i am a little stuck with this.
Many Thanks
"Charl" <Charl@.discussions.microsoft.com> wrote in message
news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...[vbcol=seagreen]
> Hi Hush
> Have you identified the SQL statements that cause the deadlock and tried
> to
> optimize the queries/indexes so that the locks resolve faster. The dump
> specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
> Regards
> Charl
> --
> http://www.sqlserver.co.za
>
> "Hush" wrote:
|||While there are always exceptions having that many columns in a clustered
index is usually not a good idea. Since the leaf level of the clustered
index is the actual data there is little to gain by clustering on so many
columns. Usually you can make the index selective enough on just a few and
it is always a good idea to keep the clustered index narrow since the
clustered index key is appended to the end of any nonclustered indexes as
well. If you are updating any of the 6 columns in the clustered index there
is a prime candidate for deadlocks since it has to physically move the
entire row.
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:ekTgocPSGHA.424@.TK2MSFTNGP12.phx.gbl...
> Hi Charl
> Thanks for your reply:
> I am currently running a SQL Profiler - How do i look for the RPC event?
> I have included Excution Plan and the SQL locks events in the profiler.
> What i am alittle concerned about is that the table in question has on
> index (Clustered Index) and out of the 7 Columns in the table 6 of them is
> assigned to clustered index. Is that good practice?
> I am a non SQL Developer DBA....so i am a little stuck with this.
> Many Thanks
>
> "Charl" <Charl@.discussions.microsoft.com> wrote in message
> news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...
>

Deadlocks "again"

Hi
I am getting the same deadlock on our SQL 2K server but with different SPID
Ids throughout the day.
I know what tables and Index information from the KEY: information , and
that is it performing an exclusive lock. What i cannot figure out is what
to do to help resolve this.
Do anyone have any tips? Here is the deadlock results: -
Deadlock encountered ... Printing deadlock information
Wait-for graph
Node:1
KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
Grant List 1::
Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec:(0x77D6D550)
Value:0x46951760 Cost:(0/F08)
Node:2
KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
Grant List 2::
Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
Value:0x51983620 Cost:(0/714)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
Value:0x51983620 Cost:(0/714)
Many ThanksHi Hush
Have you identified the SQL statements that cause the deadlock and tried to
optimize the queries/indexes so that the locks resolve faster. The dump
specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
Regards
Charl
--
http://www.sqlserver.co.za
"Hush" wrote:
> Hi
> I am getting the same deadlock on our SQL 2K server but with different SPID
> Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec:(0x77D6D550)
> Value:0x46951760 Cost:(0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
> Value:0x51983620 Cost:(0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
> Value:0x51983620 Cost:(0/714)
>
> Many Thanks
>
>|||See if these help:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/trblsql/tr_servdatabse_5xrn.asp
Troubleshooting Deadlocks
http://www.support.microsoft.com/?id=224453 Blocking Problems
http://www.support.microsoft.com/?id=271509 How to monitor SQL 2000
Blocking
--
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:uzWvhdOSGHA.5156@.TK2MSFTNGP10.phx.gbl...
> Hi
> I am getting the same deadlock on our SQL 2K server but with different
> SPID Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0
> Ec:(0x77D6D550) Value:0x46951760 Cost:(0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
> Value:0x51983620 Cost:(0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
> Value:0x51983620 Cost:(0/714)
>
> Many Thanks
>|||Hi Charl
Thanks for your reply:
I am currently running a SQL Profiler - How do i look for the RPC event? I
have included Excution Plan and the SQL locks events in the profiler.
What i am alittle concerned about is that the table in question has on index
(Clustered Index) and out of the 7 Columns in the table 6 of them is
assigned to clustered index. Is that good practice?
I am a non SQL Developer DBA....so i am a little stuck with this.
Many Thanks
"Charl" <Charl@.discussions.microsoft.com> wrote in message
news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...
> Hi Hush
> Have you identified the SQL statements that cause the deadlock and tried
> to
> optimize the queries/indexes so that the locks resolve faster. The dump
> specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
> Regards
> Charl
> --
> http://www.sqlserver.co.za
>
> "Hush" wrote:
>> Hi
>> I am getting the same deadlock on our SQL 2K server but with different
>> SPID
>> Ids throughout the day.
>> I know what tables and Index information from the KEY: information , and
>> that is it performing an exclusive lock. What i cannot figure out is
>> what
>> to do to help resolve this.
>> Do anyone have any tips? Here is the deadlock results: -
>> Deadlock encountered ... Printing deadlock information
>> Wait-for graph
>> Node:1
>> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
>> Grant List 1::
>> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64
>> ECID:0
>> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
>> Input Buf: RPC Event: sp_execute;1
>> Requested By:
>> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0
>> Ec:(0x77D6D550)
>> Value:0x46951760 Cost:(0/F08)
>> Node:2
>> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
>> Grant List 2::
>> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61
>> ECID:0
>> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
>> Input Buf: RPC Event: sp_execute;1
>> Requested By:
>> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
>> Value:0x51983620 Cost:(0/714)
>> Victim Resource Owner:
>> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
>> Value:0x51983620 Cost:(0/714)
>>
>> Many Thanks
>>|||While there are always exceptions having that many columns in a clustered
index is usually not a good idea. Since the leaf level of the clustered
index is the actual data there is little to gain by clustering on so many
columns. Usually you can make the index selective enough on just a few and
it is always a good idea to keep the clustered index narrow since the
clustered index key is appended to the end of any nonclustered indexes as
well. If you are updating any of the 6 columns in the clustered index there
is a prime candidate for deadlocks since it has to physically move the
entire row.
--
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:ekTgocPSGHA.424@.TK2MSFTNGP12.phx.gbl...
> Hi Charl
> Thanks for your reply:
> I am currently running a SQL Profiler - How do i look for the RPC event?
> I have included Excution Plan and the SQL locks events in the profiler.
> What i am alittle concerned about is that the table in question has on
> index (Clustered Index) and out of the 7 Columns in the table 6 of them is
> assigned to clustered index. Is that good practice?
> I am a non SQL Developer DBA....so i am a little stuck with this.
> Many Thanks
>
> "Charl" <Charl@.discussions.microsoft.com> wrote in message
> news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...
>> Hi Hush
>> Have you identified the SQL statements that cause the deadlock and tried
>> to
>> optimize the queries/indexes so that the locks resolve faster. The dump
>> specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
>> Regards
>> Charl
>> --
>> http://www.sqlserver.co.za
>>
>> "Hush" wrote:
>> Hi
>> I am getting the same deadlock on our SQL 2K server but with different
>> SPID
>> Ids throughout the day.
>> I know what tables and Index information from the KEY: information , and
>> that is it performing an exclusive lock. What i cannot figure out is
>> what
>> to do to help resolve this.
>> Do anyone have any tips? Here is the deadlock results: -
>> Deadlock encountered ... Printing deadlock information
>> Wait-for graph
>> Node:1
>> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
>> Grant List 1::
>> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64
>> ECID:0
>> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
>> Input Buf: RPC Event: sp_execute;1
>> Requested By:
>> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0
>> Ec:(0x77D6D550)
>> Value:0x46951760 Cost:(0/F08)
>> Node:2
>> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
>> Grant List 2::
>> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61
>> ECID:0
>> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
>> Input Buf: RPC Event: sp_execute;1
>> Requested By:
>> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
>> Value:0x51983620 Cost:(0/714)
>> Victim Resource Owner:
>> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec:(0x7E9EF550)
>> Value:0x51983620 Cost:(0/714)
>>
>> Many Thanks
>>
>

Deadlocks "again"

Hi
I am getting the same deadlock on our SQL 2K server but with different SPID
Ids throughout the day.
I know what tables and Index information from the KEY: information , and
that is it performing an exclusive lock. What i cannot figure out is what
to do to help resolve this.
Do anyone have any tips? Here is the deadlock results: -
Deadlock encountered ... Printing deadlock information
Wait-for graph
Node:1
KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
Grant List 1::
Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec0x77D6D550)
Value:0x46951760 Cost0/F08)
Node:2
KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
Grant List 2::
Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
Input Buf: RPC Event: sp_execute;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
Value:0x51983620 Cost0/714)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
Value:0x51983620 Cost0/714)
Many ThanksHi Hush
Have you identified the SQL statements that cause the deadlock and tried to
optimize the queries/indexes so that the locks resolve faster. The dump
specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
Regards
Charl
http://www.sqlserver.co.za
"Hush" wrote:

> Hi
> I am getting the same deadlock on our SQL 2K server but with different SPI
D
> Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0 Ec0x77D6D550
)
> Value:0x46951760 Cost0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
>
> Many Thanks
>
>|||See if these help:
http://msdn.microsoft.com/library/d...
tabse_5xrn.asp
Troubleshooting Deadlocks
http://www.support.microsoft.com/?id=224453 Blocking Problems
http://www.support.microsoft.com/?id=271509 How to monitor SQL 2000
Blocking
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:uzWvhdOSGHA.5156@.TK2MSFTNGP10.phx.gbl...
> Hi
> I am getting the same deadlock on our SQL 2K server but with different
> SPID Ids throughout the day.
> I know what tables and Index information from the KEY: information , and
> that is it performing an exclusive lock. What i cannot figure out is what
> to do to help resolve this.
> Do anyone have any tips? Here is the deadlock results: -
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> KEY: 6:1618820829:1 (7d009bbca7e6) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 1::
> Owner:0x51983760 Mode: X Flg:0x0 Ref:1 Life:02000000 SPID:64 ECID:0
> SPID: 64 ECID: 0 Statement Type: UPDATE Line #: 136
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: Range-S-U SPID:61 ECID:0
> Ec0x77D6D550) Value:0x46951760 Cost0/F08)
> Node:2
> KEY: 6:1831013604:1 (0c0021774e53) CleanCnt:2 Mode: X Flags: 0x0
> Grant List 2::
> Owner:0x2faa6340 Mode: X Flg:0x0 Ref:2 Life:02000000 SPID:61 ECID:0
> SPID: 61 ECID: 0 Statement Type: SELECT Line #: 1
> Input Buf: RPC Event: sp_execute;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: X SPID:64 ECID:0 Ec0x7E9EF550)
> Value:0x51983620 Cost0/714)
>
> Many Thanks
>|||Hi Charl
Thanks for your reply:
I am currently running a SQL Profiler - How do i look for the RPC event? I
have included Excution Plan and the SQL locks events in the profiler.
What i am alittle concerned about is that the table in question has on index
(Clustered Index) and out of the 7 Columns in the table 6 of them is
assigned to clustered index. Is that good practice?
I am a non SQL Developer DBA....so i am a little stuck with this.
Many Thanks
"Charl" <Charl@.discussions.microsoft.com> wrote in message
news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...[vbcol=seagreen]
> Hi Hush
> Have you identified the SQL statements that cause the deadlock and tried
> to
> optimize the queries/indexes so that the locks resolve faster. The dump
> specify the RPC event as sp_execute,1. Are you executing dynamic SQL ?
> Regards
> Charl
> --
> http://www.sqlserver.co.za
>
> "Hush" wrote:
>|||While there are always exceptions having that many columns in a clustered
index is usually not a good idea. Since the leaf level of the clustered
index is the actual data there is little to gain by clustering on so many
columns. Usually you can make the index selective enough on just a few and
it is always a good idea to keep the clustered index narrow since the
clustered index key is appended to the end of any nonclustered indexes as
well. If you are updating any of the 6 columns in the clustered index there
is a prime candidate for deadlocks since it has to physically move the
entire row.
Andrew J. Kelly SQL MVP
"Hush" <hushdontspamme@.hotmail.com> wrote in message
news:ekTgocPSGHA.424@.TK2MSFTNGP12.phx.gbl...
> Hi Charl
> Thanks for your reply:
> I am currently running a SQL Profiler - How do i look for the RPC event?
> I have included Excution Plan and the SQL locks events in the profiler.
> What i am alittle concerned about is that the table in question has on
> index (Clustered Index) and out of the 7 Columns in the table 6 of them is
> assigned to clustered index. Is that good practice?
> I am a non SQL Developer DBA....so i am a little stuck with this.
> Many Thanks
>
> "Charl" <Charl@.discussions.microsoft.com> wrote in message
> news:F38AA9E6-F580-4F62-A3D6-93C70375D145@.microsoft.com...
>

DeadLocking

I need help.
We keep having deadlocking. The deadlocking trace points me to a statistic
update. The KEY: 5:242972092:25 index lock it points to is a SQL Server
automatically created statistic. It is on a foreign key column.
I have tried turning autoUpdate Stats off and we still get the deadlock.
Trace Listed below. Does anyone have any ideas? I have never seen a deadlock
on a statistic.
01/12/2006 13:36:30,spid4,Unknown,Node:1
01/12/2006 13:36:30,spid4,Unknown,KEY: 5:242972092:1 (de001a40a963)
CleanCnt:1 Mode: X Flags: 0x0
01/12/2006 13:36:30,spid4,Unknown,Grant List 3::
01/12/2006 13:36:30,spid4,Unknown,Owner:0x2e84d360 Mode: X Flg:0x0
Ref:0 Life:02000000 SPID:61 ECID:0
01/12/2006 13:36:30,spid4,Unknown,SPID: 61 ECID: 0 Statement Type: UPDATE
Line #: 82
01/12/2006 13:36:30,spid4,Unknown,Input Buf: RPC Event:
up_updateShipmentRequestLine;1
01/12/2006 13:36:30,spid4,Unknown,Requested By:
01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: S
SPID:56 ECID:0 Ec:(0x52255528) Value:0x71aa7cc0 Cost:(0/0)
01/12/2006 13:36:30,spid4,Unknown,
01/12/2006 13:36:30,spid4,Unknown,Node:2
01/12/2006 13:36:30,spid4,Unknown,KEY: 5:242972092:25 (be027cd3b404)
CleanCnt:1 Mode: S Flags: 0x0
01/12/2006 13:36:30,spid4,Unknown,Grant List 3::
01/12/2006 13:36:30,spid4,Unknown,Owner:0x4e241860 Mode: S Flg:0x0
Ref:0 Life:02000000 SPID:56 ECID:0
01/12/2006 13:36:30,spid4,Unknown,SPID: 56 ECID: 0 Statement Type: SELECT
Line #: 9
01/12/2006 13:36:30,spid4,Unknown,Input Buf: RPC Event:
up_findShipmentRequestLineByShipmentRequ
estNumberAndLineNumber;1
01/12/2006 13:36:30,spid4,Unknown,Requested By:
01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: X
SPID:61 ECID:0 Ec:(0x235D5528) Value:0x5bc13d40 Cost:(0/C4)
01/12/2006 13:36:30,spid4,Unknown,Victim Resource Owner:
01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: S
SPID:56 ECID:0 Ec:(0x52255528) Value:0x71aa7cc0 Cost:(0/0)I see an exclusive lock generated by:
UPDATE Line #: 82 in up_updateShipmentRequestLine;1
and a shared lock generated by
SELECT Line #: 9 in
up_findShipmentRequestLineByShipmentRequ
estNumberAndLineNumber;1
You may want to look in the code in these two stored procedures (?). You may
be accessing tables in reverse order.
Probably the fix should go into the [up_updateShipmentRequestLine].
If you have
SELECT @.bExists = Field1 FROM Table1
and then
IF @.bExists = someVal
UPDATE Table1 ...
Instead do first:
UPDATE Table1 SET Field1 = @.Val1
IF @.@.ROWCOUNT == 0
INSERT ...
Ok. I'm making assumptions here since I do not know your code but the rule
is that you want to get the highest lock since the beginning of the sproc an
d
there are many ways you can do that. One is above.
If you do not want to change the logic of the code, place a Locking Hints
using
WITH( ... )
for example WITH(UPDLOCK).
If you want more details then you need to post some code so I can point you
exactly to code that generates the deadlock.
"JI" wrote:

> I need help.
> We keep having deadlocking. The deadlocking trace points me to a statistic
> update. The KEY: 5:242972092:25 index lock it points to is a SQL Server
> automatically created statistic. It is on a foreign key column.
> I have tried turning autoUpdate Stats off and we still get the deadlock.
> Trace Listed below. Does anyone have any ideas? I have never seen a deadlo
ck
> on a statistic.
> 01/12/2006 13:36:30,spid4,Unknown,Node:1
> 01/12/2006 13:36:30,spid4,Unknown,KEY: 5:242972092:1 (de001a40a963)
> CleanCnt:1 Mode: X Flags: 0x0
> 01/12/2006 13:36:30,spid4,Unknown,Grant List 3::
> 01/12/2006 13:36:30,spid4,Unknown,Owner:0x2e84d360 Mode: X Flg:0x0
> Ref:0 Life:02000000 SPID:61 ECID:0
> 01/12/2006 13:36:30,spid4,Unknown,SPID: 61 ECID: 0 Statement Type: UPDATE
> Line #: 82
> 01/12/2006 13:36:30,spid4,Unknown,Input Buf: RPC Event:
> up_updateShipmentRequestLine;1
> 01/12/2006 13:36:30,spid4,Unknown,Requested By:
> 01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: S
> SPID:56 ECID:0 Ec:(0x52255528) Value:0x71aa7cc0 Cost:(0/0)
> 01/12/2006 13:36:30,spid4,Unknown,
> 01/12/2006 13:36:30,spid4,Unknown,Node:2
> 01/12/2006 13:36:30,spid4,Unknown,KEY: 5:242972092:25 (be027cd3b404)
> CleanCnt:1 Mode: S Flags: 0x0
> 01/12/2006 13:36:30,spid4,Unknown,Grant List 3::
> 01/12/2006 13:36:30,spid4,Unknown,Owner:0x4e241860 Mode: S Flg:0x0
> Ref:0 Life:02000000 SPID:56 ECID:0
> 01/12/2006 13:36:30,spid4,Unknown,SPID: 56 ECID: 0 Statement Type: SELECT
> Line #: 9
> 01/12/2006 13:36:30,spid4,Unknown,Input Buf: RPC Event:
> up_findShipmentRequestLineByShipmentRequ
estNumberAndLineNumber;1
> 01/12/2006 13:36:30,spid4,Unknown,Requested By:
> 01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: X
> SPID:61 ECID:0 Ec:(0x235D5528) Value:0x5bc13d40 Cost:(0/C4)
> 01/12/2006 13:36:30,spid4,Unknown,Victim Resource Owner:
> 01/12/2006 13:36:30,spid4,Unknown,ResType:LockOwner
Stype:'OR' Mode: S
> SPID:56 ECID:0 Ec:(0x52255528) Value:0x71aa7cc0 Cost:(0/0)
>
>|||The update proc is one that I wrote a proc generator to create. It does a
simple update...it does not access any other or the same table before the
update. The interesting thing with the deadlock trace information is the
index that is says deadlocks is a statistic. One created by SQL Server...
I will post the update shipment request line proc below anyway.
alter proc [dbo].[up_updateShipmentRequestLine]
@.iError int OUTPUT
,@.guidShipmentRequestLineId uniqueidentifier
,@.guidShipmentRequestId uniqueidentifier
,@.iLineNumber int
,@.guidLotId uniqueidentifier
,@.sPurchaseOrderNumber char(50)
,@.sFullLotInd char(1)
,@.iMinimumCount int
,@.daDateNeeded datetime
,@.dcQuantity decimal(18,0)
,@.guidDestinationPlantId uniqueidentifier
,@.guidShipmentStatusId uniqueidentifier
,@.sShippingGroup char(3)
,@.sLineCreateUserName char(50)
,@.daLineCreateDate datetime
,@.sLineModifyUserName char(50)
,@.daLineModifyDate datetime
,@.daModifyDateTime datetime
,@.guidModifyUserId uniqueidentifier
,@.guidReferenceId uniqueidentifier
,@.useBitMap char(1) = 'F'
as
begin
Set NoCount On
Declare @.iCnt int
,@.bitMap varbinary(10)
,@.bitMapByte1 int
,@.bitMapByte2 int
,@.bitMapByte3 int
,@.bitMapByte4 int
,@.bitMapByte5 int
,@.bitMapByte6 int
,@.bitMapByte7 int
,@.bitMapByte8 int
,@.bitMapByte9 int
,@.bitMapByte10 int
If @.useBitMap = 'T' Begin
Select @.bitMapByte1 = Case When @.guidShipmentRequestLineId is null Then 0
Else Power(2,0) End
+ Case When @.guidShipmentRequestId is null Then 0 Else Power(2,1) End
+ Case When @.iLineNumber is null Then 0 Else Power(2,2) End
+ Case When @.guidLotId is null Then 0 Else Power(2,3) End
+ Case When @.sPurchaseOrderNumber is null Then 0 Else Power(2,4) End
+ Case When @.sFullLotInd is null Then 0 Else Power(2,5) End
+ Case When @.iMinimumCount is null Then 0 Else Power(2,6) End
+ Case When @.daDateNeeded is null Then 0 Else Power(2,7) End
Select @.bitMapByte2 = Case When @.dcQuantity is null Then 0 Else Power(2,0)
End
+ Case When @.guidDestinationPlantId is null Then 0 Else Power(2,1) End
+ Case When @.guidShipmentStatusId is null Then 0 Else Power(2,2) End
+ Case When @.sShippingGroup is null Then 0 Else Power(2,3) End
+ Case When @.sLineCreateUserName is null Then 0 Else Power(2,4) End
+ Case When @.daLineCreateDate is null Then 0 Else Power(2,5) End
+ Case When @.sLineModifyUserName is null Then 0 Else Power(2,6) End
+ Case When @.daLineModifyDate is null Then 0 Else Power(2,7) End
Select @.bitMapByte3 = Case When @.daModifyDateTime is null Then 0 Else
Power(2,2) End
+ Case When @.guidModifyUserId is null Then 0 Else Power(2,3) End
+ Case When @.guidReferenceId is null Then 0 Else Power(2,6) End
select @.bitmap = convert(binary(1),isNull(@.bitMapByte1,0)
)
+convert(binary(1),isNull(@.bitMapByte2,0
))
+convert(binary(1),isNull(@.bitMapByte3,0
))
+convert(binary(1),isNull(@.bitMapByte4,0
))
+convert(binary(1),isNull(@.bitMapByte5,0
))
+convert(binary(1),isNull(@.bitMapByte6,0
))
+convert(binary(1),isNull(@.bitMapByte7,0
))
+convert(binary(1),isNull(@.bitMapByte8,0
))
+convert(binary(1),isNull(@.bitMapByte9,0
))
+convert(binary(1),isNull(@.bitMapByte10,
0))
End
begin transaction
Update ShipmentRequestLine
Set [ShipmentRequestLineId] = Case isNull(substring(@.bitmap,1,1),1) & 1 when
1 Then @.guidShipmentRequestLineId Else [ShipmentRequestLineId] End
,[ShipmentRequestId] = Case isNull(substring(@.bitmap,1,1),2) & 2 when 2 Then
@.guidShipmentRequestId Else [ShipmentRequestId] End
,[LineNumber] = Case isNull(substring(@.bitmap,1,1),4) & 4 when 4 Then
@.iLineNumber Else [LineNumber] End
,[LotId] = Case isNull(substring(@.bitmap,1,1),8) & 8 when 8 Then @.guidLotId
Else [LotId] End
,[PurchaseOrderNumber] = Case isNull(substring(@.bitmap,1,1),16) & 16 when 16
Then @.sPurchaseOrderNumber Else [PurchaseOrderNumber] End
,[FullLotInd] = Case isNull(substring(@.bitmap,1,1),32) & 32 when 32 Then
@.sFullLotInd Else [FullLotInd] End
,[MinimumCount] = Case isNull(substring(@.bitmap,1,1),64) & 64 when 64 Then
@.iMinimumCount Else [MinimumCount] End
,[DateNeeded] = Case isNull(substring(@.bitmap,1,1),128) & 128 when 128 Then
@.daDateNeeded Else [DateNeeded] End
,[Quantity] = Case isNull(substring(@.bitmap,2,1),1) & 1 when 1 Then
@.dcQuantity Else [Quantity] End
,[DestinationPlantId] = Case isNull(substring(@.bitmap,2,1),2) & 2 when 2
Then @.guidDestinationPlantId Else [DestinationPlantId] End
,[ShipmentStatusId] = Case isNull(substring(@.bitmap,2,1),4) & 4 when 4 Then
@.guidShipmentStatusId Else [ShipmentStatusId] End
,[ShippingGroup] = Case isNull(substring(@.bitmap,2,1),8) & 8 when 8 Then
@.sShippingGroup Else [ShippingGroup] End
,[LineCreateUserName] = Case isNull(substring(@.bitmap,2,1),16) & 16 when 16
Then @.sLineCreateUserName Else [LineCreateUserName] End
,[LineCreateDate] = Case isNull(substring(@.bitmap,2,1),32) & 32 when 32 Then
@.daLineCreateDate Else [LineCreateDate] End
,[LineModifyUserName] = Case isNull(substring(@.bitmap,2,1),64) & 64 when 64
Then @.sLineModifyUserName Else [LineModifyUserName] End
,[LineModifyDate] = Case isNull(substring(@.bitmap,2,1),128) & 128 when 128
Then @.daLineModifyDate Else [LineModifyDate] End
,[ModifyDateTime] = isNull(@.daModifyDateTime,getDate())
,[ModifyUserId] = Case isNull(substring(@.bitmap,3,1),8) & 8 when 8 Then
@.guidModifyUserId Else [ModifyUserId] End
,[ReferenceId] = Case isNull(substring(@.bitmap,3,1),64) & 64 when 64 Then
@.guidReferenceId Else [ReferenceId] End
where ShipmentRequestLineId = @.guidShipmentRequestLineId
SELECT @.iError=@.@.ERROR, @.iCnt = @.@.rowCount
If @.iError <> 0 begin
Rollback Transaction
End
Else Begin
Commit Transaction
End
Return @.iCnt
End
"Daniel P." <DanielP@.discussions.microsoft.com> wrote in message
news:6FC61F2E-A1FD-43F1-917A-9A3BD6A7E782@.microsoft.com...
>I see an exclusive lock generated by:
> UPDATE Line #: 82 in up_updateShipmentRequestLine;1
> and a shared lock generated by
> SELECT Line #: 9 in
> up_findShipmentRequestLineByShipmentRequ
estNumberAndLineNumber;1
> You may want to look in the code in these two stored procedures (?). You
> may
> be accessing tables in reverse order.
> Probably the fix should go into the [up_updateShipmentRequestLine].
> If you have
> SELECT @.bExists = Field1 FROM Table1
> and then
> IF @.bExists = someVal
> UPDATE Table1 ...
> Instead do first:
> UPDATE Table1 SET Field1 = @.Val1
> IF @.@.ROWCOUNT == 0
> INSERT ...
> Ok. I'm making assumptions here since I do not know your code but the rule
> is that you want to get the highest lock since the beginning of the sproc
> and
> there are many ways you can do that. One is above.
> If you do not want to change the logic of the code, place a Locking Hints
> using
> WITH( ... )
> for example WITH(UPDLOCK).
> If you want more details then you need to post some code so I can point
> you
> exactly to code that generates the deadlock.
>
> "JI" wrote:
>|||Set the transaction isolation level as serializable or add the hint
WITH(TABLOCKX) and see if you still get the deadlock.
"JI" wrote:

> The update proc is one that I wrote a proc generator to create. It does a
> simple update...it does not access any other or the same table before the
> update. The interesting thing with the deadlock trace information is the
> index that is says deadlocks is a statistic. One created by SQL Server...
> I will post the update shipment request line proc below anyway.
> alter proc [dbo].[up_updateShipmentRequestLine]
> @.iError int OUTPUT
> ,@.guidShipmentRequestLineId uniqueidentifier
> ,@.guidShipmentRequestId uniqueidentifier
> ,@.iLineNumber int
> ,@.guidLotId uniqueidentifier
> ,@.sPurchaseOrderNumber char(50)
> ,@.sFullLotInd char(1)
> ,@.iMinimumCount int
> ,@.daDateNeeded datetime
> ,@.dcQuantity decimal(18,0)
> ,@.guidDestinationPlantId uniqueidentifier
> ,@.guidShipmentStatusId uniqueidentifier
> ,@.sShippingGroup char(3)
> ,@.sLineCreateUserName char(50)
> ,@.daLineCreateDate datetime
> ,@.sLineModifyUserName char(50)
> ,@.daLineModifyDate datetime
> ,@.daModifyDateTime datetime
> ,@.guidModifyUserId uniqueidentifier
> ,@.guidReferenceId uniqueidentifier
> ,@.useBitMap char(1) = 'F'
> as
> begin
> Set NoCount On
> Declare @.iCnt int
> ,@.bitMap varbinary(10)
> ,@.bitMapByte1 int
> ,@.bitMapByte2 int
> ,@.bitMapByte3 int
> ,@.bitMapByte4 int
> ,@.bitMapByte5 int
> ,@.bitMapByte6 int
> ,@.bitMapByte7 int
> ,@.bitMapByte8 int
> ,@.bitMapByte9 int
> ,@.bitMapByte10 int
> If @.useBitMap = 'T' Begin
> Select @.bitMapByte1 = Case When @.guidShipmentRequestLineId is null Then 0
> Else Power(2,0) End
> + Case When @.guidShipmentRequestId is null Then 0 Else Power(2,1) End
> + Case When @.iLineNumber is null Then 0 Else Power(2,2) End
> + Case When @.guidLotId is null Then 0 Else Power(2,3) End
> + Case When @.sPurchaseOrderNumber is null Then 0 Else Power(2,4) End
> + Case When @.sFullLotInd is null Then 0 Else Power(2,5) End
> + Case When @.iMinimumCount is null Then 0 Else Power(2,6) End
> + Case When @.daDateNeeded is null Then 0 Else Power(2,7) End
> Select @.bitMapByte2 = Case When @.dcQuantity is null Then 0 Else Power(2,0)
> End
> + Case When @.guidDestinationPlantId is null Then 0 Else Power(2,1) End
> + Case When @.guidShipmentStatusId is null Then 0 Else Power(2,2) End
> + Case When @.sShippingGroup is null Then 0 Else Power(2,3) End
> + Case When @.sLineCreateUserName is null Then 0 Else Power(2,4) End
> + Case When @.daLineCreateDate is null Then 0 Else Power(2,5) End
> + Case When @.sLineModifyUserName is null Then 0 Else Power(2,6) End
> + Case When @.daLineModifyDate is null Then 0 Else Power(2,7) End
> Select @.bitMapByte3 = Case When @.daModifyDateTime is null Then 0 Else
> Power(2,2) End
> + Case When @.guidModifyUserId is null Then 0 Else Power(2,3) End
> + Case When @.guidReferenceId is null Then 0 Else Power(2,6) End
> select @.bitmap = convert(binary(1),isNull(@.bitMapByte1,0)
)
> +convert(binary(1),isNull(@.bitMapByte2,0
))
> +convert(binary(1),isNull(@.bitMapByte3,0
))
> +convert(binary(1),isNull(@.bitMapByte4,0
))
> +convert(binary(1),isNull(@.bitMapByte5,0
))
> +convert(binary(1),isNull(@.bitMapByte6,0
))
> +convert(binary(1),isNull(@.bitMapByte7,0
))
> +convert(binary(1),isNull(@.bitMapByte8,0
))
> +convert(binary(1),isNull(@.bitMapByte9,0
))
> +convert(binary(1),isNull(@.bitMapByte10,
0))
> End
>
> begin transaction
> Update ShipmentRequestLine
> Set [ShipmentRequestLineId] = Case isNull(substring(@.bitmap,1,1),1) & 1 when
> 1 Then @.guidShipmentRequestLineId Else [ShipmentRequestLineId] End
> ,[ShipmentRequestId] = Case isNull(substring(@.bitmap,1,1),2) & 2 when 2 Then
> @.guidShipmentRequestId Else [ShipmentRequestId] End
> ,[LineNumber] = Case isNull(substring(@.bitmap,1,1),4) & 4 when 4 Then
> @.iLineNumber Else [LineNumber] End
> ,[LotId] = Case isNull(substring(@.bitmap,1,1),8) & 8 when 8 Then @.guidLotId
> Else [LotId] End
> ,[PurchaseOrderNumber] = Case isNull(substring(@.bitmap,1,1),16) & 16 when 16
> Then @.sPurchaseOrderNumber Else [PurchaseOrderNumber] End
> ,[FullLotInd] = Case isNull(substring(@.bitmap,1,1),32) & 32 when 32 Then
> @.sFullLotInd Else [FullLotInd] End
> ,[MinimumCount] = Case isNull(substring(@.bitmap,1,1),64) & 64 when 64 Then
> @.iMinimumCount Else [MinimumCount] End
> ,[DateNeeded] = Case isNull(substring(@.bitmap,1,1),128) & 128 when 128 Then
> @.daDateNeeded Else [DateNeeded] End
> ,[Quantity] = Case isNull(substring(@.bitmap,2,1),1) & 1 when 1 Then
> @.dcQuantity Else [Quantity] End
> ,[DestinationPlantId] = Case isNull(substring(@.bitmap,2,1),2) & 2 when 2
> Then @.guidDestinationPlantId Else [DestinationPlantId] End
> ,[ShipmentStatusId] = Case isNull(substring(@.bitmap,2,1),4) & 4 when 4 Then
> @.guidShipmentStatusId Else [ShipmentStatusId] End
> ,[ShippingGroup] = Case isNull(substring(@.bitmap,2,1),8) & 8 when 8 Then
> @.sShippingGroup Else [ShippingGroup] End
> ,[LineCreateUserName] = Case isNull(substring(@.bitmap,2,1),16) & 16 when 16
> Then @.sLineCreateUserName Else [LineCreateUserName] End
> ,[LineCreateDate] = Case isNull(substring(@.bitmap,2,1),32) & 32 when 32 Then
> @.daLineCreateDate Else [LineCreateDate] End
> ,[LineModifyUserName] = Case isNull(substring(@.bitmap,2,1),64) & 64 when 64
> Then @.sLineModifyUserName Else [LineModifyUserName] End
> ,[LineModifyDate] = Case isNull(substring(@.bitmap,2,1),128) & 128 when 128
> Then @.daLineModifyDate Else [LineModifyDate] End
> ,[ModifyDateTime] = isNull(@.daModifyDateTime,getDate())
> ,[ModifyUserId] = Case isNull(substring(@.bitmap,3,1),8) & 8 when 8 Then
> @.guidModifyUserId Else [ModifyUserId] End
> ,[ReferenceId] = Case isNull(substring(@.bitmap,3,1),64) & 64 when 64 Then
> @.guidReferenceId Else [ReferenceId] End
> where ShipmentRequestLineId = @.guidShipmentRequestLineId
> SELECT @.iError=@.@.ERROR, @.iCnt = @.@.rowCount
>
> If @.iError <> 0 begin
> Rollback Transaction
> End
> Else Begin
> Commit Transaction
> End
> Return @.iCnt
> End
> "Daniel P." <DanielP@.discussions.microsoft.com> wrote in message
> news:6FC61F2E-A1FD-43F1-917A-9A3BD6A7E782@.microsoft.com...
>
>

Deadlocked on the same resource (same index)

I'm seeing a deadlock issue that traces out the following 1204 report
below. You can see that one process is granted a shared lock (Mode: S)
on the index and another process is granted an exclusive lock on the
same index.
How is that possible? What scenarios could lead to this? I know that
deadlocks can happen over the same resource when one or two processes
are trying to raise the isolation level, but that doesn't seem to be
the case here.
It almost seems like the two processes are requesting locks (that they
already have?) and waiting for the other to release. What scenarios
could lead to this?
Unfortunately I can't show any code. Here is the trace file:
Michael Swart
Wait-for graph
Node:1
KEY: 7:2133582639:3 (180223bc5cb5) CleanCnt:1 Mode: X Flags: 0x0
Grant List 3::
Owner:0x52e00720 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:98
ECID:0
SPID: 98 ECID: 0 Statement Type: UPDATE Line #: 34
Input Buf: RPC Event: sp_executesql;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec0x7C1615D8)
Value:0x52dd7340 Cost0/0)
Node:2
KEY: 7:2133582639:3 (a80172417f28) CleanCnt:1 Mode: S Flags: 0x0
Grant List 0::
Owner:0x52e2e7c0 Mode: S Flg:0x0 Ref:0 Life:00000001 SPID:93
ECID:0
SPID: 93 ECID: 0 Statement Type: INSERT Line #: 2
Input Buf: Language Event: EXEC LoadDataPartitions
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:98 ECID:0 Ec0x5A2E5578)
Value:0x52fa6780 Cost0/1129C)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec0x7C1615D8)
Value:0x52dd7340 Cost0/0)
Michael Swart wrote:
> I'm seeing a deadlock issue that traces out the following 1204 report
> below. You can see that one process is granted a shared lock (Mode: S)
> on the index and another process is granted an exclusive lock on the
> same index.
> How is that possible? What scenarios could lead to this? I know that
> deadlocks can happen over the same resource when one or two processes
> are trying to raise the isolation level, but that doesn't seem to be
> the case here.
The "classic" deadlock scenario is where two processes try to acquire
locks on two resources in different order.

> It almost seems like the two processes are requesting locks (that they
> already have?) and waiting for the other to release. What scenarios
> could lead to this?
Different order of table accesses within two transactions for example.

> Unfortunately I can't show any code. Here is the trace file:
> Michael Swart
<snip/>
Unfortunately I'm no expert at trace file reading. But you can try to
catch the deadlock with Enterprise Manager. Then you can directly see SQL
statements that lead to the deadlock. HTH.
Kind regards
robert

Deadlocked on the same resource (same index)

I'm seeing a deadlock issue that traces out the following 1204 report
below. You can see that one process is granted a shared lock (Mode: S)
on the index and another process is granted an exclusive lock on the
same index.
How is that possible? What scenarios could lead to this? I know that
deadlocks can happen over the same resource when one or two processes
are trying to raise the isolation level, but that doesn't seem to be
the case here.
It almost seems like the two processes are requesting locks (that they
already have') and waiting for the other to release. What scenarios
could lead to this?
Unfortunately I can't show any code. Here is the trace file:
Michael Swart
Wait-for graph
Node:1
KEY: 7:2133582639:3 (180223bc5cb5) CleanCnt:1 Mode: X Flags: 0x0
Grant List 3::
Owner:0x52e00720 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:98
ECID:0
SPID: 98 ECID: 0 Statement Type: UPDATE Line #: 34
Input Buf: RPC Event: sp_executesql;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec0x7C1615D8)
Value:0x52dd7340 Cost0/0)
Node:2
KEY: 7:2133582639:3 (a80172417f28) CleanCnt:1 Mode: S Flags: 0x0
Grant List 0::
Owner:0x52e2e7c0 Mode: S Flg:0x0 Ref:0 Life:00000001 SPID:93
ECID:0
SPID: 93 ECID: 0 Statement Type: INSERT Line #: 2
Input Buf: Language Event: EXEC LoadDataPartitions
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:98 ECID:0 Ec0x5A2E5578)
Value:0x52fa6780 Cost0/1129C)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec0x7C1615D8)
Value:0x52dd7340 Cost0/0)Michael Swart wrote:
> I'm seeing a deadlock issue that traces out the following 1204 report
> below. You can see that one process is granted a shared lock (Mode: S)
> on the index and another process is granted an exclusive lock on the
> same index.
> How is that possible? What scenarios could lead to this? I know that
> deadlocks can happen over the same resource when one or two processes
> are trying to raise the isolation level, but that doesn't seem to be
> the case here.
The "classic" deadlock scenario is where two processes try to acquire
locks on two resources in different order.

> It almost seems like the two processes are requesting locks (that they
> already have') and waiting for the other to release. What scenarios
> could lead to this?
Different order of table accesses within two transactions for example.

> Unfortunately I can't show any code. Here is the trace file:
> Michael Swart
<snip/>
Unfortunately I'm no expert at trace file reading. But you can try to
catch the deadlock with Enterprise Manager. Then you can directly see SQL
statements that lead to the deadlock. HTH.
Kind regards
robertsql

Deadlocked on the same resource (same index)

I'm seeing a deadlock issue that traces out the following 1204 report
below. You can see that one process is granted a shared lock (Mode: S)
on the index and another process is granted an exclusive lock on the
same index.
How is that possible? What scenarios could lead to this? I know that
deadlocks can happen over the same resource when one or two processes
are trying to raise the isolation level, but that doesn't seem to be
the case here.
It almost seems like the two processes are requesting locks (that they
already have') and waiting for the other to release. What scenarios
could lead to this?
Unfortunately I can't show any code. Here is the trace file:
Michael Swart
Wait-for graph
Node:1
KEY: 7:2133582639:3 (180223bc5cb5) CleanCnt:1 Mode: X Flags: 0x0
Grant List 3::
Owner:0x52e00720 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:98
ECID:0
SPID: 98 ECID: 0 Statement Type: UPDATE Line #: 34
Input Buf: RPC Event: sp_executesql;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec:(0x7C1615D8)
Value:0x52dd7340 Cost:(0/0)
Node:2
KEY: 7:2133582639:3 (a80172417f28) CleanCnt:1 Mode: S Flags: 0x0
Grant List 0::
Owner:0x52e2e7c0 Mode: S Flg:0x0 Ref:0 Life:00000001 SPID:93
ECID:0
SPID: 93 ECID: 0 Statement Type: INSERT Line #: 2
Input Buf: Language Event: EXEC LoadDataPartitions
Requested By:
ResType:LockOwner Stype:'OR' Mode: X SPID:98 ECID:0 Ec:(0x5A2E5578)
Value:0x52fa6780 Cost:(0/1129C)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: S SPID:93 ECID:0 Ec:(0x7C1615D8)
Value:0x52dd7340 Cost:(0/0)Michael Swart wrote:
> I'm seeing a deadlock issue that traces out the following 1204 report
> below. You can see that one process is granted a shared lock (Mode: S)
> on the index and another process is granted an exclusive lock on the
> same index.
> How is that possible? What scenarios could lead to this? I know that
> deadlocks can happen over the same resource when one or two processes
> are trying to raise the isolation level, but that doesn't seem to be
> the case here.
The "classic" deadlock scenario is where two processes try to acquire
locks on two resources in different order.
> It almost seems like the two processes are requesting locks (that they
> already have') and waiting for the other to release. What scenarios
> could lead to this?
Different order of table accesses within two transactions for example.
> Unfortunately I can't show any code. Here is the trace file:
> Michael Swart
<snip/>
Unfortunately I'm no expert at trace file reading. But you can try to
catch the deadlock with Enterprise Manager. Then you can directly see SQL
statements that lead to the deadlock. HTH.
Kind regards
robert

Wednesday, March 21, 2012

Deadlock on simple update related to clustered index

I am encountering a deadlock situation, with two threads
running two updates to the same table, if that table has a
clustered index on it that is NOT the primary key, and the
where clause of the UPDATE statement is on the primary
key. Very strange... Here is the test case:
create table x
(id int not null,
lastModified datetime not null,
altkey varchar(3) not null)
GO
CREATE UNIQUE CLUSTERED INDEX IAK_X ON x (altKey)
GO
alter table x add constraint pk_x primary key(id)
GO
insert into x
values (1, getdate(), 'XXX');
Then, from 2 ISQL threads, ran the following code...
begin tran
waitfor time '15:06' -- ensure they start at same time
update x
set lastModified = getdate()
where id = 1;
waitfor delay '000:00:10' -- wait to ensure lock occurs
update x
set lastModified = getdate()
where id = 1;
commit tran;
When I monitor the locks, the following happens:
Thread A successfully performs Update 1
Thread B is blocked as A has Exclusive lock on the row.
Thread B, however, successfully gets a KEY UPDATE lock on
PK_X
Thread A, when it tries to perform Update 2, is blocked
trying to get a KEY UPDATE lock on PK_X, causing the
deadlock.
Even if I then drop the clustered index with
DROP INDEX x.iak_x;
the problem remains.
However, if I NEVER create the clustered index. The
threads both work fine and never encounter a deadlock.
Neither transaction attempts to get a KEY UPDATE lock on
the primary key index PK_X.
We try to use clustered indexes on fields other than the
ID # (one-up number, but NOT an IDENTITY column in this
case), because we encountered deadlocks on Inserts in the
past.
Any help would be greatly appreciated.On Thu, 24 Jul 2003 14:02:58 -0700, "Corey" <chorton1@.austin.rr.com>
wrote:
>Any help would be greatly appreciated.
That's pretty humorous.
I've never gotten into the detailed guts of SQLServer like some around
here, but it sounds to me like you've hit a SQLServer bug. It looks
like SQLServer locks the data record in thread A, but allows thread B
to begin and get a lock on an index entry while waiting for the data,
and voila, deadlock. If that is the case, I'd call it a bug.
I assume it works correctly if you have the PK on id?
J.sql

Monday, March 19, 2012

Deadlock Issue - Cannot pinpoint resource causing contention

All,
Have a deadlock issue - see 1204 trace info below.
After reviewing BOL I cannot ascertain the exact resource (table, page,
index, etc) that is causing the deadlock. I believe it might be a row in a
table (ie - RID: 2:1:81:0 and RID: 2:1:81:1) but I am suspicious about this
and I cannot determine the exact table.
Question - is there something in the trace data that can tell me the exact
resource down to the specific table - assuming it is a table.
Starting deadlock search 75296
Target Resource Owner:
ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0 Ec0xB611B540)
Value:0x2e7feac0
Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
Ec0xB611B540) Value:0x2e7feac0
Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
Ec0x2ED0F590) Value:0x2e893d60
Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
Ec0xB611B540) Value:0x2e7feac0
Deadlock cycle was encountered ... verifying cycle
Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
Ec0x2ED0F590) Value:0x2e893d60 Cost0/80)
Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
Deadlock encountered ... Printing deadlock information
Wait-for graph
Node:1
RID: 2:1:81:0 CleanCnt:1 Mode: X Flags: 0x2
Grant List 0::
Owner:0x2e83b8a0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:54
ECID:0
SPID: 54 ECID: 0 Statement Type: DELETE Line #: 18
Input Buf: RPC Event: dbo.p_ins_equipment_circuit_ref_info;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0 Ec0xB611B540)
Value:0x2e7feac0 Cost0/80)
Node:2
RID: 2:1:81:1 CleanCnt:1 Mode: X Flags: 0x2
Grant List 1::
Owner:0x2e7feaa0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:185
ECID:0
SPID: 185 ECID: 0 Statement Type: DELETE Line #: 18
Input Buf: RPC Event: sp_executesql;1
Requested By:
ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
Value:0x2e893d60 Cost0/80)
Victim Resource Owner:
ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
Value:0x2e893d60 Cost0/80)
End deadlock search 75296 ... a deadlock was found.
Hi
Have you seen
http://msdn.microsoft.com/library/de...abse_5xrn.asp?
I prefer to use sp_blocker_pss80
http://support.microsoft.com/kb/271509/EN-US/
You are having problems with tempdb, so you may want to cut down the usage
as detailed in
parts of
http://msdn.microsoft.com/library/de...netchapt14.asp
Also you may want to implement the suggestions in
http://support.microsoft.com/default...b;en-us;328551
John
"John" <John@.discussions.microsoft.com> wrote in message
news:49B3981C-DDB8-4B37-9606-00F2F6E32504@.microsoft.com...
> All,
> Have a deadlock issue - see 1204 trace info below.
> After reviewing BOL I cannot ascertain the exact resource (table, page,
> index, etc) that is causing the deadlock. I believe it might be a row in
> a
> table (ie - RID: 2:1:81:0 and RID: 2:1:81:1) but I am suspicious about
> this
> and I cannot determine the exact table.
> Question - is there something in the trace data that can tell me the exact
> resource down to the specific table - assuming it is a table.
> Starting deadlock search 75296
> Target Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0 Ec0xB611B540)
> Value:0x2e7feac0
> Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0
> Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
> Ec0x2ED0F590) Value:0x2e893d60
> Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0
>
> Deadlock cycle was encountered ... verifying cycle
> Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
> Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
> Ec0x2ED0F590) Value:0x2e893d60 Cost0/80)
> Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
>
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> RID: 2:1:81:0 CleanCnt:1 Mode: X Flags: 0x2
> Grant List 0::
> Owner:0x2e83b8a0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:54
> ECID:0
> SPID: 54 ECID: 0 Statement Type: DELETE Line #: 18
> Input Buf: RPC Event: dbo.p_ins_equipment_circuit_ref_info;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540)
> Value:0x2e7feac0 Cost0/80)
> Node:2
> RID: 2:1:81:1 CleanCnt:1 Mode: X Flags: 0x2
> Grant List 1::
> Owner:0x2e7feaa0 Mode: X Flg:0x0 Ref:0 Life:02000000
> SPID:185
> ECID:0
> SPID: 185 ECID: 0 Statement Type: DELETE Line #: 18
> Input Buf: RPC Event: sp_executesql;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
> Value:0x2e893d60 Cost0/80)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
> Value:0x2e893d60 Cost0/80)
> End deadlock search 75296 ... a deadlock was found.
> --
>
|||Well - I think I answered my own question after seeing other similar threads.
Using dbcc page it appears the deadlock resource is in tempdb database. Fun.
"John" wrote:

> All,
> Have a deadlock issue - see 1204 trace info below.
> After reviewing BOL I cannot ascertain the exact resource (table, page,
> index, etc) that is causing the deadlock. I believe it might be a row in a
> table (ie - RID: 2:1:81:0 and RID: 2:1:81:1) but I am suspicious about this
> and I cannot determine the exact table.
> Question - is there something in the trace data that can tell me the exact
> resource down to the specific table - assuming it is a table.
> Starting deadlock search 75296
> Target Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0 Ec0xB611B540)
> Value:0x2e7feac0
> Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0
> Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
> Ec0x2ED0F590) Value:0x2e893d60
> Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0
>
> Deadlock cycle was encountered ... verifying cycle
> Node:1 ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
> Node:2 ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0
> Ec0x2ED0F590) Value:0x2e893d60 Cost0/80)
> Cycle: ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0
> Ec0xB611B540) Value:0x2e7feac0 Cost0/80)
>
> Deadlock encountered ... Printing deadlock information
> Wait-for graph
> Node:1
> RID: 2:1:81:0 CleanCnt:1 Mode: X Flags: 0x2
> Grant List 0::
> Owner:0x2e83b8a0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:54
> ECID:0
> SPID: 54 ECID: 0 Statement Type: DELETE Line #: 18
> Input Buf: RPC Event: dbo.p_ins_equipment_circuit_ref_info;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: U SPID:185 ECID:0 Ec0xB611B540)
> Value:0x2e7feac0 Cost0/80)
> Node:2
> RID: 2:1:81:1 CleanCnt:1 Mode: X Flags: 0x2
> Grant List 1::
> Owner:0x2e7feaa0 Mode: X Flg:0x0 Ref:0 Life:02000000 SPID:185
> ECID:0
> SPID: 185 ECID: 0 Statement Type: DELETE Line #: 18
> Input Buf: RPC Event: sp_executesql;1
> Requested By:
> ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
> Value:0x2e893d60 Cost0/80)
> Victim Resource Owner:
> ResType:LockOwner Stype:'OR' Mode: U SPID:54 ECID:0 Ec0x2ED0F590)
> Value:0x2e893d60 Cost0/80)
> End deadlock search 75296 ... a deadlock was found.
> --
>
|||John,
Yes, Yes, Yes, No.
I will probably be reviewing and implementing 328551. Thanks for the heads
up.
"John Bell" wrote:

> Hi
> Have you seen
> http://msdn.microsoft.com/library/de...abse_5xrn.asp?
> I prefer to use sp_blocker_pss80
> http://support.microsoft.com/kb/271509/EN-US/
> You are having problems with tempdb, so you may want to cut down the usage
> as detailed in
> parts of
> http://msdn.microsoft.com/library/de...netchapt14.asp
> Also you may want to implement the suggestions in
> http://support.microsoft.com/default...b;en-us;328551
> John
>
> "John" <John@.discussions.microsoft.com> wrote in message
> news:49B3981C-DDB8-4B37-9606-00F2F6E32504@.microsoft.com...
>
>