Click here to monitor SSC

What Counts for a DBA: Humility

Published 10 March 2011 8:54 pm

In football (the American sort, naturally,) there is a select group of players who really hope to never have their names called during the game. They are members of the offensive line, and their job is to protect other players so they can deliver the ball to the goal to score points. When you do hear their name called, it is usually because they made a mistake and the player that they were supposed to protect ended up flat on his back admiring the clouds in the sky instead of advancing towards the goal to scoring point. Even on the rare occasion their name is called for a good reason, it is usually because they were making up for a teammate who had made a mistake and they covered up for them.

The role of offensive lineman is a very good analogy for the role of the admin DBA. As a DBA, you are called on to be barely visible and rarely heard, protecting the company data assets tenaciously, even though the enemies to our craft surround us on all sides:.

  • Developers: Cries of ‘foul!’ often ensue when the DBA says that they want data integrity to be stringently enforced and that documentation is needed so they can support systems, mostly because every error occurrence in the enterprise will be initially blamed on the database and fall to the DBA to troubleshoot. Insisting too loudly may bring those cries of ‘foul’ that somewhat remind you of when your 2 year old daughter didn’t want to go to bed. The result of this petulance is that the next “enemy” gets involved.
  • Managers: The concerns that motivate DBAs to argue will not excite the kind of manager who gets his technical knowledge from a glossy magazine filled with buzzwords, charts, and pretty pictures. However, the other programmers in the organization will tickle the buzzword void with a stream of new-sounding ideas and technologies constantly, along with warnings that if we did care about data integrity and document things, the budget would explode! In contrast, the arguments for integrity of data and supportability tend to be about as exciting as watching grass grow, and far too many manager types seem to prefer to smoke it than watch it.
  • Packaged Applications: The DBA is rarely given a chance to review a new application that is being demonstrated for the enterprise, and rarer still is the DBA that gets a veto of an application because the database it uses has clearly been created by an architect that won’t read a data modeling book because he is already married. More often than not this leads to hours of work for the DBA trying to performance-tune a database with a menagerie of rules that must be followed to stay within the  application support agreement, such as no changing indexes on a third party schema even though there are 10 billion rows instead of the 10 thousand when the system was last optimized.
  • Hardware Failures: Physical disks, networking devices, memory, and backup devices all come with a measure known as ‘mean time before failure’ and it is never listed in centuries or eons. More like years, and the term ‘mean’ indicates that half of the devices are expected to fail before that, which by my calendar means any hour of any day that it wants to fail it will.
  • But the DBA sucks it up and does the task at hand with a humility that makes them nearly invisible to all but the most observant person in the organization. The best DBAs I know are so proactive in their relentless pursuit of perfection that they detect many of the bugs (which they seldom caused) in the system well before they become a problem.

    In the end the DBA gets noticed for one of same two reasons as the offensive lineman. You make a mistake, like dropping a critical production database that had never been backed up; or when a system crashes for any reason whatsoever and they are on the spot with troubleshooting and system restoration plans that have been well thought out, tested, and tested again. Not because there is any glory in it, but because it is what they do.


    Note: The characteristics of the professions referred to in this blog are meant to be overstated stereotypes for humorous effect, and even some DBAs aren’t quite this perfect. If you are reading this far and haven’t hand written a 10 page flaming comment about how you are a _______ and you aren’t like this, that is awesome. Not every situation applies to everyone, but if you have never worked with a bad packaged app, a magazine trained manager, programmers that aren’t team players, or hardware that occasionally failed, relax and go have a unicorn sandwich before you wake up.

    12 Responses to “What Counts for a DBA: Humility”

    1. fatherjack says:

      Nice post Louis, lots of experiences to match up to your characters and scenarios but on the whole its fun being a DBA that no-one names.

    2. BuggyFunBunny says:

      – the database it uses has clearly been created by an architect that won’t read a data modeling book because he is already married.

      Getting really close to the line here, Buddy!!! Three cheers for NoSql!

    3. drsql says:

      Well, as enamored as I am by the relational model, I would assume that NoSQL would still need a model, and hence some sort of book to cover how to do it might also exist, and if it did, an the architect in charge of the product picked up a book entitled “NoSql Data Models”, one expects that they would still be displeased by the notion of reading a dating book, even if it included models :)

      And the fact is, (after putting on my flameproof undergarments), as a data architect type if you use a tool called NoSQL without understanding the value of YesSQL (known in most circles as SQL), you probably don’t get it. I haven’t looked at NoSQL at of yet, but have heard that it does have some actual purpose when consistency is less important than speed… Usually in most business systems consistency is more important than speed… so I can see a solid mix of the two architectures being useful and likely popular in the mainstream some day…

      Honestly, this post is a shout out to *all* data professionals that have the very important, thankless job of making sure that when anyone asks a question of your DBMS (prefixed by R or not) you get back an answer that makes everyone happy. So if you could all just stand on your desk and shout “DBA! DBA! DBA! DBAs we love them!” it would really help the cause, unless you are the DBA, then you will just look silly.

    4. BuggyFunBunny says:

      Just to be clear, I was kidding. I loathe NoSql and all other reactionary 1960′s clones. Send in the Clones!!

      In a nutshell NoSql (by whatever name) is just VSAM in pink tights.

    5. Sidney Greenstreet says:

      Even taking some deliberate exaggeration by the author into account, this has to be one of the most egotistical, self-congratulatory pieces of rubbish I’ve ever seen written by a DBA.

      Sure, there are some terrific DBAs out there. They’re the ones who don’t continually blame developers for all their woes, don’t try to lock down development data to the point application designers can’t even get to it without an act of Parliament, and don’t insist on inflating their power or self-importance by implementing time-wasting bureaucratic processes for anyone else to get on with their work.

      One thing I’ve learnt about DBAs: the worst of them use attitude to cover ineptitude. And you need an attitude change, chum.

    6. BuggyFunBunny says:


      I’m going to take a wild guess: you don’t have much knowledge of, or use for, Dr. Codd’s work, and find Scott Ambler to be a genius?

    7. drsql says:

      Sidney… I really do appreciate your feedback, and of course, your points here: “They’re the ones who don’t continually blame developers for all their woes, don’t try to lock down development data to the point application designers can’t even get to it without an act of Parliament, and don’t insist on inflating their power or self-importance by implementing time-wasting bureaucratic processes for anyone else to get on with their work.” are the kinds of things I was trying to say. I also realize that I kind of got on a roll and made it sound like all DBAs were perfect. I wanted to say that this is a trait that makes up a great dba…

      I also hope you don’t think that I am an admin DBA.. I am a developer /architect(albeit a data oriented one), and am pretty much applauding the DBAs who have humility to put up with a lot from everyone for doing what is a pretty boring task. And clearly I don’t want to state that every DBA is perfect, just that it is a thankless job and the best ones out there are humble. I guess I could have applauded what they do in a humble way, but what fun would that be. (I have worked against a few admin DBAs that fit your description of bad ones too. Sometimes the stern annoying ones do know what they are doing though and can be great teammates.)

      DBAs don’t usuall write the code (particularly admin ones) but are generally called on to figure out what is wrong with it. Let’s says as the development team decides that using a unique constraint is giving errors that we are taking care of in code, so it gets removed. After being in production for 10 days, it is noticed that 200000 duplicate major rows are created, and most of these rows have related rows that are also a problem (not duplicates, but assigned to one of the duplicates instead of the already existing rows.) After the support/admin DBA figures out the problem, the developers go “oops” and add the constraint/change the code and hope that it is right this time (yes, these people test as well as reasonable possible too). This is a very common problem and the DBA gets to do the cleanup.

      The fact is though, most of this I did say, or at least implied by the title: Humility. In fact, that is the whole point, in that the stuff DBAs do takes humility because of the fact that when if that dba had said that you really need a unique constraint to make sure this doesn’t happen (even if errors occurred, since they would have identified a bug in the code0, the cries of ‘foul’ occur and the accusations of self-importance, etc. Of course there are bad DBAs, and pompous ones too. I probably would be as well, if I had seen the train coming and me tied to the tracks before.

      Finally, not to give away too much of the future of my blog, but in the future as I put out more of these, I will be more than certain to mention that without developers, the DBA (development or admin) is jobless without great developers who themselves are humble and share design with those folks who think in data terms and not presentation terms. A relational db without a UI is death, but you can store data somewhere else (though the relational model does have 40 years on its side)

      The problem is that when the type of developer who feels he knows it all gets going, he can sound mighty impressive because new stuff sounds better than the same old boring, somewhat time consuming relational model work (even when using a relational engine to store data)…And the dba suffers… I have known a lot of DBAs in my career, and a great number of them just keep going like the Energizer Bunny, answering their pagers and fighting fires. Such is the life of a support person, but without them we developers would have less time to produce.

    8. Anonymous says:

      "There are 10 kinds of people in the world. Those who will always wonder why there are only two items…

    9. Anonymous says:

      Of all the valuable attributes of a DBA covered so far in this series, ranging from passion to humility…

    10. [...] (most often followed by “jerk”). You don’t need to be a jerk to be a DBA; humility is important. However, ego is important too. A good DBA needs a certain degree of self-esteem…a [...]

    11. [...] of tasks to perform: backups, performance tuning, data movement, system monitoring, and of course, avoiding being noticed.  Every day, there are many steps to perform to maintain the database infrastructure, including: [...]

    Leave a Reply

    Blog archive