Re: DBA Skill tree

  • From: Dan Norris <dannorris@xxxxxxxxxxxxx>
  • To: gurenich@xxxxxxxxx
  • Date: Fri, 3 Apr 2009 09:40:33 -0500

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 <gurenich@xxxxxxxxx> 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.
>

Other related posts: