I was going to let the differences of opinion stand, but I suppose this
requires an answer.

> -----Original Message-----
> 
> Redo and archived redo logs are the most important files in 
> the database. 
> Lose a datafile? You can still recover the database.
> Lose all controlfiles? They can be recreated.
> Lose a single redo entry? Your recovery is terminated. Yes, there are
> unsupported methods to bypass this condition, but they are 
> kludges and may
> be very, very expensive.

While all this is true, this is all based on the forgone conclusion that
mirroring outside Oracle will result in file loss.  It is that conclusion
with which I disagree.

> So, why do I still multiplex my redo logs (even on my 'test' 
> Win2k databases
> at home)? O/S level mirroring protects against some failures, 
> but it does
> not protect against the accidental deletion of the file. I 
> have had to deal
> with situations where people deleted the redo logs (disk 
> space at 90%, let's
> clear out the log files...). Another copy on another device 
> (usually with a
> separate controller), saved the database.

In your case, your problems are not related to mirroring technique. Yours
deal with how best to handle pathological situations, shops with
non-existent security, and incompetent administration.  That's certainly a
valid topic for discussion, but isn't the topic of my discussion.

> 
> Considering the small size of the redo logs and their 
> critical importance to
> the database, I'll both multiplex (oracle) and mirror (o/s).
> 

The redo logs on our production databases are from 100 Mb to 1 Gb.  Hence,
the issue is not just one of how bullet proof things can be made, but one of
performance too.

> 
> "1.  This is pure speculation."
> Kirti is one of the many people on this list who has shown 
> time and time
> again that he does not engage in "pure speculation".

In this case he was.  He was speculating about how OS's and RAIDing hardware
go about their business and how reliably they do it.  He was speculating
that, if one does not mirror via Oracle, then one will get bad redo files.

As is commonly the case, there is some tendency to assign human qualities to
computer things; things such as "knowing" about something; and the capacity
to reason and make decisions; and the ability to have a moment of
inattention when it just "forgot" to do something right.  Computers (other
than ones named HAL) don't work this way.  The original question was posed
by someone who we can safely assume is NOT running a database on some
crapola OS with rickety, unreliable, and outdated hardware (in which case, I
don't think ANY kind of mirroring will help).  If this discussion were ten
years ago, you might have a point.  But this isn't ten years ago.

> While a skeptical
> attitude is good and helps you develop, I tend to accept 
> Kirti's posts (and
> Cary's, Tim's, Jared's, Robert's, and others on the 10 list) 
> at face value
> until I put together a test case and can prove it or disprove it.

It sounds to me like you don't intend to do either.

If Stephen Hawking attempted to tell me that, in the natural integers, 2 + 2
= 15, I would know immediately that what he was telling me was incorrect.  I
have no knowledge of Kirti's expertise in computer operating systems and
hardware.  But I do know the facts.  In my past life as a Unix sys admin, I
worked with OS's and RAID hardware enough to know that file maintenance
isn't the roll of the dice that you are making it out to be.  The suggestion
that an EMC array can't be trusted to properly mirror files raises the
question: Why did you spend a million bucks on it then?

And from another post ...
> Because my OS/hardware IS reliable a corrupted 
> log file that is mirrored outside of Oracle will be corrupt - 
> the original is corrupt, so is the mirror.

In one sentence you have claimed that your "OS/hardware IS reliable" and
talk about it corrupting log files.  Are we having a problem with the
definition of "reliable" here?

And from another post....
> Ditto.
> 
> The biggest problem with non-Oracle-mirrored  redo log is
> a personnel issue.
> 
> Take it from someone who's experienced a SA deleting all
> files from a 500 Gig DW during the middle of the day.

This goes back to an old post of using NT versus Unix.  If you recall, my
reply was that security on NT was so bad, that it is not a good choice.
This stems primarily from the fact that NT is essentially a single-user OS,
built around the administrator, with some multi-user extensions kludged on
to support non-administrator pseudo-users.

Going back to the original post on this topic: There was nothing that
suggested they were in a pathological environment.  For what it's worth,
when we had databases on NT, we followed a strict directory naming routine
and made it clear to the NT admins that any directory with certain names
were not to be touched.  If anything needed to be done with those
directories, they were to page us.

Concluding remarks:

One test of the validity and sincerity of a line of reasoning is to extend
it to its logical conclusion.  Since, last time I checked, Oracle supported
five-way mirroring, am I to assume that you do this?  Probably not.  Why
not?  After all, those redo log files are most sacred and one is sure to
suffer hell-fire and damnation if one should be "corrupted" which,
apparently, must be happening an awful lot to somebody out there.  And we
can hardware mirror the Oracle mirrors.  So why not recommend that we just
go mirror crazy?

While the scenarios of gloom and doom that have been painted by some seem to
be credible, I've have yet to witness, in my years of personal experience as
a sys admin and a database admin the unreliability that some claim to exist.
That being the case, I must go with the arrangement that I think offers
fault tolerance with the best performance.
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Stephen Lee
  INET: [EMAIL PROTECTED]

Fat City Network Services    -- 858-538-5051 http://www.fatcity.com
San Diego, California        -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).

Reply via email to