Re: DBA Skill tree
- From: Guillermo Alan Bort <cicciuxdba@xxxxxxxxx>
- To: dbvision@xxxxxxxxxxxx
- Date: Sun, 5 Apr 2009 21:16:01 -0300
On Sat, Apr 4, 2009 at 12:31 AM, Nuno Souto <dbvision@xxxxxxxxxxxx> 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
hth
Alan Bort
Oracle Certified Professional
--
//www.freelists.org/webpage/oracle-l
Other related posts:
