Why is Database Administration so hard?

Question

I know a lot of Database Administrators and they are all over 28-29 years old.

Is all database administration like that? I mean, is this about getting experience more than at least 7-8 years?

Or is being a database administrator so hard?

Answer 1

The position requires a broad spectrum of knowledge ranging from development to system administration and even management. Not only must a DBA know about backup, recovery, internal operations, memory and security, but also how to communicate with both developers and management. A DBA could be giving a high level presentation to management, helping a developer tune a query, provisioning disk space for a new system and restoring data from backup all within the same hour. These responsibilities require a wealth of knowledge with little overlap.

The consequences of failure are usually greater for a DBA than a developer. DBAs often support dozens, even hundreds of different applications and systems most of which are vital to the success of the company. A security breach, recovery failure, or performance problem could have far reaching and devastating ramifications. This requires a level of knowledge and experience that can’t be gained in a short amount of time.

The better a DBA does their job the less visibility they have. A DBA with a database that is secure, recoverable, available, and performing well will lack recognition. DBAs get noticed when there are problems. Not only do they get noticed when their problems are self-inflicted, they also get blamed when the database has problems due to poor coding, improper network setup, or incorrectly configured storage.

---

I switched from developer to DBA when I was 29. For me the things that make being a DBA difficult also make it rewarding. I enjoy absorbing and using a wide spectrum of knowledge, and the greater opportunity for failure makes the avoidance thereof all the more meaningful whether others see that or not.

Answer 2

Becoming a DBA actually demands a great measure of experience but it can basically come from only four different paths:

1. Being a developer and making a segue to a DBA
2. Being a developer and being drafted as a DBA
3. Training straight from college/trade school to become a DBA
4. Being a SysAdmin and making a segue to or pulling double-duty as a DBA

Being a developer and making the segue to a DBA

In another question that was asked on this site, How Could DBAs be more 'programmer-friendly', I mentioned that I was a developer for 16 years who worked with DBAs. Having worked with them made me realize that to the extent their experience included database theory, discrete math, and programming experience, to that extent they could see how a database should work and how a query should execute.

Having a DBA with those things in their background made me feel I was still in college learning from some adjunct professor but who really knew their stuff. As long as the DBA was willing to share what they knew, without lording it over you, they could actually become your mentor in terms of developing SQL statements (SQL is, in itself, a Context-Sensitive Programming Language) that are as efficient as possible. Sure, there are the other mundane parts, such as performing installations, making backups, doing software upgrades, monitoring performance metrics, generating reports, and so forth. But as a developer, if you focus on the databases, and the SQL that runs against those databases, over time you will becomes so adept at SQL that it will be second nature and you can focus on the application development.

The demands on a developer can be taxing, but so can the DBA. The developer who voluntarily transitions to the role of a DBA shifts focus from development and coding to the mundane things I mentioned before. In light of this, the DBA closely working with programmers creates the opportunity for the DBA to make creative contributions to any project, thus making the role of a DBA that much more interesting.

Being a developer and being drafted as a DBA

For most developers that see nothing but developing and coding for the rest of their life, this could be like choosing to be either in the reality show Survivor or the game show Wipeout. The new DBA spends their time interacting with that Black Box (known to us all simply as the database) they have contacted for data over the years.

The new DBA can now create their own tables and indexes. This could resemble letting a Japanese Hibachi cook into an Italian Restaurant. The cook can whip up anything, but must realize that there are new recipes, kitchen utensils, cutlery, meats, spices, vegetables, and host of other mundane things to adjust to (sanitation, inventory, start time, work hours, etc). This is not just a time of transition but also a time to overcome a great learning curve. A new level of experience has to be learned and developed despite expert Japanese cooking over the years. In this aspect, Developers must reeducate themselves to think like a DBA.

Training straight from college/trade School to become a DBA

This is, by far, the most lethal way to become a DBA. This is also the rarest path—in fact, this is virtually unheard of. Now we are talking letting someone from McDonald's or Burger King into that same Italian Restaurant.

Three learning curves are involved:

1. Applying skills from college/trade School into the DBA role,
2. Interacting with the particular RDBMS (PostgreSQL, Oracle, MySQL, DB2, Sybase, Ingres), and,
3. Interacting with Developers (a future DBA learning decent social skills straight out of school? Yea, right!).

In this, developers will have the upper hand over DBAs for years. DBAs must learn to adjust quickly to the needs of developers in their early years as a DBA. Perhaps a DBA could make a decent starting salary, but it is harder to grow without developing themselves in these three areas of learning.

Being a SysAdmin and making a segue to or pulling double duty as a DBA

As a former developer and now a DBA, one thing that must not be taken for granted is the role of the SysAdmin.

Having the role of SysAdmin/DBA is a little awe-inspiring to me. At my employer's hosting company, we have a guy who is a SysAdmin/DBA (SCMDBA). He is so swamped with infrastructure projects plus his own internal MySQL gigs. I do not envy him, I commend him. In honesty, since the true mind of a SysAdmin/DBA is foreign to me, I leave it to the discretion of SysAdmin/DBAs to update this paragraph (or completely replace it) to describe this path.

Conclusion

Regardless which path you choose, the role of a DBA can be distinguished or disgusting, depending on how willing you are to be mentored (or tortured) in the beginning, and how willing you are to work with other overs time. Only then can one say they enjoy being a DBA.

By the way, it just so happens I experienced the first two DBA paths starting from August 2004 at the age of 39. The two years of experience I had in the drafted DBA role made the transition to a full-time DBA very enjoyable and comfortable.

My advice to DBAs 28-29 years old? Be as good at working with people as you are with the RDBMS. If you grow in both areas, you can make it as a DBA for years to come.

Answer 3

Database Administration is difficult because of two reasons

Slow feedback If one makes a bad decision in the role of a software architect, it usually takes longer to get negative feedback compared to a programmer. The programmer can often become aware of the error during compilation or while running tests, which means that the learning cycle is quite fast. A database administrator making a mistake while designing a database might just get feedback when he/she discovers how the end-users will actually use the software. This means that it might take years to get the feedback that the database design was flawed and needs to be remade. Therefore, it takes years to gain experience, instead of minutes (sometimes) for programmers.

Expensive mistakes This is also the reason why CEOs of large companies are generally in their 50s.

Answer 4

It is pretty easy to be a bad DBA

Seriously though, a DBA usually has special responsibility for something that is often critical to the success or failure of a business: its data

If you run a company then you may well be keen to employ competent experienced people in that role

I don't think it is a question of 'easier' or 'harder' - just a question of how valuable your data is: It isn't inherently harder to put a satellite in space than a person, but you would check your sums a good deal more for the latter

Answer 5

In my opinion, being a Database Administrator is easy...until something breaks that threatens the company and the burden of fixing and restoring whatever it is is on your shoulders.

Being a Database Administrator (or Network or System Admin) is a position that requires a certain maturity level. It takes someone who works well under pressure. That's not to say there aren't younger people out there that can handle this with the necessary skillset.

Also, it's easy to learn the commands from a book to backup/restore a database, optimize the server configuration, etc. But experience wins when you get the alert that your database is down.

Answer 6

I know a lot of Database Administrators and they are all over 28-29 years old. Is all database administration like that?

Most good, solid programmers I know are also at least 25 years old. I imagine there is a correlating factor to age + experience = good coder. ;)

I mean, is this about getting experience more than at least 7-8 years? Or is being a database administrator so hard? What do you think?

Being a database administrator isn't easy, if that's what you mean. There are a lot of things that you should know as a dba. That also means school, and it means a few years tutelage under another person. Remember that databases are set-logic, which almost nobody goes to school long enough to learn, which therefore nobody knows about. Set-logic shares some rules with algebra, but the engines (MSSQL, Oracle, etc) are themselves twisted beasts of implementation of those rules, so not only do you have to understand the math behind databases, you have to understand the implementation that you run on top of. That doesn't even count knowing your preferred scripting language (PL/SQL,TSQL, etc).

Then consider that as a dba you will be responsible for ensuring that the most critical business data will often be entrusted to your hands. You need to have gotten past the worst parts of "making dumb mistakes" and you need to have learned a bit of self-restraint. Most people at 21-23 haven't learnt that yet. Some of us at 30 still haven't.

OT: This is why I say that people don't really know anything until they're at least 40, and by then they're considered over the hill, when in reality they're just reaching their stride. (said as someone who is 31)

Answer 7

I don't think that being a DBA is hard. Becoming one was though.

Answer 8

I wanted to answer to add another aspect not well discussed above: field of vision.

There are wide varieties of roles for developers and some (for example, device driver development, or developing operating system schedulers) require a very narrow field of vision and an ability to delve deeply into a small problem and look at it from a purely technical viewpoint. There are other fields which require very broad fields of vision but not so much technical depth (business application development with an ERP framework of your choice).

Databases are unique because to do them well, you have to be able to move between these modes quickly and seamlessly. Databases are math engines but they are math engines which fit into business environments in very complex ways. Therefore one has to be able to both tackle the math problem as a math problem and also ask how it fits into everything else.

When you look at senior network engineers or senior system administrators, they are the closest match to a senior DBA in this area (though each field is quite different-- a good senior sysadmin requires an even broader field of vision than a good dba, and good network engineers require a deeper field).

In other words, to be a good DBA, you need to be able to move between high-level business requirements and very low level understandings relating to actual on-disk storage, and over to relational math and purely technical issues of design, all without any real transition (and probably in the course of evaluating a specific decision).

I function as a DBA and a developer. The two roles are extremely complementary, but I am a DBA first and if you saw libraries I wrote, that would be obvious. But the reason they are complementary is that on the development side, I get to directly interface with the end-users of the software and so I am constantly being pushed regarding the bredth of my vision, while on the db side I get to challenge myself on the depth.

Answer 9

There is another path, slightly different form the ones listed.

Start as a developer, then become a database designer, then become a DBA. This path was more prevalent about thirty years ago, when databases began overtaking file based applications big time, and people with database expertise were few and far between

PS: When I was an ex-programmer turned DBA, programmers used to ask me "isn't DBA work boring?"

My answer: "it's only boring when you're doing it right!". :)

Answer 10

I'm rather at the start of my DBA journey, but here are a few of the reasons why people can find this job hard... It's hard because:

• you have a lot of responsibilities: people can come and go in a company, but for quite a few of them, their most important asset is their data. You're responsible for it and have all powers over it. As the saying goes, with great powers come great responsibilities. Very costly mistakes are lurking around.
• you have to learn and keep on learning: I see this as a bonus, but not all people are willing to take the time to keep their knowledge up to date.
• it can be time consuming: things will break in the middle of the night, will you be ready?
• you will often have to fix other people mistakes: and you will mostly won't get much credit for all your good work. Don't be afraid to brush up your people skills.

Brad Mc Gehee wrote a book about it, "How to become an exceptional DBA". Worth a read if you intend to deepen the question.

Good luck!

Answer 11

I became a dba at the age of 25. It took me 6 months from the time I started studying to get certified and 2 months later I had a job. I think determination definitely plays a major part. For me it was not hard getting the job. All it took was will power to study and showing that I was capable of learning what ever is put in front of me.

I will say that all I had was a psychology degree and a help desk background. When I received my job as an Oracle Apps DBA, i immediately thought OMG, all the stuff I studied for to become a CORE DBA did not help me one bit. I remember feeling extremely overwhelmed. I had to remind myself daily I can learn this and 2 years later I have gained so much more knowledge.

What I am saying is, being a DBA is not hard, not hard at all, but learning everything on the job and off the job, that we should know as previous dba's have mentioned before is time consuming and takes much much diligence. I have found at 27 most people my age or younger does not have the diligence nor the desire to want to learn such a large spectrum of technologies. But I love my job as an Oracle Apps DBA and look forward to everything else that will constantly be thrown my way to learn. You can do it, if you put your mind to it, doesn't matter what age you are!

Answer 12

Being a DBA also means you are proactive instead of reactive. You have to be able to imagine what the future holds and plan accordingly. This involves working hard...once, many, many times, and if you do it right, the reward is a complete lack of name recognition. :-) You also have to have the ability to say "no" to people (bosses included) and objectively, effectively communicate your reasons why in terms your audience can understand. You have to be prudent and make rational decisions in high pressure situations. You have to be able to own your mistakes quickly and not let them blue screen you, but rather, effectively switch gears from "I can't believe I just did that" to "Okay, what's the best way to fix this." You have to be able to tactfully suggest improvements to a developers code in such a way as to not insult or offend, and that is an art cultivated by experience yet mastered by few.

Answer 13

As someone who considers himself primarily a SysAdmin and secondly an accidental DBA, I think part of it comes down to the amount of knowledge required to stand on your own and do the job, or perhaps more importantly, to understand the job.

The old MCDBA certification sums it up quite well I think. It required four exams to be passed, a SysAdmin exam, a Network Infrastructure exam, a Database Development exam and a SQL Administration exam. That's quite a broad range of topics, so realistically you're likely to come at it via one of them first. I would argue that much of SQL Administration stands on the shoulders of the other three, so most people come at it via one of those routes initially. For instance a SysAdmin handling the SQL backups (my first foray into SQL many years ago), or a Developer designing the database for the code they're writing. Starting out you won't know everything, but you'll have the grounding in at least part of it, for instance the systems SQL runs on and how permissions work, or the programming methods used to talk to the database, and from there you can learn the rest.

It's hard to judge whether being a DBA is really what you want to do until you're doing it, but through the above route people are able to gradually build up to it. You may either love it and make it your career focus, or find it's not for you and stick with your previous career path, all without taking a giant leap into the unknown. But, that takes time, and that fits with DBA's tending to be "wiser in years" in the industry.

To be a good DBA you also need the confidence and maturity that tends to come with age. Others have listed other aspects of this, but I'd add having the confidence to say no and stand your ground, tempered with the experience to know when it's appropriate.

Finally, I think being a good DBA requires a certain mindset, and it's hard to know whether you have that until you've been in the trenches. Having an eye for detail, a willingness to plan ahead, the ability to look at the big picture, and a not being afraid of documenting your work are important aspects of maintaining a stable system. Some SysAdmins and Developers are like that, and can easily make the transition, while others may find that while their approach has value in their current work, as a DBA they'll struggle and find these things a chore and not enjoy the work.

Answer 14

I think that the most difficult part of at least becoming a pretty involuntary database administrator is the fact that you have to bear whatever happens to the databases of the specific organization that you have happened to stumble upon.

In my experience, my first shock was on a Monday morning when the database server crashed because of a seemingly hardware error, yet I was nevertheless suspected for having done something wrong.

You can imagine that whatever one has ever learned or exercised in their lifetime has to be applied in order to make that thing work again. Then, of course, you can create a clone and even flash back-ups of the whole thing - we are talking here just about a small database server which routes things towards other computer networks through link servers. Still, the responsibility feels tremendous during those moments.

As a software developer or as a software tester, the responsibility is also big, yet I have never ever experienced such difficult times. I can imagine that the reason lies in the fact that each of them weaves just a wee bit of the spider web of the information technology world.

If I ever do become a database administrator, I shall update on whatever I have written now here.

And, yes, I am now 38 + 1/2 years old.

Answer 15

Like most skills, learning to be a dba takes time. Becoming a good dba takes longer. The more you read and learn the more knowledge you can apply.

Another path to becoming a dba is report writing or as an application expert. The more time you spend with hands on SQL, the more you will learn about how dbs work. Becoming proficient in SQL queries will provide a good starting point for becoming a dba.