Re: Stripe and Mirror Everything?

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