RE: DBA Skill tree

From: Brady, Mark <Mark.Brady_at_Constellation.Com>
Date: Mon, 6 Apr 2009 10:26:10 -0400
Message-ID: <46732D8B0755664E87B4276E3C2FF6056ECBE22AEF_at_EXM-OMF-06.Ceg.Corp.Net>

I'm not sure that practicing for an exam is "nefarious". I saw my father practice for the CPA, my girlfriend practice for the MCATs, my best friend practice for the Bar. I had a book for practicing for the SAT.

If Oracle's testing regime is so predictable that practice tests can replicate to 100% accuracy, then that says something about the testing. And if testing is all that's required for certification, then again, that's says something about the program.

Other certifications outside IT require time supervised by current masters. My wife is a LCPC, a licensed counselor; they have to spend 100 hours supervised by an existing counselor. Electricians spend YEARS under the tutelage of a master before they can even become journeymen. What's missing with IT certifications is exactly that.

-----Original Message-----
From: [] On Behalf Of Johnson, George Sent: Monday, April 06, 2009 10:12 AM
Cc: Oracle L
Subject: RE: DBA Skill tree

Well said!

I was considering becoming certified and I came across lots of sites trading certification information in various pieces of software. One of the most disheartening things in almost all Oracle threads I came across was the inane boasting of morons who had simply obtained these $100 certification testing kits, learnt all the questions off by heart then simply breezed the official tests with 100% scores! Several posters in forums had achieved almost a dozen or so certifications with 98-100% pass rates using this very nefarious method to obtain their certifications.

The worrying thing is that these flim-flam cowboy's are out there in market and getting work being employed by people who do consider the certifications to be a very accurate measurement of achievement. The most annoying thing to boot is that these companies are being burned by these cowboys and the serious professionals are being left to defend themselves and their chosen field of expertise, but I suppose that's life in any business.

-----Original Message-----
[] On Behalf Of Nuno Souto Sent: 06 April 2009 14:45
Cc: Oracle L
Subject: Re: DBA Skill tree

Guillermo Alan Bort wrote,on my timestamp of 6/04/2009 10:16 AM:

Embedded comments.

> However, I must say that one without the other (be it either
> theoretical knowledge or experience) is not enough.

Precisely. 100% agreed.

> Certifications are a necessary evil.

I disagree, they most certainly are not necessary. The majority of people that directly benefit from certifications are those making money out of providing them.

> I actually got a raise after I
> got certified.

And that is a perfect example of why not. Raises should never be linked to certifications. Education, yes, absolutely.

Certifications provided by the industry itself and recognized only by said industry? Never. That is precisely what is wrong with the whole enchillada.

> 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 ;-))

Independent of your personal motivation, the certification is useless as a means of giving me any assurance the person flaunting it is motivated. Someone who has been on the job for 10 years certainly tells me he/she has, if nothing else, a commitment to the profession. Of course, it might be a case of a "*saurus". But that is my duty of care to detect and a certification will be the last thing I'll look for help.

> You are of course referring to the dreaded dbasaurus.

No I am not. In this day and age of instant gratification, 10 years might be considered a lifetime. It is far from it.

> I think that a
> long time DBA that has become stale is the worst DBA.

There is a fundamental difference between a stale dba and the job being stale by itself. This might come as a surprise to those used to the clickety-click of OEM but dbas actually do not need graphics to work out how to manage disk space in a database. The subject has been part and parcel of dba work for more than three decades, long before even Oracle itself existed. In that sense the job is itself stale. Of course, we may flash it up with spiffy graphics to make it look new, but it's still fundamentally the same thing.

 > 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)

Not so fast. Without a doubt ASM is horribly buggy in anything other than Linux. Anyone recommending it for the sake of ASM itself is doing a disservice to the client. It needs to be said and pointed out clearly. Hiding reality serves no purpose whatsoever.

Of course if RAC is involved, that changes the picture somewhat: both are horribly buggy anyways on anything other than Linux. But, I digress...

As for DMT vs LMT: I can certainly vouch for the terrible bugs in LMT upon its introduction all the way up to early 9i releases.

Even in 10g, I can say that two months ago I installed the latest patch to to avoid dbfile corruptions with LMT and ASSM. It is still that buggy!

Guess what: the same patch is needed for 11g!

Of course with 10g, I wouldn't even think of creating DMTs! Come to think of it, I haven't used DMTs since I moved to 8i.

But I certainly haven't stopped checking for patches. You know why? Because of the experience. Missing in those who think using the latest whitest and brightest is proof enough of safety and reliability.

Check with the dbas you mentioned if that was not what they meant. If it was, there is your answer. If it wasn't, you have my full support to frame them as pure dbasaurus! ;)

> That's what reporting tools are for.

No it most definitely is not. Reports don't replace analysis and reasoning. They just make it easier to visualize what is, for all intents and purposes, numbers. We still need to analyze the report. And understand its meaning and the meaning of the data behind it.

> It's like telling engineering
> students they can't use a periodic table because in the old days they
> didn't have them.

Actually, it's like telling chemical engineering students they can deduce the totality of possible chemical reactions between elements by observing the periodic table.

Any chemical engineering student will immediately explain that is simply impossible.

> 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)

I have learned to use the "new" tools. OEM has been around since release 7. That's over 15 years ago. The new html version is just a different presentation of the same information, it's not a new tool.

Sure it has new functionality. It better! But that doesn't make it a "new" tool.

Grid is, though. But that's a different kettle.

> I've utterly destroyed a few databases in my time (though through OS
> and not Oracle itself... like fsck with fs mounted)

Ah yes. You should have tried "rm -rf .*" in the old days of basic AT&T SystemV. Nothing destroyed ALL file systems more efficiently... LOL!

> 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).

I find it easier and faster to go with the head of Statspack plus a home brew script to check v$session for runaways.

EM is still too misleading in the overall status page.

What I find it incredibly useful for, with the tuning pack, is to quickly work out a better plan for a tricky statement.

I'm sick and tired of manually figuring out three-page-long Peoplesoft SQL with umpteen levels of views on views and impenetrable execution plans. On a good day. That is precisely where an automatic tool like the tuning pack becomes invaluable. It saves heaps of time.

But it's still not perfect: all it can do is fix that particular iteration or instance of that statement. If the problem is caused by some other factor than just that plain SQL, it won't go away that easy and will require lots of analysis and reflection.

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

Indeed! It's taken me a while but I finally got a set of scripts that more or less keeps that beast under control. Without a doubt the OEM front-end makes it heaps easier!

Nuno Souto
 Please consider the environment before printing
This message contains confidential information and is intended only for the individual or entity
named. If you are not the named addressee you should not disseminate, distribute or copy this email.
Please notify the sender immediately by e-mail if you have received this e-mail by mistake
and delete this e-mail from your system.
E-mail transmission cannot be guaranteed to be secure or error-free as information could be
intercepted, corrupted, lost, destroyed, arrive late or incomplete, or contain viruses. The sender
therefore does not accept liability for any errors or omissions in the contents of this message
which arise as a result of e-mail transmission. If verification is required please request a hard-copy
version. This message is provided for informational purposes and should not be construed as an
invitation or offer to buy or sell any securities or related financial instruments.
GAM operates in many jurisdictions and is regulated or licensed in those jurisdictions as required.
To the extent this email has been sent to you by any GAM company domiciled in the EU, being
GAM (U.K.) Limited, GAM Sterling Management Limited, GAM International Management Limited,
GAM London Limited, GAM Fund Management Limited, or GAM Fonds Marketing GmbH i.L.,
please note the following details in respect of each such company:
- GAM (U.K.) Limited (a company limited by shares and registered in England and Wales with
company number 01664573);
- GAM Sterling Management Limited (a company limited by shares and registered in England and
Wales with company number 01750352);
- GAM International Management Limited (a company limited by shares and registered in England
and Wales with company number 01802911);
- GAM London Limited (a company limited by shares and registered in England and Wales with
company number with Company Number 00874802)
Each of Registered Office: 12 St. James's Place, London, SW1A 1NX
GAM Sterling Management Limited, GAM International Management Limited and GAM London
Limited are each authorised and regulated by the Financial Services Authority.
GAM Fund Management Limited (a company limited by shares and registered in Ireland with no.
156828) of Registered Office: George's Court 54-62 Townsend Street Dublin 2, Ireland
GAM Fonds Marketing GmbH, i.L. (a company limited by shares and registered in Germany under
No. HRB 66857) of Friedrichstrasse 154, D-10117 Berlin, Germany. The competent Commercial
Register is "Amtsgericht Charlottenburg" in Berlin. Liquidator: Daniel Durrer.

>>> This e-mail and any attachments are confidential, may contain legal,
professional or other privileged information, and are intended solely for the
addressee.  If you are not the intended recipient, do not use the information
in this e-mail in any way, delete this e-mail and notify the sender. CEG-IP2

Received on Mon Apr 06 2009 - 09:26:10 CDT

Original text of this message