RE: Stripe and Mirror Everything?

I was always under the impression that Informix queues io requests per chunk (as seen in onstat -g ioq), so to shorten those queues it makes sense to have many chunks. However, i suppose, even if that is the case, the i/o bottleneck will always on the disk subsystem, not on the database server side. > -----Original Message----- > From: owner-informix-list@iiug.org > [mailto:owner-informix-list@iiug.org] On Behalf Of Jonathan Leffler > Sent: 15 September 2004 07:39 > To: informix-list@iiug.org > Subject: Re: Stripe and Mirror Everything? > > David E. Grove wrote: > > Thank you for commenting, Art. > > > > In my shop, I tell folks that if > <whatever-we're-discussing> has Art's > > imprimatur, just do it. :-) > > On issues of RAID, in particular, I would agree. > > > "Art S. Kagel" <kagel@bloomberg.net> wrote : > >> Sounds good to me. SOO refreshing to finally have lots of > >> influential on my band wagon. ;-) > >> > >>David Grove wrote: > >>>We are building a brand new system: [...] > >>> > >>> So (finally), the QUESTION: are there reasons NOT to use a > >>> single dbspace for everything? > > The only mild reason for being concerned about a single dbspace is if > any of the tables in your (still relatively small) database is > encroaching on the limits of what will fit in a single partition. If > you do have a large table, you will have to fragment it to keep it as > a single table, and in released code, you have to each fragment in a > separate dbspace. (There are plans to change that, but that is not > available yet.) So, if you have any big tables that might outgrow > their single fragment, you will need more dbspaces (or an upgrade to > IDS that isn't available yet). > > Otherwise, it is perfectly reasonable to use a single dbspace for > everything, basically for the reasons outlined. > > The ultra-purist might want to argue that the physical log on on > mirrored disk and the logical log on another mirrored disk might give > better performance, but you'd probably be wasting space for neglible > performance benefit and extra complexity in the setup. > > -- > Jonathan Leffler #include <disclaimer.h> > Email: jleffler@earthlink.net, jleffler@us.ibm.com > Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/ > Disclaimer http://www.shoprite.co.za/disclaimer.html sending to informix-list