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