Re: How to perform a health check?

Noons wrote:

> Hans Forbrich <news.hans_at_telus.net> wrote in message
> news:<Muk7d.7473$223.6928_at_edtnps89>...
>

>> > For years I've complained bitterly there are
>> > no standards anywhere to define what a dba job is
>> > and how to make sure one gets the right people
>> > for it.
>> 
>> a) For the standard ... what's wrong with the definition of DBA that
>> Oracle
>> provides?  It's been part of the DBA guide since Version 5 (or earlier).

While I understand (and agree to a certain extent), my soapbox goes like this:

>
> 1- It's Oracle's definition. I want an industry standard.
> If I wanted another "defacto standard", I'd stay with
> M$ and not bother about Oracle.

If the industry is too [pick appropriate adjective] to develop/publish standards, and Oracle is willing to fill in the blank, then why buck that?

IMO our industry in general has no Standards. We have 'strongly encouraged guidelines' that are ignored any time they get in the way of short term profitability.

The closest thing we have is the 'defacto standard' that - if proposed by M$, has traditionally become a rally point; - if proposed by Oracle has resulted in the lament of "Oracle is trying to foist proprietary on us". (Proof - TSql vs PL/SQL)

Even on the tech front, implemented TCP stack is not 'pure to standard' ... and M$ tried very, very hard to usurp that (fortunately limited success with ifconfig vs ipconfig as a very simplistc example).

So far I haven't even seen a decent 'industry standard' description of Developer, Designer, SysAdmin, SecAdmin (even WebMaster) ... if you can point some out, I'd be happy to increase my knowledge base.

> 2- It is the job description of a production dba. That has
> never been enough.

A non-production DBA wears several hats and the rest of the chapter, IMO, describes a number of those hats adequately. (So does the production DBA, but not quite to the same extent.)

In their definitions, Oracle's stance seems to be "here are the _duties_ of the DBA, SecAdmin, SysAdmin, Dev, etc.". Rather than take the fight to HR, HR can use these as a guide to develop a '_job_ _description_'.

And then there's the '... And other related duties' clause <g>

> 3- It seems to imply that anything that is "technical" should
> be left to Oracle support. Sure...

Once upon a time :( that was not terribly unreasonable. Of course, we'd then split hairs on the definition of "technical". <g>

/Hans Received on Sat Oct 02 2004 - 12:13:03 CDT