![]() | |
![]() |
| | Thread Tools | Display Modes |
#1
| |||
| |||
|
#2
| |||
| |||
|
|
I tried to troubleshoot a deadlocking issue with the ETL jobs. And I enabled tracing through DBCC TRACEON (1222, 1204, -1). I can see that it is on when I do DBCC TRACESTATUS. But it captured NO deadlock information. Why it did not trap any info? And is there any other alternatives I have in capturing the deadlock incidents? |
#3
| |||
| |||
|
|
xo (xo555... (AT) gmail (DOT) com) writes: I tried to troubleshoot a deadlocking issue with the ETL jobs. And I enabled tracing through DBCC TRACEON (1222, 1204, -1). I can see that it is on when I do DBCC TRACESTATUS. But it captured NO deadlock information. Why it did not trap any info? And is there any other alternatives I have in capturing the deadlock incidents? I know I tested that the other day, but it was on SQL 2005 SP3 or SQL 2008 SP1. But maybe you added one too many. 1222 is suffcient. 1204 is the old deadlock trace which is more difficult to understand. You can also enable the deadlock trace by adding ;-T1222 to the startup paramerters for you instance in SQL Server Configuration Manager. This forces a server restart obviously. And since some people misunderstand what a deadlock is: you did really have a deadlock with a process getting an error about being a deadlock victim? -- Erland Sommarskog, SQL Server MVP, esq... (AT) sommarskog (DOT) se Links for SQL Server Books Online: SQL 2008:http://msdn.microsoft.com/en-us/sqlserver/cc514207.aspx SQL 2005:http://msdn.microsoft.com/en-us/sqlserver/bb895970.aspx SQL 2000:http://www.microsoft.com/sql/prodinf...ons/books.mspx |
#4
| |||
| |||
|
|
I suspect the processes encountered blocking instead of deadlocking since SQL server error log did not capture any info. But the application folks keep insisting there was deadlocking and provided the following log info from the application side. |
![]() |
| Thread Tools | |
| Display Modes | |
| |