Message-ID: <20040203005007.42351.qmail@web20411.mail.yahoo.com>
Date: Mon, 2 Feb 2004 16:50:07 -0800 (PST)
From: Paul Drake <discgolfdba@yahoo.com>
Subject: Re: RAID 1 or 10 for Oracle redo/control files?
To: oracle-l@freelists.org
In-Reply-To: <FBE1FCA40ECAD41180400050DA2BC54004E9367B@qtiexch2.qgraph.com>
MIME-Version: 1.0
Content-type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 8bit
Sender: oracle-l-bounce@freelists.org
Errors-To: oracle-l-bounce@freelists.org
Precedence: normal
Reply-To: oracle-l@freelists.org

--- "Jesse, Rich" <Rich.Jesse@qtiworld.com> wrote:
> Hey all,
> 
> I know this as been brought up before, but I've been
> having some difficulty
> finding specific reasons for/against RAID 10 on
> Oracle redo and control
> files.  Here's the info:
> 
> We're getting a SAN, whose initial use will be to
> house a few Oracle DBs.
> I'm proposing that our ERP DB's layout include this:
> 
> 	Redo 01	2 drives, RAID 1
> 	Redo 02	2 drives, RAID 1
> 	Control 01	3 drives, RAID 1
> 	Control 02	2 drives on server, RAID 1 (in case of
> SAN failure)
> 
> I've been asked to prove why the Redos shouldn't be
> RAID 10, because the
> striping should allow for faster writes.  I remember
> reading that this was
> nullified by the sequential nature of the writes,
> but I can't remember where
> I saw this.
> 
> Cary?  Tim?  Jonathan?  Everyone else here that I
> forgot?
> 
> THX!
> Rich
> 

Rich,

One of the things that Statspack is good for, is
examining the amount of redo written per hour, and the
aggregated waits on such, regardless of OS :)

As the user process will block on LGWR flushing the
redo buffer to disk on a commit, latency here will be
more important than throughput.

Imagine of you were being shuttled from the airport to
the hotel, and the SuperShuttle that your travel
department instructed you to take wasn't going to
leave until it was entirely full. They're optimizing
their throughput, waiting for a full run, at the
expense of your latency. Ideally, there would be a
limo waiting for you, you would not have checked any
baggage and off you go to your destination, in time to
get a decent meal from somewhere other than the 24
hour menu at the hotel.

my point is that sometimes, lower latency is much more
important than higher throughput (as in online gaming
or Voice/IP, DSL vs. cable modem).

In win32 land, I've run a utility named "filemon.exe"
from the sysinternals.com site to log file IOs against
a set of directories, or a single file. I'm sure that
there are numerous utilities in lin32 land for
obtaining the same data, I just haven't run them yet.
Maybe next week (reloading RHES 3.0 WS on the laptop
currently).

I gathered a detailed list of file IOs for the online
redo logs during certain periods. The writes were all
under 64KB, and mostly under 32KB. Many were as small
as 1024 bytes. One would have to stripe very finely in
order to have a noticeable effect on response time.
Far better to just minimize latency by dedicating
drives for online redo logs, only use say 1-2 GB of
the drive (short stroke it) and use the remainder of
the space for storing backup sets.

If you find that your writes are large, then striping
may have some positive effect for you.

If you refer to Juan Loiza's SAME paper, he advocated
having the RAID cache manage this, and still
recommended a 1 MB stripe for the RAID volumes
containing the online redo logs. His recommendations
were in the most general sense, and don't apply
equally well to all environments (say you're running
an oltp database in 32bit space with only 128 MB on
the host-based dual channel external RAID controller,
not having gigs of cache on an external storage unit).

I'd say (heuristically) to stick with OFA and
dedicate, segregate the online redo logs without
striping. A test under a representative workload for
your environment would be best. 15,000 rpm drives
would be a good idea.

As others mentioned, having 4 RAID 1 vols allocated
such that odd and even redo log members reside on
different volumes would help reduce interference from
LGWR and ARCHn, assuming 2 members per redo log group.

Pd

filemon.exe example output
1	4:42:59 PM	oracle.exe:868	WRITE 
F:\ORACLE\ORADATA\MYDB\CONTROL03.CTL	SUCCESS	Offset:
24576 Length: 8192

23792	5:03:56 PM	oracle.exe:868	WRITE 
E:\ORACLE\ORADATA\MYDB\REDO7A.LOG	SUCCESS	Offset:
11212800 Length: 1024

23780	5:03:56 PM	oracle.exe:868	READ 
H:\ORACLE\ORADATA\MYDB\USERS01.DBF	SUCCESS	Offset:
683163648 Length: 65536	


__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request@freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------