RAID array questions
OK - my PHB has decided to provide me with an HP Model 20 "Nike" disk array. Yes, Art, I will be using Raid 10 ONLY _no_ Raid 5. <g> I will also be using hardware mirroring on the array. 45 gigs mirrored (array size is 90 gigs total) IDS 7.31.UC2 HP K260 1 gig RAM 16K stripe size KAIO/all raw A few questions regarding this: 1. Should I place the root and logs dbspaces on the array w/ my data, or on separate standalone singleton SCSI drives (and controllers) mirrored via OS or Informix? 2. Do I gain anything by applying Informix fragmentation to big whopper growing tables? The array is already fragmenting everything nine ways from Sunday, yes? Should the fragmentation be fragmented? Maybe just dedicated data and index dbspaces (w/ detached indexes) for large growing tables? 3. By striping at the hardware level rather than the database level, am I not preventing IDS from utilizing multiple scan threads? IDS doesn't know that chunks are on separate drives. 4. Does anyone know if HP-UX LVM provides for staggering the starting drive pairs/stripes? Any comments appreciated. Allen W. Jantzen, DBA Ned Davis Research
allenj wrote: > > OK - my PHB has decided to provide me with an HP Model 20 "Nike" disk > array. Yes, Art, I will be using Raid 10 ONLY _no_ Raid 5. <g> I will > also be using hardware mirroring on the array. Glad to hear it, you'll be glad enough once you get going to upgrade that small grin <g> to a big one <G>! > 45 gigs mirrored (array size is 90 gigs total) > IDS 7.31.UC2 > HP K260 > 1 gig RAM > 16K stripe size > KAIO/all raw > > A few questions regarding this: > > 1. Should I place the root and logs dbspaces on the array w/ my data, > or on separate standalone singleton SCSI drives (and controllers) > mirrored via OS or Informix? Root and logs should be mirrored and should be separate from the data array as much as possible. Either use singleton drives, separate for each root and log and mirror anyway you can or create a second small RAID10 of 2 or 3 pairs and place both root and logs there. A two pair harware RAID10 should perform as well or better than two singleton pairs so... > 2. Do I gain anything by applying Informix fragmentation to big whopper > growing tables? The array is already fragmenting everything nine ways > from Sunday, yes? Should the fragmentation be fragmented? > Maybe just dedicated data and index dbspaces (w/ detached indexes) for > large growing tables? This is a religious issue. There are three camps: 1) Fragmentation gives you more control and permits parallelization and fragment elimination so you do not need striping. 2) Striping load balances best so if you stripe you don't have to fragment. 3) Striping load balances and fragmentation gives you control and paralellization. To me this sounds like "sand paper give me abrasion and a belt gives me power, so I bought a belt sander" to me! I always use both where it makes sense. (Don't use my belt sander to polish the silver!) > 3. By striping at the hardware level rather than the database level, am > I not preventing IDS from utilizing multiple scan threads? IDS doesn't > know that chunks are on separate drives. You can go round and round in this one. Hardware mirror is so much faster than IDS mirror that I cannot see the intelligence making enough difference. IDS mirror -vs- OS mirror - now there you may have a case! > 4. Does anyone know if HP-UX LVM provides for staggering the starting > drive pairs/stripes? Don't know. Also find out if the LVM can take advantage of sector zoning and vary the stripe block size by the cylinder zone on the drives. It can improve write performance by up to 25%, in our testing, through those cylinders whose zone # of sectors is not an even multiple of the stripe block (for a non-zoned scheme). You need an LVM that supports it and a drive vendor willing to reveal its sector zoning strategy. Art S. Kagel
In article <375EF943.F07685E5@bloomberg.net>, Art S. Kagel <kagel@bloomberg.net> writes >Root and logs should be mirrored and should be separate from the data >array as much as possible. Either use singleton drives, separate for Agreed, logs get sequential writes and roots dbspace gets writes to the reserved pages. >each root and log and mirror anyway you can or create a second small >RAID10 of 2 or 3 pairs and place both root and logs there. A two pair >harware RAID10 should perform as well or better than two singleton >pairs so... > >> 2. Do I gain anything by applying Informix fragmentation to big whopper >> growing tables? The array is already fragmenting everything nine ways >> from Sunday, yes? Should the fragmentation be fragmented? >> Maybe just dedicated data and index dbspaces (w/ detached indexes) for >> large growing tables? > >This is a religious issue. There are three camps: > >1) Fragmentation gives you more control and permits parallelization and > fragment elimination so you do not need striping. >2) Striping load balances best so if you stripe you don't have to > fragment. >3) Striping load balances and fragmentation gives you control and > paralellization. > >To me this sounds like "sand paper give me abrasion and a belt gives me >power, so I bought a belt sander" to me! I always use both where it >makes sense. (Don't use my belt sander to polish the silver!) Agreed, fragment elimination reduces the amount of disk I/Os required. Surely the first thing is to reduce the number of I/Os required??, then work on getting the I/O going to the right places! > >> 3. By striping at the hardware level rather than the database level, am >> I not preventing IDS from utilizing multiple scan threads? IDS doesn't >> know that chunks are on separate drives. > Read ahead can help here since read-ahead+striping = I/O to multiple drives. >You can go round and round in this one. Hardware mirror is so much >faster than IDS mirror that I cannot see the intelligence making enough >difference. IDS mirror -vs- OS mirror - now there you may have a case! > >> 4. Does anyone know if HP-UX LVM provides for staggering the starting >> drive pairs/stripes? > >Don't know. Also find out if the LVM can take advantage of sector >zoning and vary the stripe block size by the cylinder zone on the >drives. It can improve write performance by up to 25%, in our testing, Can you help me visualize this? (vary the,,zone on the drives) A simple example would help... >through those cylinders whose zone # of sectors is not an even multiple >of the stripe block (for a non-zoned scheme). You need an LVM that >supports it and a drive vendor willing to reveal its sector zoning >strategy. > >Art S. Kagel -- David Williams
David Williams wrote: > > In article <375EF943.F07685E5@bloomberg.net>, Art S. Kagel > <kagel@bloomberg.net> writes [SNIP] > >> 3. By striping at the hardware level rather than the database level, am > >> I not preventing IDS from utilizing multiple scan threads? IDS doesn't > >> know that chunks are on separate drives. > > > Read ahead can help here since read-ahead+striping = I/O to multiple > drives. Truth! [SNIP] > >> 4. Does anyone know if HP-UX LVM provides for staggering the starting > >> drive pairs/stripes? > > > >Don't know. Also find out if the LVM can take advantage of sector > >zoning and vary the stripe block size by the cylinder zone on the > >drives. It can improve write performance by up to 25%, in our testing, > Can you help me visualize this? (vary the,,zone on the drives) A > simple example would help... Sure, wish I could draw a picture but here goes the thousand words. All modern SCSI drives are zoned. That means that the outside cylinders contain more sectors than the inner cylinders and that the cylinders are grouped into zones containing the same number of sectors per cylinder per head. So, for example sake, a KagelGuchi 4000 has 16 heads and 2048 cylinders numbered from the inside out. Cylinders 0-409 make up zone one and contain 128 sectors, the next 409 cylinders contain 192 sectors, the center zone contains 256 sectors and the outer zones contain 320 and 384 sectors each. Now on a single revolution the drive can transfer (16 * 512 * 128) or 1MB from tracks in the innermost zone and (16 * 512 * 384) or 3MB from tracks on the outermost zone. If your stripe size is two MB then every I/O from/to the inner zone involves two I/Os as does every other sequential I/O from/to the outer zone. Obviously the numbers themselves do not make sense. There are usually from 8 to 50 sectors in a zone not 128 to 384. Stripe block sizes are normally 2K-64K not 2MB. However, for the example these numbers worked out cleanly so... The point is that if your LVM and its drivers can handle zone specific blocking, and if your drive vendor is willing to release its zoning scheme for your drives, the gains can be significant. > >through those cylinders whose zone # of sectors is not an even multiple > >of the stripe block (for a non-zoned scheme). You need an LVM that > >supports it and a drive vendor willing to reveal its sector zoning > >strategy. Art S. Kagel