In the same cache vein, make sure you know what type of caching is being done at each LUN (or how ever the HP's setup). Write-thru caching won't help your write speed at all, while write-back will. The trade off is that since write-back acknowledges the write from the cache (write-thru won't acknowledge the write until it physically hits the much slower disk), there is a small chance that it may not be flushed to disk in the event of failure (e.g. power).
I don't know about HP's offering, but the FastT900 from IBM allows you to mirror your cache, plus they have a battery backup for them to flush the cache to disk in the case of power failure. So, for us, I imagine we'll head for the mirrored write-back cache option w/BBU. I think it's an acceptable risk for the gains for our particular situation. Rich Rich Jesse System/Database Administrator [EMAIL PROTECTED] Quad/Tech Inc, Sussex, WI USA > -----Original Message----- > From: Matthew Zito [mailto:[EMAIL PROTECTED] > Sent: Monday, July 21, 2003 3:04 PM > To: Multiple recipients of list ORACLE-L > Subject: RE: Oracle configuration on SAN > > > > A 14-drive RAID-5 set is very large. It's certainly > functional, but the > two problems you'll run into is problems with spindle contention and > rebuild times. With a 14-drive set, your drive is getting cut into 14 > columns, so that there's 14 different disk regions per drive it might > have to seek to in order to service any given I/O. That can > negatively > impact performance on random writes. Have you tested failing > out a drive > under load? On a 14-drive set the rebuild time is going to be pretty > horrendous, and your performance will likely be impacted unless your > cache hit numbers are really great. > > The other problem is that by carving luns globally out of a single > RAID-5 set, differing i/o patterns on the luns can create hot > spots much > more easily, since your small (comparatively, anyway) redo log volume > (for exmaple) ends up on only four columns of the disks, and other > volumes on other columns on those disks can be hurt by the constant > writing. > > While I'm not necessarily as anti-RAID 5 as some (though I > give all due > respect and worship to our mighty BAARF leaders), you need to keep a > very close eye on your array in this configuration. If you have a > normal OLTP workload (whatever "normal" is), play with your cache > allocations - the read v. write cache, and if you can do per-lun > tweaking, weight the redo and archive log lun(s) very heavily towards > write cache. > > If you're set on RAID-5, I would recommend taking two of the disks and > making them a mirrored pair for redo and archive logs. Since > the writes > tend to be reasonably contiguous, the fact you're hitting just one set > of spindles shouldn't hurt quite as bad, and cache should > take the edge > off a bit. > > This all being said, my knowledge of that particular HP array > is limited > at best, so I can't offer vendor-specific > recommendations/thoughts that > might invalidate some of these concerns. Good luck. > > Thanks, > Matt > > -- > Matthew Zito -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Jesse, Rich 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).
