Re: redo log file setup with mirrored drives

Amen to that!

Stephen,
It seems like you keep this discussion on just for the sake of discussion. And also, it seems like you live in some kind of "ideal" world, where hardware and software is 100% error-free and is 100% "bullet-proof" and "fool-proof", and SAs, DBAs, developers, etc... never make a single mistake. Good for you!
But most of us live in real world, where everything listed above is not happening (yes, we, DBAs, make mistakes too). So, we are TRYING to make our databases as reliable as possible (in particular situation), using all the features provided with oracle db including RedoLogs multiplexing (of course, using some common sense, and not creating 20 members in one group).

Igor Neyman, OCP DBA
ineyman_at_perceptron.com

• Original Message ----- To: "Multiple recipients of list ORACLE-L" <ORACLE-L_at_fatcity.com> Sent: Wednesday, November 27, 2002 8:43 AM

> >Now for those who are into this "worst scenario" thing let me ask you:
What
> >if I put your storage array between a 30HP air conditioning blower moter
and
> >a spot welder, and run a couple of paint shakers on top of the array to
> >boot. What will your vaunted Oracle multiplexing do for you then? Huh?
> >Well, smarty pants, I'm waiting!
>
> We do hardware mirroring to protect against controller and disk failures.
>
> We do redo log file multiplexing to protect against fat fingers and other
odd-ball stuff that have caused problems for an entire file system. Call it an unreliable OS, poor SA (ok, maybe even DBA) practices, whatever. The fact is that I've experienced it and I've been grateful to have the redo logs multiplexed. Each DBA can weigh the pros/cons and decide for themselves.
>
> Given your scenario above, mirroring or multiplexing within the array
would both be useless. The entire storage array would have to be mirrored. But I don't rely on my multiplexing for this type of disaster. The multiplexing is for other issues I've encountered over the years. I wish I could maintain only 1 member redo log groups. My OS is man-made and occassionally has a bug. Sometimes I'm brain-dead and make a stupid mistake. So I'm opting for all the protection I can get, because I don't want to tell our company executives that their data is unrecoverable.
>
> Jay
>
> >>> slee_at_dollar.com 11/26/02 09:49PM >>>
>
> -----------------Original Message----------------
> I believe the forgone conclusion you are talking about is that "mirroring
> outside of Oracle MAY result in data loss" MAY is a very important word.
> The multiplexing of redo logs across multiple disks and controllers is a
> simple way protect your database from potential failure.
>
> Your position appears to be that hardware mirroring, software mirroring,
> RAID hardware, and the controllers feeding them all are infallible.
> --------------------------------------------------------------------
>
> For those of you who are averse to the acquisition of knowledge through
> muscular debate, I trust you know where the DELETE button is. For the
rest
> of you ....
>
> As far as "MAY" goes, we can take that to any ridiculous extreme you wish
to
> take it. The issue is NOT: "The multiplexing of redo logs across multiple
> disks and controllers". The issue is HOW one does this. Let's get this
> back to my original post. I was responding to the implication that there
is
> some danger in using hardware mirroring such than one should not use it.
>
> As one who HAS ACTUALLY DONE BOTH and ACTUALLY USES BOTH and HAVE DONE SO
> FOR A LONG TIME (have you?) with both DATABASE and NON-DATABASE files, I
> felt it necessary to state that notwithstanding whatever armchair academia
> is floating around on the topic, I have NEVER experienced a loss with
> hardware mirroring; And have never seen a reason to imply that the
> practice has any inherent dangers. Does that mean that a problem can
never
> occur? Certainly not. Have we ever had a controller or hard drive fail?
> Yes, indeed. But, have we ever lost a database as a result? Nope.
>
> Let me turn things around on you and look at Oracle multiplexing. Has
> anyone ever lost a database who was doing Oracle multiplexing? Sure.
Well
> gosh! I thought this was supposed to keep this from happening. Why
didn't
> it?
>
> The previous posts seemed to be totally preoccupied with this apparently
> ubiquitous phenomenon of corrupt blocks. Let me ask you this: How often
> does it occur that you run your rman backup, and it detects bad blocks
that
> your OS missed or Oracle missed and failed to report? I'm just curious to
> know how prevalent these things are.
>
> Another thing that was stated by the original response was that there was
> some performance benefit to Oracle doing the multiplexing -- that Oracle
> somehow "optimizes" the process. In the case of software mirroring by the
> OS, this is a dubious statement. In the case of hardware mirroring, the
> statement is patently false and is the main reason why one would use
> hardware mirroring -- because performance demands on the system require
it.
>
> Let's take this performance thing a little further. As we have read in
many
> posts to the list, we even do such reckless and unthinkable things (at
least
> it was a few years ago) as allow storage arrays to cache our writes ...
even
> our redo writes (lions, tigers, and bears, oh my!) because performance
> demands require it. Now, you can peruse the database literature and find
an
> abundance of text on what a hideously EVIILLLLL practice this is. But we
do
> it anyway. And, saints preserve us! We don't have a landscape littered
> with lost databases.
>
> As one who has never lost a file of any kind to hardware or software
> mirroring (well ... except for the early releases of Veritas on the
Motorola
> 88K system where Veritas was a complete abortion and worse than nothing at
> all) I am going to go with my own considerable experience on the subject.
> If you wish to quote chapter and verse from this doc or that doc, that's
> great. But I'm going to go with what I have actually seen tempered by any
> tangible, objective, hard evidence I come across.
>
> Now for those who are into this "worst scenario" thing let me ask you:
What
> if I put your storage array between a 30HP air conditioning blower moter
and
> a spot welder, and run a couple of paint shakers on top of the array to
> boot. What will your vaunted Oracle multiplexing do for you then? Huh?
> Well, smarty pants, I'm waiting!
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Stephen Lee
>
>
>
>
> **DISCLAIMER
> This e-mail message and any files transmitted with it are intended for the
use of the individual or entity to which they are addressed and may contain information that is privileged, proprietary and confidential. If you are not the intended recipient, you may not use, copy or disclose to anyone the message or any information contained in the message. If you have received this communication in error, please notify the sender and delete this e-mail message. The contents do not represent the opinion of D&E except to the extent that it relates to their official business.
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Jay Hostetter
> INET: jhostetter_at_decommunications.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: Igor Neyman
  INET: ineyman_at_perceptron.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).