RE: DBA Skill tree

I suppose that depends... there's the old-school "that's how we did
things  in v6, and that's good enough for me" old-school, and there's
the old-school "I've always loved all the new features, it makes a rich
beautiful tapestry of my ever-growing and ever-changing Oracle
knowledge" old-school.  If it's the former, then, yeah, a newbie with an
OCP is a better find, but just nothing is going to beat the latter.

 

________________________________

From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx] On Behalf Of Dan Norris
Sent: Friday, April 03, 2009 9:41 AM
To: gurenich@xxxxxxxxx
Cc: sacrophyte@xxxxxxxxx; Oracle L
Subject: Re: DBA Skill tree

 

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: