RE: redo log file setup with mirrored drives

Stephen,

        Nothing is gained by personal attacks in this forum. This forum is intended to be a learning experience for all (myself included). I suggest that you review the archived list and examine the quality of posts by Kirti, Jared, et.al. They speak for themselves.

        BTW, 2 + 2 does equal 15 for very large values of 2 and very small values of 15. ;)
Dan Fink

-----Original Message-----
Sent: Tuesday, November 26, 2002 11:50 AM To: Multiple recipients of list ORACLE-L

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: slee_at_dollar.com

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: ListGuru_at_fatcity.com (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).
-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Fink, Dan
  INET: Dan.Fink_at_mdx.com

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: ListGuru_at_fatcity.com (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).