I found out about being able to profile from the database side a couple of years ago. I even had it running on production servers for a long time and was steady collecting profiler data for the longest. I took care to archive the trace logs that were produced. The thing was, though, that I had the traces running on the production database server.

After reading this article on SQL Server Performance and having to do profiling all over again at my new company, I've come to realize that I can just capture profiler data on the database side, but on a development database server. I can have SQL Agent kick off the traces and save all the data to a table on that box rather than do it all on the p...

I found out about being able to profile from the database side a couple of years ago. I even had it running on production servers for a long time and was steady collecting profiler data for the longest. I took care to archive the trace logs that were produced. The thing was, though, that I had the traces running on the production database server.

After reading this article on SQL Server Performance and having to do profiling all over again at my new company, I've come to realize that I can just capture profiler data on the database side, but on a development database server. I can have SQL Agent kick off the traces and save all the data to a table on that box rather than do it all on the production box. Likewise, I can use the Windows 2003/XP Perfmon tool to save performance counter data to a database table and be able to access all of that information via query if I want to. It's going to make performance analysis much easier, I think.