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

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 3

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 4

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 5

UPDATE 2011-05-25 11:00 EDT

In all fairness, to the SysAdmin/DBAs out there, I am adding a fourth category to the Paths of Becoming a DBA.

Becoming a DBA actually demands a great measure of experience but it can come from basically only four(4) 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 in this forum, "How Could DBAs be more 'programmer-friendly'", I mentioned being a developer for 16 years and working 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. 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 shift 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 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 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 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 the 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 the 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 role that must not be taken for granted is the that 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) describing this path. Hey, @Gauis and @Andrew, thanks for the reminder !!!

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. BTW, it just so happens I experienced the first two DBA paths starting from August 2004 at the age of 39. The 2 years of experience I had in the drafted DBA role made the transition to a fulltime DBA very enjoyable and comfortable.

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 6

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 7

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

Answer 8

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 9

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!