If I saw there's a dead lock through the Enterprise Manager's current
activity section, how can I see those processes which have dead lock
(blocking and being blocked) is running what SQL statement? So that I
can know which SQL statement cause the dead lock there.
Usually when I open the deadlock process, I can see something like
'sp_xxxxx' ... it seems to be the store procedure.But the dead lock
should be cause the the SQL statement in the application scripting
portion.
I can kill the process from there, but before doing that, I wish to see
the SQL statement causing that.
Thanks.
Peter CCHHi
sp_who2 will give you information about the processes involved. You may want
to read
http://support.microsoft.com/defaul...kb;en-us;224587 and try
sp_blocker_pss80
http://support.microsoft.com/kb/271509/EN-US/
John
"Peter CCH" <petercch.wodoy@.gmail.com> wrote in message
news:1122191600.869516.130600@.z14g2000cwz.googlegroups.com...
> If I saw there's a dead lock through the Enterprise Manager's current
> activity section, how can I see those processes which have dead lock
> (blocking and being blocked) is running what SQL statement? So that I
> can know which SQL statement cause the dead lock there.
> Usually when I open the deadlock process, I can see something like
> 'sp_xxxxx' ... it seems to be the store procedure.But the dead lock
> should be cause the the SQL statement in the application scripting
> portion.
> I can kill the process from there, but before doing that, I wish to see
> the SQL statement causing that.
>
> Thanks.
>
> Peter CCH
>|||Hi,
To add on to John, Enable trace flag (1204); which will record the deadlock
chain into the error log.
Execute the below command from query analyzer to enable trace flag 1204.
DBCC TRACEON(1204,-1)
Also see the below url to reduce deadlock.
http://www.sql-server-performance.com/deadlocks.asp
Thanks
Hari
SQL Server MVP
"Peter CCH" <petercch.wodoy@.gmail.com> wrote in message
news:1122191600.869516.130600@.z14g2000cwz.googlegroups.com...
> If I saw there's a dead lock through the Enterprise Manager's current
> activity section, how can I see those processes which have dead lock
> (blocking and being blocked) is running what SQL statement? So that I
> can know which SQL statement cause the dead lock there.
> Usually when I open the deadlock process, I can see something like
> 'sp_xxxxx' ... it seems to be the store procedure.But the dead lock
> should be cause the the SQL statement in the application scripting
> portion.
> I can kill the process from there, but before doing that, I wish to see
> the SQL statement causing that.
>
> Thanks.
>
> Peter CCH
>|||Hari,
Would you know what the "-1" does in "DBCC TRACEON(1204,-1)" ?
Thanks,
Gopi
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23V4GOXFkFHA.3300@.TK2MSFTNGP15.phx.gbl...
> Hi,
> To add on to John, Enable trace flag (1204); which will record the
> deadlock chain into the error log.
> Execute the below command from query analyzer to enable trace flag 1204.
> DBCC TRACEON(1204,-1)
> Also see the below url to reduce deadlock.
> http://www.sql-server-performance.com/deadlocks.asp
> Thanks
> Hari
> SQL Server MVP
>
> "Peter CCH" <petercch.wodoy@.gmail.com> wrote in message
> news:1122191600.869516.130600@.z14g2000cwz.googlegroups.com...
>|||The -1 means to enable the flag for ALL connections. Without the -1, it only
enables the flag for the current connection, and connections that have other
trace flags already enabled.
HTH
--
Kalen Delaney
SQL Server MVP
www.SolidQualityLearning.com
"gopi" <rgopinath@.hotmail.com> wrote in message
news:%23Gne01IkFHA.3144@.TK2MSFTNGP12.phx.gbl...
> Hari,
> Would you know what the "-1" does in "DBCC TRACEON(1204,-1)" ?
> Thanks,
> Gopi
> "Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
> news:%23V4GOXFkFHA.3300@.TK2MSFTNGP15.phx.gbl...
>|||We've been using this trace flag with lots of success. You can see in the
SQL error log what DB and the object ids involved (tables & indexes) in the
chain. This makes it "much" easier to find the cause(s) of the deadlock.
"Hari Prasad" <hari_prasad_k@.hotmail.com> wrote in message
news:%23V4GOXFkFHA.3300@.TK2MSFTNGP15.phx.gbl...
> Hi,
> To add on to John, Enable trace flag (1204); which will record the
deadlock
> chain into the error log.
> Execute the below command from query analyzer to enable trace flag 1204.
> DBCC TRACEON(1204,-1)
> Also see the below url to reduce deadlock.
> http://www.sql-server-performance.com/deadlocks.asp
> Thanks
> Hari
> SQL Server MVP
>
> "Peter CCH" <petercch.wodoy@.gmail.com> wrote in message
> news:1122191600.869516.130600@.z14g2000cwz.googlegroups.com...
>|||Peter CCH wrote:
> If I saw there's a dead lock through the Enterprise Manager's current
> activity section, how can I see those processes which have dead lock
> (blocking and being blocked) is running what SQL statement? So that I
> can know which SQL statement cause the dead lock there.
> Usually when I open the deadlock process, I can see something like
> 'sp_xxxxx' ... it seems to be the store procedure.But the dead lock
> should be cause the the SQL statement in the application scripting
> portion.
> I can kill the process from there, but before doing that, I wish to
> see the SQL statement causing that.
>
> Thanks.
>
> Peter CCH
Deadlocks and blocking problems are two different things, although they
do share the "blocking" aspect. It sounds like what you are seeing is
blocking problems, not deadlock issues. Deadlocks are quickly resolved
by SQL Server and don't really show up in system tables. They are
normally identified through application error reporting and through
running traces on a server (from Profiler or using the SQL Trace API).
If you are having blocking problems, you need to identify the long
running transactions and figure out why they are taking so long to
complete. It's possible the application is not fetching result sets
quickly enough or not fetching all results to the end of the result set.
It's also possible there are performance problems in the queries that
require tuning.
The best built-in tool to determine these problems is Profiler or,
better yet, using SQL Trace directly from the sp_trace*() functions. You
can have Profiler script a trace for you using the File - Script Trace
menu option.
Look at the SQL:BatchStarting/Completed and RPC:Starting/Completed
events to start with. Examine the CPU, Duration, and Reads columns and
try to get a handle on the high CPU and long running batches.
David Gugick
Quest Software
www.imceda.com
www.quest.com
No comments:
Post a Comment