Comments on: The 6 Performance Tuning Mistakes You Don’t Want to Make

By: Sometimes It’s A Dirty Job – #TSQL2sDAY #50 - SQL Server - SQL Server - Toad World

Tue, 14 Jan 2014 13:32:11 +0000

[…] on a daily basis. You’re not using the auto-close option on your databases. You know you’re not supposed to flush the procedure cache on a live server. Sometimes though, in spite of your best efforts, you find yourself elbow-deep […]

By: Sometimes It’s A Dirty Job – #TSQL2sDAY #50

Sometimes It’s A Dirty Job – #TSQL2sDAY #50 — Tue, 14 Jan 2014 13:00:57 +0000

By: steve

steve — Tue, 17 Apr 2012 13:47:00 +0000

You can minimize the impact on the server if you run a trace on the server side instead of using Profiler. You can go into the Profiler and create the trace you want to run and filter it down to the db or whatever you need first. Next go to the file menu click on export, then script trace definition, and choose a version of SQL Server you need to run against.

By: Anonymous

Anonymous — Sun, 15 Apr 2012 15:22:00 +0000

If using Profiler in production is a mistake, what is the “correct” thing to do?

By: ThomasLaRock

ThomasLaRock — Tue, 10 Apr 2012 01:39:00 +0000

In reply to SCHDBA. Steven, Point taken, thanks for leaving a comment.

By: SCHDBA

SCHDBA — Mon, 09 Apr 2012 13:59:00 +0000

In reply to SCHDBA. Check that, #4.

By: SCHDBA

SCHDBA — Mon, 09 Apr 2012 13:57:00 +0000

I disagree with #5 to a point. I’ve resolved many, many issues in production by conservatively using SQL Profiler. I’ve also unEarthed many problems while they were small by again, using this feature with a limited scope. It’s far more important to know exactly how to leverage these tools, than to just say ‘no’. That said, I agree that novice and even “seasoned” DBAs will start up Profiler in production without any filtering and wonder why things just went from bad to worse.