Re: Redo logs on mirrored disks/cannot allocate new log

Thanks to Chris, Deepak, Matthew, Jonathon, Chuck and everyone else who responded to both of my questions on the redo log configuration. To address the 'cannot allocate new log' errors I was seeing during one regularly scheduled process, I plan on increasing the logs to 50MB, and adding 2 more groups for a total of 8. I started making the changes, and have seen improvement, but need a little more space to finish it up. My tuning book by Gurry and Corrigan suggested that too few checkpoints could result in data loss if the latest redo log was removed and the instance was lost. Hopefully, THAT won't ever happen, but at 50 MB, log switches/checkpoints should be very infrequent during normal processing.

As for the mirrored/mutliplex thread, I'm still not certain which approach to choose, (especially after hearing about Chris' database that outruns his vendor's application!!) I plan on talking it over with the SA and finding out more about how the mirrors are monitored. He watches everything pretty closely, and never touches the Oracle files, but unless I can monitor too, I'm not sure I'm ready to drop multiplexing and rely solely on the mirrors. Maybe when I'm gray enough to qualify for senior status ...

Robyn

Chris Royce <Chris_at_Royce.net> on 06/12/2000 07:16:47 PM

Please respond to ORACLE-L_at_fatcity.com

To: Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com> cc: (bcc: Robyn Sands/US1/Lend Lease)

Subject: 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
> also send the HELP command for other information (like subscribing).

--
Author: Chris Royce
  INET: Chris_at_Royce.net

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