I do not believe that high-end storage systems change the rules significantly
unless you can cache the entire database. If you cannot cache the entire
database, then the response time for physical reads is still important. If
physical read response time is important, then so too is I/O separation,
striping and allowing for database growth without introducing a hot spot.

Unfortunately, if the disk subsystem hides the physical disk configuration and
if you have already paid for the hardware, there is relatively little that you
can do about it. Even so, I would still choose a set of smaller file systems in
preference to one large one.


-----Original Message-----
Sent: Saturday, 2 September 2000 6:10


I will be using VxVM, VxFS and Quick I/O and a high end storage subsystem
(large cache, customisable LUN's presented to the host as "disks"), would
there be any RDBMS datafile (log, datafiles, rollback, etc.) issues if I
just create one large filesystem (striped on all available I/O channels to
that subsystem) instead of several smaller striped filesystems?  I believe
all rules change when using a high end storage subsystem as the kernel does
not actually deal with physical disks (taking into issue geometry, seek
times, rot delays...)

To illustrate:

Say a subsystem with 40 lun's of 7.0 Gb each on 4 FC-AL's (10 devices each LUN)

/orabig  - 280 Gb of 4-width stripe ( 4 FC-AL's )
vs.
10 smaller /oraNN each 28 Gb of 4-width stripe (on 4 FC ctrls)

Either config, each will fully utilise the 4-FC channels. And since the
storage subsystem is cached, fully redundant and does back end striping
itself, availability and performance I think should not be a problem.