RE: Oracle configuration on SAN

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
rjesse_at_qtiworld.com                  Quad/Tech Inc, Sussex, WI USA

> -----Original Message-----
> From: Matthew Zito [mailto:mzito_at_gridapp.com]
> 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.
Received on Mon Jul 21 2003 - 14:51:25 CDT