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/

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 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/

David E. Grove wrote: >Jonathan Leffler wrote: >> 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. For the database as a whole - undoubtedly. However, if any single table reaches a certain size, it becomes to big to fit into a single dbspace (under 9.40). You must then fragment the table, and (under 9.40 and earlier), each fragment must go into a separate dbspace. The majority of commercial databases have one (or a few) tables which dominate the disk space usage. > [...] I am expecting 9.4 to permit such a single large chunk. Yes. No problem. Over 4 TB for your chunk, problem (no can do). Under 4 TB for your chunk, no problem. > Even if not a single chunk, I can always create a bunch of 2G > chunks, right? You could - it isn't necessary in 9.40, but was in earlier versions. > (I never fully understood the absolute demands for >2G > chunks, since you can just create however many you need.) There are limits on the number of chunks in a dbspace, and various other similar things. However, the more practical difficulty on non-RAID systems is that you can usually only partition a disk into 8 partitions - one of which is the whole disk. So, if you had an 18 GB disk, you could create 7x2GB partitions for use by IDS, but the remaining 4GB was useless (2 GB if you were very careful). People objected to being unable to use large percentages of their disk drives. RAID-based systems don't suffer from that problem -- but using big drives directly is a problem. Consider the 250 GB disk drive you can buy for well under $200 at Fry's (an electronics/computer supplier of repute and renown in the San Francisco Bay Area); assume you lay the partitions out with the whole drive starting at offset 0 (of necessity), and then the other partions starting at multiples of 2GB. You could use 16*(1024^3) bytes of your 250*(10^9) byte disk drive (because Informix's GB are binary GB and disk drive GB are measured in decimal GB), which is under 7%. If you sacrificed the seventh and eighth partitions for use as regular file systems, you could improve things. And, of course, there were 'only' performance reasons for not using 2GB cooked files (as distinct from cooked - or block mode - devices) in those file systems. So, there were practical reasons why the 2GB limit was painful -- but RAID largely mitigated those problems. (The problem was exacerbated by the fact that the sum of the start offset of the chunk and the chunk offset could not exceed 2GB. IDS 9.40 also relieved that problem; starting offsets can be very large indeed - I'd take it under advisement whether it is up to 4TB or some other similarly large value.) > 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. Yes - proper planning and table sizing. No, not hinting at difficulties with large chunks. You can also take it as read that we recognize the need to remove the one fragment per dbspace limitation. -- Jonathan Leffler #include <disclaimer.h> Email: jleffler@earthlink.net, jleffler@us.ibm.com Guardian of DBD::Informix v2003.04 -- http://dbi.perl.org/

"David E. Grove" <david_grove@correct.state.ak.us> writes: > 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 did a single 72G dbspace for a client last year and it's worked just fine ever since. So don't sweat it. -- Forte International, P.O. Box 1412, Ridgecrest, CA 93556-1412 Ronald Cole <ronald@forte-intl.com> Phone: (760) 499-9142 President, CEO Fax: (760) 499-9152 My GPG fingerprint: C3AF 4BE9 BEA6 F1C2 B084 4A88 8851 E6C8 69E3 B00B