Re: Mirrored disks Vs duplexed logs

From: Steve Dodsworth] <Steven_Dodsworth_at_qsp.co.uk>
Date: 1996/07/03
Message-ID: <4rdjj8$519_at_mailhost.qsp.co.uk>#1/1


In <31D97F09.2082_at_kla.com>, Raju Patel <m_patel_at_kla.com> writes:
>If Oracle receives an error on a write to a redo log, it will mark that
>logfile as STALE. As a result, if the Redo Log Group has only One
>member from Oracle's perspective, a write error would cause the entire
>group to be STALE and Oracle would have errors the next time it tries to
>write to that group. To avoid this situation, I believe it is always
>better to mirror from within Oracle than at the Operating System.
>
>Raju Patel
>Oracle Database Specialist
>Infogration Inc.
>
>
>
>Steven_Dodsworth_at_qsp.co.uk wrote:
>>
>> Hello world,
>>
>> This seems a daft question, but here goes.
>>
>> Oracle recommends having duplexed redo logs in case of disk failure. I read
>> that to be similar to mirroring. If a database resides on a system that has
>> disk mirroring, do the redo logs still have to be duplexed - I cannot think of
>> a reason to still have more than one 'database defined' copy. Does any one
>> know of any reason to keep two 'database configured' copies.
>>
>> Bye,
>>
>> Steve
>>
>> opinions expressed are mine and do not
>> necessarily represent those of my employer

Hello again,

I've since spoken to a guy from sequent, and their philosophy is to use the o/s mirroring, apparently most o/s vendors mirroring functionality is very stable and it is safe to have one redo log group mirrored across n disks. Unfortunately *some* vendors mirroring systems are not stable and therefore Oracle would recommend multiple redo log groups. If the logs are mirrored and a fault occurs when oracle attempts to write to them, the o/s will not return an error.

I suppose it is the old story of how many disks are available to hold only redo logs as per recommendations.

Thanks,
Steve

opinions expressed are mine and do not
necessarily represent those of my employer Received on Wed Jul 03 1996 - 00:00:00 CEST

Original text of this message