• Grant Fritchey (4/22/2014)


    Yeah, hard to argue with you Kevin (like it's ever easy). 8gb of RAM for SQL Server is probably barely adequate. My local VMs running on my laptop get more resources than that.

    It's amazing how things have changed... mostly for the worst. It wasn't so long ago that a previous company that I worked for was running their whole enterprise using 32 bit SQL Server 2000 Standard Edition on a 4 processor box played against a SAN with nothing but 7.5K RPM hard disks (state of the art at the time) and had no problems with processing or disk writes even though we had 1.2 million customers and we were handling all of the long distance calls, to boot. Sure... they started out with some problems with many overnight procs that took in excess of 10 hours to run but some thoughtful coding brought all of those jobs down to less than half an hour and some of them took as little as 3 minutes (some SERIOUS crap code was at work).

    The rules haven't actually changed that much but expectations (hardware can fix anything, right?), perceptions (it's cheaper to throw hardware at a problem than to have someone fix the code, right?), and needs (we need it now and it'll be cheaper to ship it and then fix it, right?) have gone through the roof and code quality has fallen through the bottom of the basket. It's a deadly combination where even today's incredible hardware can't keep up because crap code keeps hitting the proverbial fan. 😛

    Hardware helps but performance is in the 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)