Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> Re: Redo logs on mirrored disks

Re: Redo logs on mirrored disks

From: Chris Royce <>
Date: Tue, 13 Jun 2000 11:21:59 -0400
Message-Id: <>


    I responded to someone else as follows below:

I DO NOT multi-plex my redo logs BUT I have my entire production databases on RAID 0+1 mirrored/striped data sets. I had a nearly non recoverable situation awhile back when I lost half a mirror on a duplexed redo log. I got into one of
those infuriating 'loops' while trying to drop a logfile 'member' which had the
missing 'half': cannot drop it because it doesn't exist, cannot use it because
it was missing etc. etc. Through a lot of experimenting and stressful gyrations
we were eventually able to trick the system into thinking it was a whole entity
and was able to 'drop' the logfile. I actually do not remember what I finally

did to get around it - must have repressed a potential data loss situation on a
production instance. I had another oddball situation that caused a performance

hit. Unbeknownst to me, half of my mirrored redo logs were on a different type of controller and disk farm which was slightly older/slower. Everything ran fine
until we started generating significantly more redo. Seems that because of unequal latency, every (approx.) 4 minutes it became necessary for the archiver
to catch up and resynch the duplexed logs causing system interrupts and slowdowns.
Took us weeks with software
and hardware people to identify the situation. Simple when you find out. Anyway
I eventually dropped the duplexed redos and the performance issue disappeared.

Then we discovered the hardware discrepancy.

Just my opinion. I now have 8 single set redo logs spread over 4 spindles of 250
MBytes each. I have had no problems and have not encountered any log switch contingencies.


Chris Royce
Jamestown NC wrote:

> Hi Chris ...
> Any info you can provide on past problems would be appreciated.
> Getting ready to add some disks, and move some things around,
> and I need to decide whether to continue mirroring and duplexing,
> or choose one or the other.
> Fortunately, my SA is excellent: monitors everything, and never
> touches Oracle without talking to me, but I can't take any
> unnecessary chances with this database either.
> Robyn
> Chris Royce <> on 06/12/2000 05:00:58 PM
> Please respond to
> To: Multiple recipients of list ORACLE-L <>
> cc: (bcc: Robyn Sands/US1/Lend Lease)
> I run my Production databases on RAID 0+1 with the redo logs NOT duplexed.
> No problems in a number of years. I have had a couple of problems,
> however, with duplexed redo logs. Explanations on request.
> Chris Royce
> Jamestown NC
> wrote:
> > listers,
> >
> > Reading through Steve Adams web site, I came across
> > the tip that says redo logs should be mirrored or
> > multiplexed, but there is no need to do both. The
> > explanation makes sense, but I have never run a
> > production database without multiplexing redo logs,
> > and the thought of doing so is a little scary!! I
> > wanted to find out how many other DBA's have taken
> > this approach, and if you've tried it, how much of
> > performance difference have you seen? Is there any
> > increased risk of data loss?
> >
> > TIA ... Robyn Sands
> >
> > --
> > Author:
> > INET:
> >
> > Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
> > San Diego, California -- Public Internet access / Mailing Lists
> > --------------------------------------------------------------------
> > To REMOVE yourself from this mailing list, send an E-Mail message
> > to: (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).
> ------------------------------------------------------------------------
> Name: att1.htm
> att1.htm Type: Hypertext Markup Language (text/html)
Received on Tue Jun 13 2000 - 10:21:59 CDT

Original text of this message