SA vs. DBA Issues With IDS and RAID 1+0

Hello all, I have read with interest the IIUG archive, and particularly Mr. Kagel's postings about the technical superiority of RAID 1+0. However, from that massive collection of postings I came away with the (possibly erroneous) impression that the high degree of fault tolerance associated with RAID 1+0 may come at the price of having a somewhat more complex IDS database to manage. Would some of you please elaborate upon the extent to which RAID 1+0 may dictate or rule out certain schema configuration options for the DBA (e.g. quantity and size of chunks and dbspaces, placement of dbspaces, whether or not table and index fragmentation is desirable). In addition, do any of you have any particular configuration suggestions to make for an IDS database application that by design has a large number of UNIX files to keep track of? In other words, instead of storing files (spreadsheets, word processing documents, etc.) within the IDS database using SLOB or BLOB data elements, the database records the location of the file on an external UNIX file system. (Don't ask.) My understanding is that one would choose a different stripe block size for the database than for the file system. Is there anything else that one ought to consider? Thanks in advance for your insightful commentary. JL

John Leyden wrote: > Hello all, > > I have read with interest the IIUG archive, and particularly Mr. Kagel's > postings about the technical superiority of RAID 1+0. However, from that > massive collection of postings I came away with the (possibly erroneous) > impression that the high degree of fault tolerance associated with RAID > 1+0 may come at the price of having a somewhat more complex IDS database > Using RAID10 will not affect your schema design choices at all. On some systems the OS cannot create more than some small number of partitions from a large pseudo drive like a RAID10 array, however the same applies to a RAID0 or RAID3/4/5 array. In all cases there is a workaround that depends on the OS. Usually a third party volume manager like Veritas VM is used to divide the pseudo disk into a number of virtual disks less than or equal to 2GB in size. > to manage. Would some of you please elaborate upon the extent to which > RAID 1+0 may dictate or rule out certain schema configuration options > for the DBA (e.g. quantity and size of chunks and dbspaces, placement of > dbspaces, whether or not table and index fragmentation is desirable). > I think what you are referring to are a number of posts asking whether it was better, with only a few mirrored pairs, to use the pairs as discrete chunks and use Informix fragmentation for load balancing or to set up a RAID10 array from the mirrors and let the stripe component handle the load balancing instead. The answer, as usual is it depends. Generally in addition to load balancing Informix fragmentation gives you parallelization and fragment elimination which RAID10 alone will not give you. However, if there are enough drives and controllers involved you can use both, and that is my usual recommendation and how I set up our servers. In other words, set up one or more RAID10 arrays and partition it. Then create a number of dbspaces from the array (or arrays) and fragment the table(s) across those dbspaces. This gets you the best of both. > In addition, do any of you have any particular configuration suggestions > to make for an IDS database application that by design has a large > number of UNIX files to keep track of? In other words, instead of > storing files (spreadsheets, word processing documents, etc.) within the > IDS database using SLOB or BLOB data elements, the database records the > location of the file on an external UNIX file system. (Don't ask.) My > understanding is that one would choose a different stripe block size for > the database than for the file system. Is there anything else that one > ought to consider? > Yes filesystems tend to perform best with a large block size, especially if individual files are large, usually 64K or 128K; while Informix does best with a blocksize of 16K or 32K. > Thanks in advance for your insightful commentary. > > JL Art S. Kagel