• Jim P. (4/4/2013)


    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

    Now that's what I'm talking about. But, those don't sound like "Development DBAs". Those sound like developers that think they know SQL Server because their system used an ORM to talk to SQL Server. 😛 All of the true Development DBAs I know (which are mostly on this site, BTW), wouldn't have allowed such a thing to happen never mind having written such terrible code.

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)