Re: DBA Skill tree

From: Kerry Osborne <>
Date: Fri, 3 Apr 2009 10:38:52 -0500
Message-Id: <>

I have to say that I think experience is very important - up to a point. There seems to me to be some minimum amount that is necessary to be really good at what you do. Malcolm Gladwell talks about that in his book Outliers. One of his examples was getting into medical school. You had to be good enough to get in, but the difference between the ones that got in easily and the ones that didn't have the great MCAT scores, was not a reliable predictor of success as a doctor. His point was that there was a threshold above which other factors became much more important. You had to clear the hurdle and then other factors (hard work was one of his favorites) came into play. I think he's right. Their does seem to me to be a minimum amount of experience which a DBA needs and unfortunately I think that minimum is higher than most of would like to admit. I have rarely seen anyone with less than 5 years of experience that really had a good grasp on being a DBA. After that the willingness to work hard and the problem solving skills in my book become the top predictors of success.

Kerry Osborne

On Apr 3, 2009, at 9:40 AM, Dan Norris wrote:

> Maria,
> I hope you mean that experience should be a contributor, but not the
> *only* factor. While I agree that many "old school" DBAs could
> handle issues more readily than some newbies, I'd say that most of
> the "old school" DBAs I've encountered in my consulting travels are
> the "out of touch" type. That is, they have lost most of the theory
> and have maintained the same environment(s) for so long that the
> problems they can solve are the ones that happen regularly to them.
> They faint/fail at new or unknown issues. That is my personal
> experience and the new or unknown issues weren't particularly tough
> ones. I'd say I've been asked to provide help (consulting) to more
> "old school" DBAs than newbies over my years. However, that's
> probably also because the "old school" DBAs are often in larger
> shops that have bigger environments (and usually bigger problems to
> go with them).
> I agree that experience should be a factor, but I also acknowledge
> that as a consultant working on issues for 2-3 weeks at a time, I
> was able to gain more relative experience (i.e. seeing/solving more
> problems) than many "old school" DBAs would see in several years.
> That's just the nature of break-fix consulting. I describe it like
> dog years (and it feels like that sometimes too!).
> Summary: "Experience" means different things in different situations.
> Dan
> On Fri, Apr 3, 2009 at 9:24 AM, Maria Gurenich <>
> wrote:
> Well, how about years of experience for starters? IMHO, OCP with 2
> years of experience could not beat old school DBA with 10 years of
> experience even though the newbie thinks that he/she knows all new
> features. I haven't had chance to wrote down my thoughts, but being
> on a couple of interview so far, I end up with something like this:
> newbie - from school to 2 yrs of experience, is able to maintain
> database without unexpected downtimes, is able to make, test and
> keep backups and recovery and even if doesn't know for sure, feels
> with his/her guts where the problem is.
> standart - 2-5 yrs, includes all basics, is able to assess, judge,
> improve the existing strategies, is able to predict and plan before
> hand, understands company's benefits "using RMAN instead of
> hotbackups", does not need significant amount of time to figure out
> where the problem is, is ready with the correct (reasonable) answer
> for almost all questions.
> advanced - 7+ yrs, should be standart for all these years, and also
> be an expert in non-standart features: RAC, HA, RASP, architecture
> design.. Should be heavily involved in business part of the deal,
> meaning that he/she not only maintains his/her databases, but
> totally understands the business needs and the impact of downtime.
> This would be somebody who understands hardware part, is able to
> distinguish between small nuances, has a solid knowledge of database
> internals, is able to work productively without any gudget/tool,
> e.g. can fix anything from the command line balancing his/her laptop
> on the knee. Somebody who is able to train newbie and standart, who
> understands that database IS for developers rather than something
> that he/she has to protect FROM developers. Please, don't
> underestimate this fact. I've seen a lot of experienced DBAs, who
> absolutely seriously think that their job is to protect the database
> from intruders like developers and end users. IMHO, these are
> obvious signs of unripeness.

Received on Fri Apr 03 2009 - 10:38:52 CDT

Original text of this message