http://blog.sqlauthority.com/2011/10/20/sql-server-tracewrite-wait-type-wait-related-to-buffer-and-resolution/ Personal Notes of Pinal Dave Wed, 22 May 2013 19:03:49 +0000 hourly 1 http://wordpress.com/ http://blog.sqlauthority.com/2011/10/20/sql-server-tracewrite-wait-type-wait-related-to-buffer-and-resolution/#comment-181067 Thu, 20 Oct 2011 06:19:46 +0000 http://blog.sqlauthority.com/?p=15093#comment-181067 I do not consider Tracewrite as too much of an innocent wait, since when a Profiler program is open and a trace is running, this means that there is some system resources overhead. I.e. CPU and memory are used, or even Disk IOs.
Why? Here is how it works: a user starts the profiler, connects to a SQL Server and starts requesting events. SQL Server has a mechanism which filters and delivers the events to the user, but this takes some CPU and memory, as well as Network IO.
It is especially critical if a user logs in to the production system and they run a trace for a prolonged time.
To me the Tracewrite waits is an alarm that someone is trying to debug a problem and that they might have loaded the system with extra tasks because of that.
In this case I would like to know what problem they are trying to debug and if there is a better way to debug it.

]]>