Readahead is important for archiving - you want to avoid head seeks between two spindles, and on arrays where your physical disk could be shared between multiple volumes, it becomes extra important to bundle as much i/o per head read as possible, since that I/O can adversely affect other volumes as well. And since you know a read off a redolog is going to be a sequential read, it makes sense to optimize for that I/O pattern.
Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mladen Gogala > Sent: Friday, September 26, 2003 3:25 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Reality check for filesystem/disk layout > > > Can you remind me, what is readahead good for on redo files? > I believe that parallelism is much more essential for > the recovery and archiver file is usually quick enough, even > without any special tricks. > > > -- > Mladen Gogala > Oracle DBA > > > -----Original Message----- > Matthew Zito > Sent: Friday, September 26, 2003 3:05 PM > To: Multiple recipients of list ORACLE-L > > > > Avoid small stripe sizes for your redo log volumes - > especially on two-disk-only RAID sets, you'll break readahead > and write allocation on many arrays. > > Beyond that, it looks good - what kind of array are you using? > > Matt > > -- > Matthew Zito > GridApp Systems > Email: [EMAIL PROTECTED] > Cell: 646-220-3551 > Phone: 212-358-8211 x 359 > http://www.gridapp.com <http://www.gridapp.com/> > > -----Original Message----- > [EMAIL PROTECTED] > Sent: Friday, September 26, 2003 1:30 PM > To: Multiple recipients of list ORACLE-L > > > We have the luxury of moving a 300G database to a new box > that's being built and choosing the specifications, disk > layout, striping, etc. After spending the morning poring > over Cary Millsap's wonderful VLDB paper this is what we're > thinking of but I'd appreciate any comments. > > One of my main goals going in was separating redo logs into 2 > sets of disks and archive logs on a third. > > We have 16 disks to play with and seem to be winning the 1+0 > battle against some SAs who don't understand why we wouldn't > want to use RAID5. > > The database has minimal write activity during the day (other > than sorts to the temp tablespace) but huge batch write > activity at night and especially at the end of the month (the > data load time is enough of a problem that the few > partitioned tables we can easily reload are doing > unrecoverable loads). There is a lot of read activity during > the day, both single row queries from front ends that are > rolled out to several thousand people and reports that can do > some large sort/merge joins. > > Here's what we were thinking: > > 1st Disk Set - 4 72M disks RAID 1+0 > > 1st and 3rd redo log on outside > Misc. Datafiles in middle > Misc scripts and files used by other departments in center > > 2nd Disk Set - 6 72M disks RAID 1+0 > Archive logs on outside > Temp tablespace and misc. datafiles in middle > Text files used for loading in center > > 3rd Disk Set - 6 72M disks RAID 1+0 > 2nd and 4th redo logs on outside > Rollback tablespace and misc datafiles in middle > /oracle (executables and some scripts) in center > > > I was debating if there was any advantage in varying stripe > sizes across the different disk sets (since I know Cary says > redo logs like fine grained stripe sizes) but given the mix > of uses for each that doesn't seem viable= > -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Matthew Zito INET: [EMAIL PROTECTED] Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: [EMAIL PROTECTED] (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).
