Re: Stripe and Mirror Everything?

David E. Grove wrote: > Thank you, Jonathan. We always appreciate your comments-- another resource > we can "take to the bank." > > >>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 > > > I had been planning on a single 72G dbspace (a single chunk, actually [on > the RAID]). That's over 10 times the size of the whole database, and should > allow for >8 years of growth. > I would certainly consider two dbspaces - the root dbspace and a temporary dbspace. In a logged database transaction record writing (which is typically the most io intensive in an oltp system) can be reduced by having the temporary tables in a non-logged dbspace. There's also a minor benfit in that temporary dbspaces is not backed up. > I expect to create the dbspace and import a test database, today. I guess > I'll find out soon enough, but I am expecting 9.4 to permit such a single > large chunk. Even if not a single chunk, I can always create a bunch of 2G > chunks, right? (I never fully understood the absolute demands for >2G > chunks, since you can just create however many you need.) > > Anyway, I am presuming your caution about encroaching upon the limits of a > single dbspace was just to emphasize proper planning for space, and not any > kind of hint that there is any difficulty with large chunks in 9.4. > > Regards, > > DG > > > > "Jonathan Leffler" <jleffler@earthlink.net> wrote in message > news:4147D563.5070306@earthlink.net... > >>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/ > > >

"Claus Samuelsen" <csa@eye-bee-em.com> wrote in message news:41494202$0$212$14726298@news.sunsite.dk... > > I would certainly consider two dbspaces - the root dbspace and a > temporary dbspace. In a logged database transaction record writing > (which is typically the most io intensive in an oltp system) can be > reduced by having the temporary tables in a non-logged dbspace. There's > also a minor benfit in that temporary dbspaces is not backed up. > I hadn't thought of that. Would using "WITH NO LOG" clause also be a way to eliminate that overhead? I guess that would only work for explicit tables, huh? DG