--- "Jesse, Rich" <Rich.Jesse@xxxxxxxxxxxx> 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@xxxxxxxxxxxxx put 'unsubscribe' in the subject line. -- Archives are at //www.freelists.org/archives/oracle-l/ FAQ is at //www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------