Re: Redo logs on mirrored disks

I DO NOT multi-plex my redo logs BUT I have my entire production databases on RAID 0+1 mirrored/striped detests. 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 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 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.

Thnx

Chris Royce
Snr DBA
Jamestown NC

Norwood Bradly A wrote:

> Robyn:
>
> Have not yet read that tip from Steve Adams, but I value his opinions very
> highly.
>
> However, Oracle seems to go with multiplexing as shown by their caveat
> regarding o/s or hardware corruption:
>
> In my shop, we do both mirroring and multiplexing
>
> Multiplexing Online Redo Log Files
> Oracle provides the capability to multiplex an instance's online redo log
> files to safeguard against damage.
> You can also mirror your redo logs at the O/S level, but in so doing you run
> the risk of O/S or hardware induced corruption. In most cases, multiplexing
> of online logs is best.
>
> -----Original Message-----
> Sent: Monday, June 12, 2000 11:52 AM
> To: Multiple recipients of list ORACLE-L
>
> 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: rsands_at_lendleaserei.com
>
> 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: 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).
> --
> Author: Norwood Bradly A
> INET: Bradley.A.Norwood_at_M1.IRSCOUNSEL.TREAS.GOV
>
> 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: 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
Received on Mon Jun 12 2000 - 16:53:45 CDT