Re: disk layout san raid5

wane wrote:
> We are migrating an Oracle9i (9.2.0.7.0) database to an AIX 5300-04
> LPAR which is allocated disk from a DS4500 which is setup into 2 RAID5
> array groups. The disk is presented to AIX as 2 "LUN"s (or hdisks) with
> one from each RAID5 array group. We are upgrading the third party
> application so we have the opportunity to do a complete exp/imp and
> restucture the disk since a full test cycle will be performed.
> Currently there are a "maze" of tablespaces/datafiles for
> tables/indexes (about 65GB space usage). Oh, and all disk is allocated
> through Virtual I/O LPARs and with a SVC layer in front of the DS4500.
>
> I am proposing to reduce the number of tablespaces (maybe even just 1)
> and use 2 datafiles for each tablespace with each datafile on a
> separate hdisk (ie LUN).
>
> Question: is there any performance advantage to more and smaller
> tablespaces and/or datafiles even though they technically exist on the
> same physical disk?
>
> Any comments would be appraciated. Thanks.

I don't think there is any performance difference because Oracle has its own ideas of how to round-robin the segments within the tablespace as they are created. That's why SAME works. According to some people there is some performance deterioration under the covers in a unix filesystem when you free and reuse blocks, so that is an argument for making a few large files right after making the filesystem. You can get a better parallelization for RMAN if you have many files about the same size rather than a few files of wildly different size. There is a management benefit to keeping indices in their own tablespaces, but no performance benefit. There are definite advantages to using locally managed tablespaces over dictionary managed, including performance. Some (if not all) files will perform better if you don't use RAID-5 - even if you have humongous battery-backed cache, at some point it gets swamped and performance goes in the toilet. Redo and archiving are particularly vulnerable. Rebuilding parity when you swap a disk can highlight these issues. For a good time, pull a second disk while rebuilding.

For RAID, performance is dependent on how much you can spread across spindles and controllers. Halving the number of spindles may not be the best route, unless it helps you have more controller bandwidth. YMMV. jg

--
@home.com is bogus.
Mmmmmm...
http://www.nctimes.com/articles/2006/05/29/news/coastal/52806193359.txt