• I can't speak for others but I almost always offer a better solution when I say "No".  The trouble is... it doesn't help.  They say that DBAs have this negativity about them but a lot of people get their feelings hurt simply because their idea, no matter how bad it may actually be, is in jeopardy.

    Sometimes I let people experiment even though I think something is a horrible idea just so I can occasionally prove that the idea is horrible.  For example, I let some folks use sp_GetAppLock because they insisted that it would do what they wanted it to do.  I had suggested that there's a much better way and they simply wouldn't hear it and basically accused me of being an old fuddy-duddy that didn't know squat about how modern front-end code worked against a database.  Heh... and their strongest justification was that it was a recommended method that they got from some web site somewhere.

    So, knowing full well what was going to happen, I let them see it my way 😉  by letting them use sp_GetAppLock.  The next couple of days were grand fun.  People on the floor were complaining about some slowness and the front-end developers started to have timeouts start appearing in their logs.  As each day wore on, more timeouts occurred and faster.  I'm sitting there watching the blocking mount up knowing full well what the cause was.  I finally explained it to them and the reason why sp_GetAppLock was the cause and the boogers still wouldn't take my word for it.  They finally got on the forum were they got the original idea and someone with more than half a brain suggested that the ol' fuddy-duddy DBA they were talking about was right.

    Ah... almost forgot.  It took the devs about a half hour to implement the suggestion that I originally gave them to replace the sp_GetAppLock code and things have been running hot, straight, and normal since. 

    Another instance was when we were having problems with some monster sized outages on the floor.  36 CPUs on an SSD box with a quarter TB or RAM would suddenly ramp up to over 80% average usage (many of the individual CPUs would peg to the ceiling).  I had identified the symptoms of the problem and was working on isolating the cause but knew it wasn't the hardware and I told them about it the problem.  They said they thought it was a hardware problem and that they were going to buy another 12 core and another 128GB of RAM.  I almost went into my "No... that'd be a waste of money because it's not a hardware problem" but then I remembered that I'd been preaching that, although hardware certainly did carry some weight, true performance was in the code and no one listed then.  So I told them one more time without being adamant about it except that I did mention that I thought adding the extra CPUs would simply raise contention (more stuff failing) and then kow towed to their incorrect urges.  They spent the money on the hardware and, sure enough, the problems got worse.  It didn't last long, though.  It was definitely a front-end related problem and I had fed my front-end savvy boss enough information about the symptoms that he figured out that it was because .NET, contrary to what was documented, had been defaulted all connections to implicitly set M.A.R.S. to enabled.  He and the devs ripped through the connections and explicitly set M.A.R.S. to disabled and THAT fixed the problem instantly.

    I now have a 48 Core fire breathing monster server with 384 GB of RAM (although that change didn't do squat for performance) and folks have a fair bit more respect for when I say "Performance is in the code and you need to fix it... here's how" instead of them saying "we doubt it". 😀

    As I tell folks, old DBAs aren't hard of hearing... we're tired of listening.  And we're not stubborn... we've just seen a lot more than most and already know if something's going to work or not even it's its the latest shinny new twitch on the market.  At least I give a reason and an alternative when I say "No"  (although I am getting tired of offering alternatives to the same "new" stupid things over and over).  The best I get from people with all the twitch ideas is that "everyone is doing it" or "it's a 'Best Practice'" or some idiot who's somehow managed to develop a following on some forum said so.

    And those are just two of the dozens of instances where people haven't listened and were more interested in their own agenda rather than doing it right.  I got the same lines of horse-muffins when I was a young DBA and I still get them now that I'm an old DBA.  Other people need to start listening to us for a change.  We're not being negative... we're trying to save people some time, money and, in many cases, embarrassment.

    To be absolutely blunt, I'm tired of articles like this one.  Get a grip people.  Instead of fighting us, join us because we can make you shine if you'll let us. 😉  And, for the love of Pete, remember all the times we said "Yes".

    And, no... I won't budge an inch if it puts the data in jeopardy, period.

    --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)