philcart (5/19/2011)
I'd suggest never run the Profiler GUI on a production server without very limited events/columns and strict filters. Even then, on a very busy server, there will be an adverse impact on the server.Better method is to use a server side trace created via the sp_trace_create. Have the output of the trace go to a file then open the file in Profiler once the trace is closed.
BJ (the author) includes a script that creates a server side trace. But even so, the trace as BJ defined it is very limited in terms of events and columns. And the event is very lightweight. (It was designed to be that way). As BJ defined it, I would feel comfortable creating that trace in order to capture blocking problems in production.
Also let me plug a tool I wrote to help analysis of the blocked process reports after collecting them:
http://sqlblockedprocesses.codeplex.com/
I've found it useful.