Re: raid 5 disaster

My rule for documenting procedures is that it has to be clear enough
for either my mother or father to be able to follow the instructions
WITHOUT my being there to guide them.

Leads to some VERY detailed, very simplistic instructions but no data
center I have ever worked with has complained.

IMHO, you should not have to guide the backup admin through your
procedures. He is, after all, your backup. What happens if you win the
lottery and decide to quit? Or to be a bit more morbid (as one of my
ex-bosses used to say about me) what happens if you are hit by a bus?

One thing I learned from the 9/11 disaster is that recovery procedures
should NOT assume knowledge is available. One friend (consultant) had
to help a company rebuild their databases from backups from scratch.
Every DBA had been lost in the Towers. Fortunately, he had helped them
build the systems. Unfortunately, the documentation wasn't thorough. 

This is one of my pet peeves, so excuse the rant, it's not directed at
anyone in particular. But we all tend to assume that documentation is
the LAST thing we should do, rather than the first. And we don't keep
it up to date. This is the pot calling the kettle black, I'm guilty of
it myself. But I do try.

Rachel

--- Jared.Still@xxxxxxxxxxx wrote:

> > On Fri, 13 Aug 2004 13:31:59 -0700, jared.still@xxxxxxxxxxx
> > <jared.still@xxxxxxxxxxx> wrote:
> > > See, SarbOx doesn't have to be completely dull and boring.  :)
> > 
> > ah but how do we trust the perl that you wrote to produce the
> > spreadsheet - couldn't all that abstruse code be hiding a multitude
> of
> > sins. I think we need an audit of the perl that lies behind the
> > spreadsheet of the information for the audit...
> > 
> > qui custodiet ipsos custodes
> > 
> Yes, we keep going down that road.
> 
> I wrote the database test restore procedures.
> 
> So, mgt decides to have the backup admin try it out.
> 
> Of course, he can't do it without me guiding him, just as I can't
> rebuild his servers without his help.  There is a certain level
> of knowledge assumed in this kind of documentation.
> 
> SarbOx leads to very strange conundrums.
> 
> 
> Jared
> 
> 
> ----------------------------------------------------------------
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> ----------------------------------------------------------------
> To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
> 

----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------

Other related posts: