Re: URGENT deadlock question
From: David Gugick (davidg-nospam_at_imceda.com)
Date: 12/17/04
- Next message: bd2103: "Backup Error - File in Use"
- Previous message: Brandon S.: "Re: Maintenance Plan Failure"
- In reply to: ChrisR: "Re: URGENT deadlock question"
- Next in thread: ChrisR: "Re: URGENT deadlock question"
- Reply: ChrisR: "Re: URGENT deadlock question"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 17 Dec 2004 16:54:57 -0500
ChrisR wrote:
> Thanks for the quick response. However, now Im really confused.
>
>
> When you use
>> Profiler to view a trace, SQL Server dumps rowsets across the
>> network to the Profiler client, but there is no guarantee you'll see
>> everything if SQL Server doesn't feel like it can keep up with all
>> the activity. A server-side trace to a trace file guarantees you'll
>> see everything. Just make sure the trace file is created on a local
>> server drive, not on a network drive or you'll throttle server SQL
>> Server and kill overall performance.
>
> Will I get everything if I save to a table as well, or only a file?
>
> Also, Ive always read that it would hurt performance to run Profiler
> on the local box. But if Im reading correctly, you are saying thats
> the only way to gauantee seeing all activities?
> Do you know if I can get the needed info from the messages in the
> Error Log?
>
>
> "David Gugick" <davidg-nospam@imceda.com> wrote in message
You cannot save to a table, nor should you, when using a server-side
trace. SQL Server only supports writing to a file for a trace with a
guarantee that all information is collected. You can either open the
trace file in Profiler when the trace is complete or move the trace data
to a table in any database on any server using the ::fn_trace_gettable()
system function.
You are not running Profiler when you do a server-side trace. Profiler
is a client application. The SQL Trace API is what Profiler uses
(inefficiently, I might add). And to be clear, you are better off
running Profiler right on the box as opposed to over the network because
no rowsets end up clogging the network pipe. But it doesn't really
matter because if SQL Server can't ship out the rows to the Profiler
client (wherever it is located), it temporarily stops sending rows.
Server-side traces do not have the problem because of the auditing
requirements of SQL Server: If it occurs on the server, and you're
looking for it, it must be logged.
I think the error log is used for deadlock information storage when
using trace flags.
Use a server-side trace. You don't have to write much code as Profiler
can generate it for you. And since you can open up the trace in
Profiler, it's easy to read.
-- David Gugick Imceda Software www.imceda.com
- Next message: bd2103: "Backup Error - File in Use"
- Previous message: Brandon S.: "Re: Maintenance Plan Failure"
- In reply to: ChrisR: "Re: URGENT deadlock question"
- Next in thread: ChrisR: "Re: URGENT deadlock question"
- Reply: ChrisR: "Re: URGENT deadlock question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
