Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: duplexing redos and archives

RE: duplexing redos and archives

From: Cary Millsap <cary.millsap_at_hotsos.com>
Date: Wed, 07 Aug 2002 08:49:31 -0800
Message-ID: <F001.004ADB30.20020807084931@fatcity.com>


I haven't run "truss" on LGWR lately, but it was my understanding from talking to some of the guys who wrote it that LGWR actually does some read operations to ensure integrity of the writes (at least when you let Oracle do the redo multiplexing inside the kernel).

<aside>If this is true, then of course it's one more reason *not* to use RAID 5 for your online redo log files. If it's true, then redo log I/O is not truly sequential, contrary to what most people say.</aside>

I don't have a high-volume-of-DML system to test this week, but the truss experiment should be interesting.

Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com

Upcoming events:
- Hotsos Clinic, Oct 1-3 San Francisco, Oct 15-17 Dallas, Dec 9-11 Honolulu
- 2003 Hotsos Symposium on OracleR System Performance, Feb 9-12 Dallas - Next event: NCOAUG Training Day, Aug 16 Chicago

-----Original Message-----
Sent: Wednesday, August 07, 2002 10:54 AM To: Multiple recipients of list ORACLE-L

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: Cary Millsap
  INET: cary.millsap_at_hotsos.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).
Received on Wed Aug 07 2002 - 11:49:31 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US