Deadlock searches every 5 seconds

Rumor has it that a great way to wait for potential deadlock is to:
DBCC TRACEOn (3605, 1205, -1)
Ive done this for a while and have been please with the resaults. However I
just noticed in the Error Log that a Deadlock search is being done about
every 5 seconds. This is fine, but Im wondering if theres a way that the
search can write to the Error Log only if theres a Deadlock, not every time
it does a search? Also, if I ever needed to "Truncate" the Error Log , how
would I go about it?
The behavior you're seeing is because you've turned on trace flag 1205. If
you turn on trace flag 1204, you'll only get error log output when we find a
deadlock. The overhead of -T1205 is pretty high, and the TF is
undocumented, so I would recommend turning it off and relying on the
documented -T1204 instead.
FYI, the 5 second deadlock search is by design. If we find a deadlock,
though, we will increase the frequency of searches temporarily.
Thanks,
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"ChrisR" <noemail@.bla.com> wrote in message
news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Rumor has it that a great way to wait for potential deadlock is to:
> DBCC TRACEOn (3605, 1205, -1)
> Ive done this for a while and have been please with the resaults. However
> I just noticed in the Error Log that a Deadlock search is being done about
> every 5 seconds. This is fine, but Im wondering if theres a way that the
> search can write to the Error Log only if theres a Deadlock, not every
> time it does a search? Also, if I ever needed to "Truncate" the Error Log
> , how would I go about it?
>
|||Perfect! Thanks.
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>
|||To clarify, Traceon is a Server level setting, right?
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>
|||Hi Chris
DBCC TRACEON is normally session level, but adding the -1 makes it take
effect for all sessions.
To start a fresh errorlog, you can run sp_cycle_errorlog.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
> To clarify, Traceon is a Server level setting, right?
>
> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
> news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
>
|||All sessions in the DB, or the Server?
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
> Hi Chris
> DBCC TRACEON is normally session level, but adding the -1 makes it take
> effect for all sessions.
> To start a fresh errorlog, you can run sp_cycle_errorlog.
> --
> HTH
> --
> Kalen Delaney
> SQL Server MVP
> www.SolidQualityLearning.com
>
> "ChrisR" <noemail@.bla.com> wrote in message
> news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
>
|||All sessions means all connections to the server.
HTH
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uVGZi2hNFHA.2880@.TK2MSFTNGP10.phx.gbl...
> All sessions in the DB, or the Server?
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
>

Deadlock searches every 5 seconds

Rumor has it that a great way to wait for potential deadlock is to:
DBCC TRACEOn (3605, 1205, -1)
Ive done this for a while and have been please with the resaults. However I
just noticed in the Error Log that a Deadlock search is being done about
every 5 seconds. This is fine, but Im wondering if theres a way that the
search can write to the Error Log only if theres a Deadlock, not every time
it does a search? Also, if I ever needed to "Truncate" the Error Log , how
would I go about it?The behavior you're seeing is because you've turned on trace flag 1205. If
you turn on trace flag 1204, you'll only get error log output when we find a
deadlock. The overhead of -T1205 is pretty high, and the TF is
undocumented, so I would recommend turning it off and relying on the
documented -T1204 instead.
FYI, the 5 second deadlock search is by design. If we find a deadlock,
though, we will increase the frequency of searches temporarily.
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"ChrisR" <noemail@.bla.com> wrote in message
news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Rumor has it that a great way to wait for potential deadlock is to:
> DBCC TRACEOn (3605, 1205, -1)
> Ive done this for a while and have been please with the resaults. However
> I just noticed in the Error Log that a Deadlock search is being done about
> every 5 seconds. This is fine, but Im wondering if theres a way that the
> search can write to the Error Log only if theres a Deadlock, not every
> time it does a search? Also, if I ever needed to "Truncate" the Error Log
> , how would I go about it?
>|||Perfect! Thanks.
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>|||To clarify, Traceon is a Server level setting, right?
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>|||Hi Chris
DBCC TRACEON is normally session level, but adding the -1 makes it take
effect for all sessions.
To start a fresh errorlog, you can run sp_cycle_errorlog.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
> To clarify, Traceon is a Server level setting, right?
>
> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
> news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
>|||All sessions in the DB, or the Server?
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
> Hi Chris
> DBCC TRACEON is normally session level, but adding the -1 makes it take
> effect for all sessions.
> To start a fresh errorlog, you can run sp_cycle_errorlog.
> --
> HTH
> --
> Kalen Delaney
> SQL Server MVP
> www.SolidQualityLearning.com
>
> "ChrisR" <noemail@.bla.com> wrote in message
> news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
>|||All sessions means all connections to the server.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uVGZi2hNFHA.2880@.TK2MSFTNGP10.phx.gbl...
> All sessions in the DB, or the Server?
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
>

Deadlock searches every 5 seconds

Rumor has it that a great way to wait for potential deadlock is to:
DBCC TRACEOn (3605, 1205, -1)
Ive done this for a while and have been please with the resaults. However I
just noticed in the Error Log that a Deadlock search is being done about
every 5 seconds. This is fine, but Im wondering if theres a way that the
search can write to the Error Log only if theres a Deadlock, not every time
it does a search? Also, if I ever needed to "Truncate" the Error Log , how
would I go about it?The behavior you're seeing is because you've turned on trace flag 1205. If
you turn on trace flag 1204, you'll only get error log output when we find a
deadlock. The overhead of -T1205 is pretty high, and the TF is
undocumented, so I would recommend turning it off and relying on the
documented -T1204 instead.
FYI, the 5 second deadlock search is by design. If we find a deadlock,
though, we will increase the frequency of searches temporarily.
Thanks,
--
Ryan Stonecipher
Microsoft Sql Server Storage Engine, DBCC
This posting is provided "AS IS" with no warranties, and confers no rights.
"ChrisR" <noemail@.bla.com> wrote in message
news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
> Rumor has it that a great way to wait for potential deadlock is to:
> DBCC TRACEOn (3605, 1205, -1)
> Ive done this for a while and have been please with the resaults. However
> I just noticed in the Error Log that a Deadlock search is being done about
> every 5 seconds. This is fine, but Im wondering if theres a way that the
> search can write to the Error Log only if theres a Deadlock, not every
> time it does a search? Also, if I ever needed to "Truncate" the Error Log
> , how would I go about it?
>|||Perfect! Thanks.
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>> Rumor has it that a great way to wait for potential deadlock is to:
>> DBCC TRACEOn (3605, 1205, -1)
>> Ive done this for a while and have been please with the resaults. However
>> I just noticed in the Error Log that a Deadlock search is being done
>> about every 5 seconds. This is fine, but Im wondering if theres a way
>> that the search can write to the Error Log only if theres a Deadlock, not
>> every time it does a search? Also, if I ever needed to "Truncate" the
>> Error Log , how would I go about it?
>|||To clarify, Traceon is a Server level setting, right?
"Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
> The behavior you're seeing is because you've turned on trace flag 1205.
> If you turn on trace flag 1204, you'll only get error log output when we
> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
> undocumented, so I would recommend turning it off and relying on the
> documented -T1204 instead.
> FYI, the 5 second deadlock search is by design. If we find a deadlock,
> though, we will increase the frequency of searches temporarily.
> Thanks,
> --
> Ryan Stonecipher
> Microsoft Sql Server Storage Engine, DBCC
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
> "ChrisR" <noemail@.bla.com> wrote in message
> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>> Rumor has it that a great way to wait for potential deadlock is to:
>> DBCC TRACEOn (3605, 1205, -1)
>> Ive done this for a while and have been please with the resaults. However
>> I just noticed in the Error Log that a Deadlock search is being done
>> about every 5 seconds. This is fine, but Im wondering if theres a way
>> that the search can write to the Error Log only if theres a Deadlock, not
>> every time it does a search? Also, if I ever needed to "Truncate" the
>> Error Log , how would I go about it?
>|||Hi Chris
DBCC TRACEON is normally session level, but adding the -1 makes it take
effect for all sessions.
To start a fresh errorlog, you can run sp_cycle_errorlog.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
> To clarify, Traceon is a Server level setting, right?
>
> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
> news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
>> The behavior you're seeing is because you've turned on trace flag 1205.
>> If you turn on trace flag 1204, you'll only get error log output when we
>> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
>> undocumented, so I would recommend turning it off and relying on the
>> documented -T1204 instead.
>> FYI, the 5 second deadlock search is by design. If we find a deadlock,
>> though, we will increase the frequency of searches temporarily.
>> Thanks,
>> --
>> Ryan Stonecipher
>> Microsoft Sql Server Storage Engine, DBCC
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "ChrisR" <noemail@.bla.com> wrote in message
>> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>> Rumor has it that a great way to wait for potential deadlock is to:
>> DBCC TRACEOn (3605, 1205, -1)
>> Ive done this for a while and have been please with the resaults.
>> However I just noticed in the Error Log that a Deadlock search is being
>> done about every 5 seconds. This is fine, but Im wondering if theres a
>> way that the search can write to the Error Log only if theres a
>> Deadlock, not every time it does a search? Also, if I ever needed to
>> "Truncate" the Error Log , how would I go about it?
>>
>|||All sessions in the DB, or the Server?
"Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
> Hi Chris
> DBCC TRACEON is normally session level, but adding the -1 makes it take
> effect for all sessions.
> To start a fresh errorlog, you can run sp_cycle_errorlog.
> --
> HTH
> --
> Kalen Delaney
> SQL Server MVP
> www.SolidQualityLearning.com
>
> "ChrisR" <noemail@.bla.com> wrote in message
> news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
>> To clarify, Traceon is a Server level setting, right?
>>
>> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
>> news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
>> The behavior you're seeing is because you've turned on trace flag 1205.
>> If you turn on trace flag 1204, you'll only get error log output when we
>> find a deadlock. The overhead of -T1205 is pretty high, and the TF is
>> undocumented, so I would recommend turning it off and relying on the
>> documented -T1204 instead.
>> FYI, the 5 second deadlock search is by design. If we find a deadlock,
>> though, we will increase the frequency of searches temporarily.
>> Thanks,
>> --
>> Ryan Stonecipher
>> Microsoft Sql Server Storage Engine, DBCC
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "ChrisR" <noemail@.bla.com> wrote in message
>> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>> Rumor has it that a great way to wait for potential deadlock is to:
>> DBCC TRACEOn (3605, 1205, -1)
>> Ive done this for a while and have been please with the resaults.
>> However I just noticed in the Error Log that a Deadlock search is being
>> done about every 5 seconds. This is fine, but Im wondering if theres a
>> way that the search can write to the Error Log only if theres a
>> Deadlock, not every time it does a search? Also, if I ever needed to
>> "Truncate" the Error Log , how would I go about it?
>>
>>
>|||All sessions means all connections to the server.
--
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"ChrisR" <noemail@.bla.com> wrote in message
news:uVGZi2hNFHA.2880@.TK2MSFTNGP10.phx.gbl...
> All sessions in the DB, or the Server?
> "Kalen Delaney" <replies@.public_newsgroups.com> wrote in message
> news:%23PcnYpZNFHA.3668@.TK2MSFTNGP14.phx.gbl...
>> Hi Chris
>> DBCC TRACEON is normally session level, but adding the -1 makes it take
>> effect for all sessions.
>> To start a fresh errorlog, you can run sp_cycle_errorlog.
>> --
>> HTH
>> --
>> Kalen Delaney
>> SQL Server MVP
>> www.SolidQualityLearning.com
>>
>> "ChrisR" <noemail@.bla.com> wrote in message
>> news:uEkDybVNFHA.1392@.TK2MSFTNGP10.phx.gbl...
>> To clarify, Traceon is a Server level setting, right?
>>
>> "Ryan Stonecipher [MSFT]" <ryanston@.microsoft.com> wrote in message
>> news:uFJpQCVNFHA.1040@.TK2MSFTNGP12.phx.gbl...
>> The behavior you're seeing is because you've turned on trace flag 1205.
>> If you turn on trace flag 1204, you'll only get error log output when
>> we find a deadlock. The overhead of -T1205 is pretty high, and the TF
>> is undocumented, so I would recommend turning it off and relying on the
>> documented -T1204 instead.
>> FYI, the 5 second deadlock search is by design. If we find a deadlock,
>> though, we will increase the frequency of searches temporarily.
>> Thanks,
>> --
>> Ryan Stonecipher
>> Microsoft Sql Server Storage Engine, DBCC
>> This posting is provided "AS IS" with no warranties, and confers no
>> rights.
>> "ChrisR" <noemail@.bla.com> wrote in message
>> news:egkCnvUNFHA.2748@.TK2MSFTNGP09.phx.gbl...
>> Rumor has it that a great way to wait for potential deadlock is to:
>> DBCC TRACEOn (3605, 1205, -1)
>> Ive done this for a while and have been please with the resaults.
>> However I just noticed in the Error Log that a Deadlock search is
>> being done about every 5 seconds. This is fine, but Im wondering if
>> theres a way that the search can write to the Error Log only if theres
>> a Deadlock, not every time it does a search? Also, if I ever needed to
>> "Truncate" the Error Log , how would I go about it?
>>
>>
>>
>

deadlock search

I have a system with a lot of deadlock searches appearing in the log,
but they usually do not find any deadlocks.
message in the log:
End deadlock search 21022 ... a deadlock was not found.
How is deadlock search triggered? Is it configurable? I think
performance is degrade by the deadlock searches but I need to know a
little more about under what conditions they occur.
/StenSten
You can capture it on the client (on Error) or run SQL Server Profiler with
Lock:Deadlock event
"Sten" <stenperersejspam@.hotmail.com> wrote in message
news:1108560501.098795.130320@.z14g2000cwz.googlegroups.com...
> I have a system with a lot of deadlock searches appearing in the log,
> but they usually do not find any deadlocks.
> message in the log:
> End deadlock search 21022 ... a deadlock was not found.
> How is deadlock search triggered? Is it configurable? I think
> performance is degrade by the deadlock searches but I need to know a
> little more about under what conditions they occur.
> /Sten
>|||A deadlock search occurs 500 millis after any lock is denied... Deadlock
searches used to happen immediately on denial ( in SQL 6.5). But many of
those deadlock searches were un-necessary, since it is normal to be denied a
lock while someone is using a row for a short period of time, then they
release the lock and you go about your business... Yet we used to have to
pay for a deadlock search anyway... In recent releases MS delayed the
deadlock search until 500 millis after the lock is denied... THe thinking is
that during the normal case, you will be granted the lock in a very short
period of time, and the deadlock search can be avoided altogether... Also
this allows a single deadlock search the opportunity to search for deadlocks
for multiple users in a single search... All of this is an optimization in
recent SQL versions.
There may be some way to set the deadlock search timeout, but if so , I do
not know what it might be.( I don't think MS exposes that to us...)
Wayne Snyder, MCDBA, SQL Server MVP
Mariner, Charlotte, NC
www.mariner-usa.com
(Please respond only to the newsgroups.)
I support the Professional Association of SQL Server (PASS) and it's
community of SQL Server professionals.
www.sqlpass.org
"Sten" <stenperersejspam@.hotmail.com> wrote in message
news:1108560501.098795.130320@.z14g2000cwz.googlegroups.com...
>I have a system with a lot of deadlock searches appearing in the log,
> but they usually do not find any deadlocks.
> message in the log:
> End deadlock search 21022 ... a deadlock was not found.
> How is deadlock search triggered? Is it configurable? I think
> performance is degrade by the deadlock searches but I need to know a
> little more about under what conditions they occur.
> /Sten
>|||Wayne Snyder wrote:
> A deadlock search occurs 500 millis after any lock is denied...
Deadlock
> searches used to happen immediately on denial ( in SQL 6.5). But many
of
> those deadlock searches were un-necessary, since it is normal to be
denied a
> lock while someone is using a row for a short period of time, then
they
> release the lock and you go about your business... Yet we used to
have to
> pay for a deadlock search anyway... In recent releases MS delayed the

> deadlock search until 500 millis after the lock is denied... THe
thinking is
> that during the normal case, you will be granted the lock in a very
short
> period of time, and the deadlock search can be avoided altogether...
Also
> this allows a single deadlock search the opportunity to search for
deadlocks
> for multiple users in a single search... All of this is an
optimization in
> recent SQL versions.
> There may be some way to set the deadlock search timeout, but if so ,
I do
> not know what it might be.( I don't think MS exposes that to us...)
> --
> Wayne Snyder, MCDBA, SQL Server MVP
> Mariner, Charlotte, NC
> www.mariner-usa.com
> (Please respond only to the newsgroups.)
> I support the Professional Association of SQL Server (PASS) and it's
> community of SQL Server professionals.
> www.sqlpass.org
> "Sten" <stenperersejspam@.hotmail.com> wrote in message
> news:1108560501.098795.130320@.z14g2000cwz.googlegroups.com...
log,
a
OK, so basically if You have long transactions holding locks more than
500 millis You will be in danger of deadlock search.
Thank You very much for a fast response.
/Sten