Re: DBA Skill tree

From: Guillermo Alan Bort <>
Date: Sun, 5 Apr 2009 21:16:01 -0300
Message-ID: <>

On Sat, Apr 4, 2009 at 12:31 AM, Nuno Souto <> wrote:
> Stefan Knecht wrote,on my timestamp of 4/04/2009 12:42 AM:
>> I don't agree. After being an instructor for oracle courses for the past 3
>> years, I can say very confidently that the years of experience count for
>> nothing when it comes down to really knowing how oracle works.
> Funny. I can say exactly the opposite.
> But then again, I've been a dba for a LOT longer than 3 years.
I've been a DBA for a little over 3 years, and have taught oracle courses for about two years. When I gave the first course I was really a rookie, junior DBA who had had very little real life experience. So I stuck to the course manual and had a very hard time with students' questions. The same thing happened when I first gave the tuning course over two years ago. Giving those courses (rather than taking them) helped me to really get to understand how oracle works, and made the experience I got after that all the better. I actually learned more after giving the courses about the course topic. On one hand, this was in detriment of those who took the first few courses I gave, on the other hand, both I and the students' of my latter courses were greatly benefited.

However, I must say that one without the other (be it either theoretical knowledge or experience) is not enough.
>> There's people that "use" oracle and there's people that use oracle. How
>> long you do it doesn't really mean much. Its all about how curious you are,
>> and how much effort you put into it.
> That, I agree.
> Having said that, I'll also mention that anyone who has been a dba for 10 or
> more years PROBABLY has a little bit more commitment to the job and the type
> of work than a newb freshly painted with a "certification"?
Certifications are a necessary evil. I actually got a raise after I got certified. It was important for me since I don't have a college degree yet, and am working as a Sr. DBA... and many juniors are actually computer engineers... so I had to have some 'valid' way of showing I deserver to be Sr. (actually after a few weeks at the job it shows, but it's a nice addition to my wall ;-))

> Might be just me, but someone who shows a track record in a given profession
> is at the very least showing a willingness to stick to the job and learn
> about it.
> Of course: some might classify a long time dba as someone who has become
> stale?  I've got news for those: it *is* a stale job.  How many different
> "innovative" ways can one manage space allocation?
You are of course referring to the dreaded dbasaurus. I think that a long time DBA that has become stale is the worst DBA. I actually had a discussion with a senior dba (due to age, not knowledge) about locally vs dictionary managed tbs in 10g. He sustained that dictionary managed was better because local extent managmenet was buggy. Had a similar argument with a 9i OCP about ASM... he said that using veritas' cluster filesystem was better because ASM was buggy (though true, the result is a failed RAC implementation due to veritas' limitations and a new project using ASM)

> Yeah sure: nowadays you might look at a nice flash graphic - that
> essentially shows you nothing above the basic numbers.
> A dba trained in more traditional fashion might actually have looked at said
> numbers and tried to make some sense of them over time. Like: detect trends,
> capacity plan, find abnormal patterns of growth, etc.  Something you simply
> cannot do looking at graphics.

That's what reporting tools are for. It's like telling engineering students they can't use a periodic table because in the old days they didn't have them. If you learn to use the new tools (OEM?) you might save a great deal of time and get the same information (plus AWR/statspack reports in a neat easy-to-copy-and-paste-into-a-report html)

>> Especially nowadays, you can be a full-time full-GUI DBA using nothing but
>> enterprise manager (I'm not saying this is good, mind you) -- but you see it
>> more and more. And I honestly believe someone that works like this for 3 or
>> 4 years  has a far less good knowledge about oracle than someone taking it
>> apart for 6 months, doing so passionately.
> Don't expect anyone with little experience to do it anytime
> soon, though.
> And there is a LOT more about the dba job than simply "taking Oracle apart".

I've utterly destroyed a few databases in my time (though through OS and not Oracle itself... like fsck with fs mounted) I've used both EM (both DC and GC) and sql*plus scripts (on aix). For most tasks I take sql*plus over EM every time... except for the quick overview of the database... there's something to the performance page of EM that is just easier to perform a db tuning... (without using advisors due to license restrictions) it's like reading the head of the statspack and know where you have to drill down... EM performance page gives that... and I think that's about all I'd use EM for... at least db control. (grid control has other features).

Oh, an perhaps the dbms_scheduler interface... since I really, really don't remember any of the member functions and procedures :-P


Alan Bort
Oracle Certified Professional

Received on Sun Apr 05 2009 - 19:16:01 CDT

Original text of this message