Which "flavor" DBA are you?

This re-post from my Applied Team System blog (which was a repost from my old SQL Server Central blog) was inspired by James Luetkehoelter‘s Agile Development and the “DBA” post a few days back. I’ll have more to say about database developers, agile methodologies, and the need for a DBA in posts to come. Enjoy!

   I received a cool compliment today from a peer who’s a developer. He said, “You know, I really like having a DBA on my team!” I have to tell you, it made my whole day!

   It led to a discussion about past experiences and expectations, and I shared something I thought was pretty much common knowledge: there are three types of DBAs. My peer was shocked, so maybe the knowledge isn’t so common after all.

   The three “flavors” of DBAs I define are:

  1. System, Operations, or Production Support DBAs – these DBAs write maintenance plans in notepad and have no qualms whatsoever about executing in command-line. They were DBAs in the old days, when we carved our own ICs out of wood. They will get your server and database back online fast – and with less data corruption than anyone else on the planet. They live for torn pages and I/O faults.
  2. Application Support DBAs – these DBAs are familiar with one or more (usually complex) applications. I’m talking PeopleSoft, Seibel, and SAP here. If you want to customize a screen or write a one-off web application, you desperately need these folks.
  3. Database Developers – these DBAs are ruthless bit-heads. They use bigint and byte fields for masking binary states. They can optimize a stored procedure in their sleep and wrap an API around a database so developers never have to consider writing SQL that directly hits tables. They are performance freaks that will work 18-hour days on weekends to test in Production – when it’s “safe.”

   Do you think DBAs fall into these categories? Do you know any that do? Do you see yourself in there anywhere? Do you have more or less or different “flavors” for classifying DBAs? 

:{> Andy

Technorati Profile

Andy Leonard

andyleonard.blog

Christian, husband, dad, grandpa, Data Philosopher, Data Engineer, Azure Data Factory, SSIS guy, and farmer. I was cloud before cloud was cool. :{>

6 thoughts on “Which "flavor" DBA are you?

  1. Too often we don’t fall neatly within just one of the three different types you’ve defined.  I would suspect that it depends heavily on the size of the company and/or team.
    I grew into 1, transitioned into 2, and eventually became 3.  Although now that I work for a small company, I am currently about 10% 1, 5% 2, and 85% 3.
    And Adam, many have used a production database for confirmation that a performance tweak will behave exactly as expected when it is impossible to duplicate the database/hardware environment outside of production.  Granted, I have not done that in a long time now, but I cannot state that I will not ever do it again.

  2. Yes, we’ve all done it, but that certainly doesn’t mean that we should!  A long time ago I caused some production problems as a result of playing fast and loose with testing on live systems.  The problems I caused were minor, but one time another DBA I was working with caused a short amount of downtime (due to a transaction that she forgot to roll back, that was sitting there blocking everything).  It was embarrassing for the whole database team, and I really do not want to risk being put in that situation again!

  3. I’m none of the above. it appears that I’m (1) 50% SQL Server infrastructure engineer evaluating, recommending, and designing SQL Server infrastructure components and systems, and (2) 50% ‘behavioral empiricist’–if there is such a thing–studying the behavior of SQL Server as an empirical science.

  4. I think I’d say I’m 1, 2, 3 and 4, 5, 6 – all that and a bit more, depending on the situation. Given the client and the situation (and if I have my way), I’ll follow the data from initial conception and modeling, to implementation and optimization, as well as management, the later consumption (applications, reports, Biztalk, etc).
    I generally define myself as a data-centric specializing generalist. I focus on SQL Server specifically, but I know a little about an awful lot (networking, AD, development, etc).
    I think one of the biggest problems in our industry right now is that many organizations want to categorize job functions and "silo" them since there’s way too much to learn unless you specialize. I think that’s just plain silly. All job descriptions in IT/IS should overlap. A "production" DBA has to know a bit about hardware and the operating system. A networking infrastructure specialist needs to know a bit about how AD works, or how applications interact with each other over the network. The server infrastructure specialist has to know a bit about database systems and application development to understand how something new utilizes physical resources.
    Of all the clients I work with, the most difficult projects are ones where "silo-ing" is prevalant. The ones that roll smoothly have people being experts in one area but at least conversant in others.

Leave a Reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.