RE: duplexing redos and archives

I believe that oracle sets the status of the particular member in v$logfile table to 'UNUSABLE' and that it archives only the usable member. Cary has mentioned that LGWR does actually read the file to ensure consistency, so I don't believe that a corrupt file will be archived.

Mladen Gogala
Oracle DBA
Phone: (203) 459-6855
Email: mgogala_at_oxhp.com

> -----Original Message-----
> From: Alan Davey [mailto:adavey_at_competitrack.com]
> Sent: Wednesday, August 07, 2002 12:50 PM
> To: Multiple recipients of list ORACLE-L
> Subject: Re: duplexing redos and archives
>
>
> Dan,
>
> So in your scenario, what happens when Oracle goes to archive
> the redo logs? Does it first compare the duplexed versions,
> or does it just archive the first (corrupted) file in the group?
>
> Regards,
> --
>
> Alan Davey
> adavey_at_competitrack.com
> 212-604-0200 x106
>
>
> On 8/7/2002 11:54 AM, Fink, Dan <Dan.Fink_at_mdx.com> wrote:
> >Joe,
> > #2 could result from the processes/hardware path
> outside of Oracle's
> >control. For example, the redo logs are written to disks
> with separate
> >caches. Disk #1 cache soft corrupts the data being stored, but it
> >is not
> >caught by the system. Disk#2 cache writes it correctly. The key is
> >that
> >Oracle 'thinks' the log has been written correctly when it was not.
> >I'm not
> >a hardware/systems expert, but the scenario of one file
> being corrupted
> >where another is not sounds possible, but unlikely. Then again...why
> >take
> >the chance.
> >
> >
> >-----Original Message-----
> >Sent: Wednesday, August 07, 2002 6:53 AM
> >To: Multiple recipients of list ORACLE-L
> >
> >
> >Dan,
> >
> >If scenario #2 happened wouldn't both sets of logs be corrupted since
> >oracle is writing the same thing to both files?
> >
> >BTW, from the tone of everyone responding I think I'll push for
> >continuing to duplex. Thanks.
> >
> >Joe
> >
> >"Fink, Dan" wrote:
> >>
> >> This may be 'old school' thinking, but I prefer to duplex my redo
> >logs.
> >Why?
> >> Because there are some things that mirroring cannot protect you
> >against.
> >> 1. The deletion of a redo log through human error (been there,
> >recovered
> >> from it...)
> >> 2. The logical corruption of a redo log (never experienced
> it myself,
> >but
> >it
> >> is theortically possible)
> >> 3. Oracle's fault tolerance regarding the ability to function as
> >long as 1
> >> redo log in a group is accessible
> >>
> >> Considering the critical nature of the redo logs (lose one and
> >your
> >recovery
> >> is done...and perhaps your job) and their small size in relation
> >to
> >overall
> >> databse size, duplexing in a group makes sense.
> >>
> >> This is one of those issues where valid arguements exist on both
> >sides. In
> >> some ways, the logical arguements are on the side of not duplexing
> >redo
> >logs
> >> that are mirrored. However, when you consider that the loss or
> >corruption
> >of
> >> a single redo log can cause the database to be unrecoverable is
> >enough to
> >> justify the cost of duplexing.
> >>
> >> Just my humble (old school) opinion
> >>
> >> Dan Fink
> >>
> >> -----Original Message-----
> >> Sent: Tuesday, August 06, 2002 12:13 PM
> >> To: Multiple recipients of list ORACLE-L
> >>
> >> Currently we are duplexing our redo logs and archive logs through
> >> oracle. We do this at the oracle level because we are
> using mirroring
> >> (raid0?) and if we lose a redo log or archive file the database
> >will not
> >> be affected.
> >>
> >> We will be moving to raid5 arrays in the future and are wondering
> >> whether we still need to do the duplexing. Since the arrays are
> >made up
> >> of data disks plus a parity disk plus a hot swap do we need to
> >worry
> >> about losing a redo log? Our sys admins are telling us we don't
> >and I
> >> tend to agree with them but we want to get other opinions on the
> >> subject.
> >>
> >> How are shops handling this who are using raid5?
> >>
> >> Thanks.
> >> Joe
> >> --
> >> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >> --
> >> Author: Joe Armstrong-Champ
> >> INET: Joseph.Armstrong-Champ_at_tufts.edu
> >>
> >> 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).
> >> --
> >> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >> --
> >> Author: Fink, Dan
> >> INET: Dan.Fink_at_mdx.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).
> >--
> >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >--
> >Author: Joe Armstrong-Champ
> > INET: joseph.armstrong-champ_at_tufts.edu
> >
> >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).
> >--
> >Please see the official ORACLE-L FAQ: http://www.orafaq.com
> >--
> >Author: Fink, Dan
> > INET: Dan.Fink_at_mdx.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).
> >
> >
>
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.com
> --
> Author: Alan Davey
> INET: adavey_at_competitrack.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).
>

-- 
Please see the official ORACLE-L FAQ: http://www.orafaq.com
-- 
Author: Gogala, Mladen
  INET: MGogala_at_oxhp.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).