Jeff Moden (4/4/2013)
For example, if you have some performance challenged code that uses a huge number of resources because someone simply used DISTINCT to get past an accidental Many-to-Many join, it won't cost you much on your own hardware.
I was moved from doing a DBA for a product that had multiple separate installations to a product that had every customer in a single silo. The development (and supposedly production) DBA's were on the left coast while the silo was on EST. I'm going to use the term DBA very loosely because of all the errors I found. One of the steps I did was to add in a free monitoring tool* just to see the high cost queries and other stuff.
I found an SP that was returning a list of 27K employees for 500+ individual facilities every time it was run. They were then evaluating the list in the web front end. The SP was running more than 5000 times per day. It was a quick SP, but totally wasted I/O. Adding a facility ID to the SP changed the results to about 25, and the I/O was significantly decreased.
So the development DBA needs to be watched. And tuning local or remote is always a problem.
* = Confio Ignite Free
----------------
Jim P.
A little bit of this and a little byte of that can cause bloatware.