Take the 2-minute tour ×
Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. It's 100% free, no registration required.

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?

share|improve this question
6  
I'm not sure what the comic brings to this except pleasant distraction. Anybody else? –  jcolebrand May 24 '11 at 14:32
9  
When you have finished developing, you are then fully formed and complete and eligible to be a DBA... :-) –  gbn May 24 '11 at 15:03
2  
This is a great question. It got the minds of many answering with the true passion of the DBA !!! +1 for this one !!!! –  RolandoMySQLDBA May 25 '11 at 15:18
2  
@jcolebrand - it was depicting a really DBAish solution for something really serious :) Showing the hardships associated with the life of a DBA. –  dezso Jun 22 '12 at 10:48
1  
It's not that hard, just tedious. –  glyph Jan 14 at 23:19
show 1 more comment

14 Answers 14

up vote 106 down vote accepted

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.

share|improve this answer
5  
Very Concise and Thoughtful Perspectives !!! I would give you +3 (+1 for each), but this site only lets me give +1 !!! –  RolandoMySQLDBA May 25 '11 at 15:11
3  
+1 from me as well, the bit about security breach makes me think Sony needs a new set of DBAs. –  Derek Downey May 25 '11 at 16:05
    
"The better a DBA does their job the less visibility they have." is this good thing or bad thing for the DBA ? –  zinking Aug 21 '12 at 6:29
1  
@zinking - Many occupations have tasks show progress or accomplishment and can then get recognition and reward. A DBA does not have this and only gets recognized when there are problems. Does that help? –  Leigh Riffel Aug 21 '12 at 12:05
    
@LeighRiffel my question is : it sounds like in order for a DBA to get recognition , he has to create as many problems as possible. this kind kind of explains my experience with DBA... LOL –  zinking Aug 21 '12 at 14:40
show 2 more comments

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.

share|improve this answer
1  
excellent writeup. –  jcolebrand May 24 '11 at 17:16
2  
Nonsense! Former sysadmin here. –  Gaius May 25 '11 at 7:06
    
@Gaius not nonsense, missing the sysadmin path though (so add it on!) –  Andrew Bickerton May 25 '11 at 8:03
1  
@Gauis and @Andrew, no offense taken !!! I work around at least a dozen IT gurus whose "bags I am not fit to carry." I am sure the path needed by sysadmins toward being a DBA is twice as arduous just to be a sysadmin and even more toward sysadmin/DBA. –  RolandoMySQLDBA May 25 '11 at 10:58
1  
@SqlSandwiches : I wish I started at 29 as a DBA myself. Everyone had a unique path to become the DBA we are today. We just have to conitnue writing the book on ourselves to be the DBA we can be. Cheers !!! –  RolandoMySQLDBA Jun 21 '11 at 23:07
show 3 more comments

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.

share|improve this answer
5  
+1 for "slow feedback". When a new DBA joined the team a couple of years ago, I discovered some mistakes I'd made 8 years previously. –  Jack Douglas May 24 '11 at 17:30
    
Your angle is a little different but no less important. It is also good to reflect on the realities as well. +1. –  RolandoMySQLDBA May 24 '11 at 21:22
    
+1 for "slow feedback" as well. –  Leigh Riffel Aug 20 '11 at 21:25
2  
@David regarding your slow feedback argument, in many shops it's developers' job to design tables and such. –  AlexKuznetsov Feb 23 '12 at 1:53
add comment

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

share|improve this answer
    
Hello Jack. I think being a DBA like being Project Manager. These are critical jobs needed knowledge and as also experience.. And i think if there is a bad DBA in your company, your products never be very good even if you have good developer right? –  Soner Gönül May 24 '11 at 13:54
    
A good DBA can certainly help in the development of good products, but often more important is ensuring data availability, integrity and security –  Jack Douglas May 24 '11 at 14:17
    
it is easy provided you smoothed your path out along the way !!! You struck a chord with me because data is our business and a DBA's main commodity. If it is valuable to the DBA, then the DBA will get mature enough to handle it. +1 !!! –  RolandoMySQLDBA May 24 '11 at 21:20
add comment

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.

share|improve this answer
3  
maturity in the face of adversity, I like that !!! +1. –  RolandoMySQLDBA May 24 '11 at 21:09
    
And of course you need to get the compnay back up and running in a littel time as possible. –  HLGEM Feb 1 '12 at 22:21
1  
Yes ... the "why-cant-we-just-put-this-in-the-cloud"->goat->hero->"why-cant-we-just-put-this‌​-in-the-cloud" cycle is pretty fast –  swasheck Jun 22 '12 at 17:03
add comment

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)

share|improve this answer
1  
+1 all sounds like good sense to me –  Jack Douglas May 24 '11 at 16:48
    
+1 all true, especially on the younger ages needing self-restraint (coming from someone whose 46) –  RolandoMySQLDBA May 24 '11 at 21:16
add comment

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

share|improve this answer
    
Let's hear your thoughts !!! –  RolandoMySQLDBA May 25 '11 at 21:21
3  
Short and sweet :) –  Jack Douglas May 27 '11 at 10:20
    
Ill plus one that, I like what I think you're getting at. –  Thomas Stringer Sep 5 '11 at 11:34
add comment

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.

share|improve this answer
add comment

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!". :)

share|improve this answer
add comment

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!

share|improve this answer
2  
+1 for don't be afraid to brush up on your people skills. –  Walter Mitty Apr 2 '13 at 15:07
add comment

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.

share|improve this answer
    
You make becoming a DBA sound like a life experience. Disciplined in the beginning and mellowing out as you figure out what being a DBA is along with a comfortable mastery of it. +1 !!! –  RolandoMySQLDBA Mar 8 at 4:39
add comment

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!

share|improve this answer
1  
That's the spirit. What you really learned were principles for adapting to DBA work. Field experience with Oracle opened you up to politics, people, performance and projects. Thank you for sharing your thoughts as a young DBA. +1 !!! –  RolandoMySQLDBA Mar 7 at 17:00
add comment

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.

share|improve this answer
add comment

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.

share|improve this answer
add comment

protected by Paul White May 20 at 7:03

Thank you for your interest in this question. Because it has attracted low-quality answers, posting an answer now requires 10 reputation on this site.

Would you like to answer one of these unanswered questions instead?

Not the answer you're looking for? Browse other questions tagged or ask your own question.