RE: Multiplex Redo Logs with Mirrored Disks?

That depends on your non-failure goals, your operations schedule, the mean time between failure of your raid n-plex reliability, the time required on your system to write an entire new full backup, the mean time between failure of your database machine(s), whether you check log validity after it is archived, the error rate of parallel write to logs from Oracle (including the software, the memory, and the (I hope) two different controllers).

Oh, and whether you have a batch operation or something else that will materially benefit from *NOT* having multiple members.

For example, if you only want to fail once in 3,000 years and the time to detect an error in producing redo logs plus the time to do a full backup is enough smaller than your machine's mtbf that they should only coincide once in 4,000 years, then you're covered.

If you've got unproven raid n-plex technology (which includes brand new well known technology that is not burned in past the "new machines tend to break" period), then you probably shouldn't be running a production database on that box.

Oh, I left one out: The differential probability that you have an employee with access to the online redo logs who is stupid or mean enough to delete one and not anal enough to find redo01b and whack it right after whacking redo01a.

Seriously though: There are cases where Oracle managed members will fail
(though unlikely due to the software itself, all praise to Bill Bridge, who
locked that sucker down tighter than the cork in Cary's bottle of Cabo Wabo). There are cases when raid n-plex software will fail (though it has never actually happened to me on a machine over 3 months old. By fail, I mean all n plexes are corrupted before you can do something about it).

Unless they changed it since last I measured it, there is indeed a penalty for batch operations that might otherwise run unmolested in that there is a limit to the parallel write buffer size that is not a limit for writing a single member (right Bill? that's still in there, right?)

If all your transactions force log buffer writes frequently so that the buffer ready to write never gets up to 128K (last I really checked was a long time ago, then that parallel write penalty pretty much disappears
(completely disappears? I'm not sure but it got too small to measure a
difference when I measured it, again very long ago.) If you have one or more monolithic batch transactions that are set up to effectively use the machine as if it was a single user system (in that they don't compete for resources), then the penalty can be substantial (someone quoted a figure for some process on this current thread, so I'm buying it that that is still true.)

So do you rely on one or the other or both? Well as for me, I declared stripe and mirror everything a long long time ago because I was really really tired of quarter and half gigabyte drives making this high pitched whiny sound that I could hear in NH all the way from New Jersey that meant I had to stay up all night waiting for tapes to load. (Yes, I really could hear them, well at least once, when the operator thought it would be funny to hold the phone up to it and let me guess the problem.) Now that is not Juan's SAME, so don't confuse them. OH, the point I was making: I wouldn't ever rely on JUST Oracle multiple members for a production system. If you've got anything less than duplex on the physical media holding your online logs then you deserve sleep deprivation.

Whether you ALSO plex via multiple members per group managed by Oracle though, is a complex, situation dependent analysis. I think the thread has been a decent summation of the pros and cons, but I'd quibble with concluding either "always" or "never."

So is the any need? Yes. If you think the rate of failure of your n-plex plus other things that can go wrong is too great a risk, you can add belts to your suspenders (braces for the UK, okay) by also having multiple members in Oracle.

Best practice? There is exactly one person whose word I'd take on that, and I've never seen him chime in on a list. And even then I'd insist it is situation dependent.

Regards,

mwf

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of David Wagoner Sent: Tuesday, November 23, 2004 10:47 AM To: ORACLE-L (E-mail)
Subject: Multiplex Redo Logs with Mirrored Disks?

Is there any need to multiplex redo logs with mirrored disks (e.g., RAID-1 or RAID-1+0)?
Example- Oracle recommends multiplexing redo logs on separate disks, like redo01a.log on Disk1 and redo01b.log on Disk2, etc.

However, now that mirrored disks are in common use with RAID-1+0, RAID-1, etc. it seems that sufficient protection is in place to use only a single copy of each redo log. This would also provide the benefit of reduced disk I/O to write redo information to disk.

Anyone disagree?

Best regards,

David B. Wagoner
Database Administrator

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l