On Tue, 14 Sep 2004 17:46:58 -0400, DL Redden wrote:


> I read through about half of the O document and for the most part got sold
> on the idea of SAME. However there are some Informix specific maintanence
> issues that spring to mind:
>
> 1) Table and index reorgs
> 2) Is this a viable option for log files? 3) Should you let the root dbspace
> also be the temp dbspace?
>
> I would imagine that since Art gave an okay to Davids suggestion that he
> didn't see any glaring problems with the one large dbspace idea, but I would
> like to see some discussion to the points and any others that can be thought
> of.
<SNIP>

ABSOLUTELY! Let's kick this one around the block a few times. Heck, there
are so many of endless discussions of nothing here that I often expect to see
Jerry Seinfeld's sig in there somewhere. This one has an important point so
let's keep it in the air folk.

As to my agreement... OK, I definitely agree that so long as there are not
too many drives (and I would not let it get as far as the O doc does, ie into
the dozens of mirrored pairs) there's nothing wrong with using a single large
stripe. Indeed as many of you know we use a 'plaid' a stripe of 5 RAID10
sets, each made of 5 mirrored pairs, bringing 25 pairs of spindles to every
read or write. But that's my limit. I don't think I'd approve a 50 or 100
pair array as a single unit.

Keep in mind something that the O guys just glanced over - the bottleneck in a
large array is NOT the drives but the controllers. Five fast drives can
deliver data to an ULTRA320 SCSI controller faster than the controller can
cache it or deliver it to the system bus or network! Building arrays using
controllers with 16 drives on them all in the same array is going to tank on
sequential reads or large readahead (my feelings about THAT are well known as
well). So, caviat emptor!

Either way in David's configuration of 6 pairs the array size is not a problem
but I'd want to make sure there were at least 4 controllers in use, two on
each side of the mirror (plus redundancy 4 controllers of course) handling
only 3 drives each.

As to dbspaces, personally I prefer several dbspaces just for administrative
reasons, and I DO like to keep ROOT, logical logs, and physical logs on a
separate structure. I like to keep indexes and data on separate dbspaces
also, and the issue raised about fragmenting larger tables is valid whether
you are reaching the 16MM page limit or not. Again, with David's description
of their data, and his willingness, at least for now ;-), to sacrifice
performance for administrative simplicity, I don't see any major problems.

Art S. Kagel