Here is the video to accompany the article I wrote for SQLServerPedia.com, "The Server-side Trace: What, Why, and How"…
Any time you open SQL Server Profiler and run a trace, you're running a client-side trace. Even if you open SQL Profiler on the server and run it there, it’s still client-side. To run a server-side trace, we need to create a script. If that last sentence made your stomach tighten up, don't worry…this will be completely painless.
I go over the difference between client side and server side traces, the benefits, and how to set up, edit, run, and stop a server side trace. The article was written after the video, so it has a little more information. For example, in the article I linke to a blog by SQL Server MVP Linchi Shea that better illuminates the benefits of server-side traces over client-side ("Performance Impact: Profiler Tracing vs. Server Side SQL Tracing", [1]).
This was a fun video to make, and this marks my first non-blog publish. I'm very excited, and already gettnig positive feedback. Keep the emails and comments coming, guys: positive, constructive, and other!
3/12/2010 Edit: I ran across a little something today I thought I should share, a SQLMonster.com forum thread on traceID=1. In it, Kalen DeLaney confirms that the traceID = 1 that you see when you run select * from fn_trace_getinfo(NULL) is a "default system trace used to populate some of the summary reports". My suspicions are confirmed, Dr. Watson!
-Jen McCown, http://www.MidnightDBA.com
Pingback: SQL Monitoring with SQL Profiler