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: kkennedy <kkennedy_at_firstpoint.com>
Date: Tue, 06 Aug 2002 10:58:24 -0800
Message-ID: <F001.004AC76A.20020806105824@fatcity.com>


DON'T DO IT!!!! Well, that's maybe a little overstated, but not much. Raid5 has it's place and can be effective if you don't do much writing to the database.

We have a test box that was set up long ago with raid5. When we moved a copy of our transaction intensive production database to that machine and applied a full production load, the database performance went south real fast with all the wait stats pointing at a disk bottleneck. Even after extensive tuning of a bunch of bad and even not-so-bad code, performance still does the Hoover thing -- it sucks.

If you are committed to raid5 for whatever reason, keep a couple spindles out of the raid5 array and use them for the redo logs. Watch your wait statistics. You may decide that raid5 is not so great after all.

And, never ever ever listen to a sys admin who tells you to not worry about something in the database. They may understand unix but few of them understand Oracle databases and most of them are dead wrong when it comes to deciding on which disk technology to use with Oracle.

If you have a copy of Oracle Performance Tuning 101, open it to chapter 11 and share with your sys admins. If you don't have a copy, go to a bookstore and read the first page of chapter 11 -- then buy the book and share it with your sys admins. There's probably many other good sources for this type of information, but this book happens to be open on my desk at the moment.

Kevin Kennedy
First Point Energy Corporation

If you take RAC out of Oracle you get OLE! What can this mean?

-----Original Message-----
Sent: Tuesday, August 06, 2002 11:13 AM
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: kkennedy
  INET: kkennedy_at_firstpoint.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 Tue Aug 06 2002 - 13:58:24 CDT

Original text of this message

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