Hi, I understand your concern that the process may affect your server performance however this is not the case.
If you would run such a trace using Profiler then you get in to trouble but not if you use the scripts provided in this article. I take it a step forward and make a statement that if you implement this process not only you are not risking your server's performance but you will not be able to measure the impact on your system, that is the foot print can hardly be measured because it is that small.

The explanation to the different behaviors Profiler vs. Server Side trace (implemented at this process) is that SQL Trace is a database engine technology that exposes 2 providers: the rowset provider and the file provider. The rowset provider used by Profiler is much "heavier" than the file provider. The file provider has also many other advantages over the rowset provider.
Profiler, however is always great for quick and dirty work but has to be used with caution.

For additional information about SQL Trace you may download a presentation I have that is just about that: http://sqlserverutilities.com/download/Tracing_SQL_Server.zip

-Yaniv

Yaniv10/5/2009 5:43:21 PM

Looks useful, but doesn't running another trace all the time create significant load on the server? 99% of the problems I have to find and fix are not error related, but are performance related (whether it be bad code or bad DB design). So, implementing something that could further negatively impact performance doesn't seem too wise.

Vincent9/22/2009 9:02:06 AM

Great article, very practical. Already implemented at my company.
One correction: In procedure TraceErrorsCreate I had to modify the path to the trace files location that match my server.

SHAHAR9/6/2009 5:04:37 PM