Re: A question for great Informix minds.....
...but I'm answering anyway! From: Vickey Crouch <vcrouch@swbell.net> > >Would anyone out there like to share their thoughts on the best way to >lay out dbspaces? We have several databases, ranging from 50 mg to >200 gig in size, that we're migrating to a new platform. Our new >platform is a Sun E4500 with 8-400hz processors and 1.5 gig of RAM. We >have an A-1000 disk array with 18 gig drives (10,000 r.p.m.), and a >single controller. The storage array is set up with a hardware level >RAID-5 configuration. We're using Veritas to manage storage. The new >platform will be running IDS 9.2 with Solaris 2.7. The 10 Golden rules are: Rule number 1: Don't use RAID 5. Rule number 2: Don't use RAID 5. Rule number 3: Don't use RAID 5. Rule number 4: Don't use RAID 5. Rule number 5: Don't use RAID 5. Rule number 6: Don't use RAID 5. Rule number 7: Don't use RAID 5. Rule number 8: Don't use RAID 5. Rule number 9: Don't use RAID 5. Rule number 10: Don't use RAID 5. Rule number 11: There is no rule number 11. >We're trying to decide how many dbspaces we should allocate. Should we >allocate at least one dbspace for each database, regardless of the >size? Should we allocate one dbspace to dump all of the little >databases into? Should we allocate multiple dbspaces for the large >databases? Are there any advantages to fragmenting dbspaces with a >RAID-5 configuration? Any suggestions for a good chunk naming >convention? Stripe across multiple disks, create a separate dbspace for each database (to allow restores [and possibly backups] of individual databases), multiple dbspaces will only be useful for a large dbspace if you can make use of fragment elimination or PDQ, and I'd have to see how your system was used before I could comment. Set up /usr/chunks, a separately mounted filesystem. Make a set of links to actual raw disk in /usr/chunks/fast, medfast, medslow and slow (your sys admin should know what I'm on about). Call these links /usr/chunks/fast/fast01 - fastN, medfast/medfast01 - N, etc. Then create a set of links in /usr/chunks/informix/instancename which link to the previously created set of links with names like rootdbs_0, datadbs1_0, etc. (trust me on this). This allows two perspectives on the links, one from the sys admin side and one from the dba side. So, for example, rootdbs will point to /usr/chunks/informix/obnoxio/rootdbs_0 which will link to /usr/chunks/fast/fast01 which will link to /dev/md/rdsk/d5 (or whatever) Links to additional chunks would be called rootdbs_1, etc. ______________________________________________________ Get Your Private, Free Email at http://www.hotmail.com
Obnoxio The Clown wrote: > > ...but I'm answering anyway! > > From: Vickey Crouch <vcrouch@swbell.net> > > > >Would anyone out there like to share their thoughts on the best way to > >lay out dbspaces? We have several databases, ranging from 50 mg to > >200 gig in size, that we're migrating to a new platform. Our new > >platform is a Sun E4500 with 8-400hz processors and 1.5 gig of RAM. We > >have an A-1000 disk array with 18 gig drives (10,000 r.p.m.), and a > >single controller. The storage array is set up with a hardware level > >RAID-5 configuration. We're using Veritas to manage storage. The new > >platform will be running IDS 9.2 with Solaris 2.7. > > The 10 Golden rules are: > > Rule number 1: Don't use RAID 5. > Rule number 2: Don't use RAID 5. > Rule number 3: Don't use RAID 5. > Rule number 4: Don't use RAID 5. > Rule number 5: Don't use RAID 5. > Rule number 6: Don't use RAID 5. > Rule number 7: Don't use RAID 5. > Rule number 8: Don't use RAID 5. > Rule number 9: Don't use RAID 5. > Rule number 10: Don't use RAID 5. > Rule number 11: There is no rule number 11. SURE the is: Rule number 11: See rules 1-10! > >We're trying to decide how many dbspaces we should allocate. Should we > >allocate at least one dbspace for each database, regardless of the > >size? Should we allocate one dbspace to dump all of the little > >databases into? Should we allocate multiple dbspaces for the large > >databases? Are there any advantages to fragmenting dbspaces with a > >RAID-5 configuration? Any suggestions for a good chunk naming > >convention? Yes. Name each chunk's link after the dbspace to which it will belong. If you use a disk/controller/partition based scheme you WILL be sorry later when you have to move some chunk to another drive for some reason or want to duplicate the server on another system using backup/restore and the disk configurations differs. After that the names will make no sense and only serve to confuse anyone relying on them. Let the links point to device names based on a hardware related scheme but the links should be server based. IE: dbs_1_chk_1, dbs_1_chk_2 > Stripe across multiple disks, create a separate dbspace for each database > (to allow restores [and possibly backups] of individual databases), multiple > dbspaces will only be useful for a large dbspace if you can make use of > fragment elimination or PDQ, and I'd have to see how your system was used > before I could comment. > > Set up /usr/chunks, a separately mounted filesystem. Make a set of links to > actual raw disk in /usr/chunks/fast, medfast, medslow and slow (your sys > admin should know what I'm on about). Call these links > /usr/chunks/fast/fast01 - fastN, medfast/medfast01 - N, etc. > > Then create a set of links in /usr/chunks/informix/instancename which link > to the previously created set of links with names like rootdbs_0, > datadbs1_0, etc. (trust me on this). > > This allows two perspectives on the links, one from the sys admin side and > one from the dba side. > > So, for example, rootdbs will point to > /usr/chunks/informix/obnoxio/rootdbs_0 which will link to > /usr/chunks/fast/fast01 which will link to /dev/md/rdsk/d5 (or whatever) > > Links to additional chunks would be called rootdbs_1, etc. > ______________________________________________________ > Get Your Private, Free Email at http://www.hotmail.com -- Art S. Kagel & Family kagel@erols.com
Hello. "Art S. Kagel & Family" wrote: > Obnoxio The Clown wrote: > > The 10 Golden rules are: > > Rule number 1: Don't use RAID 5. ...... > > Rule number 10: Don't use RAID 5. > Rule number 11: See rules 1-10! Can You please estimate ( in % ) performance increasing after switching the drive from RAID 5 to RAID 10? > Art S. Kagel & Family > kagel@erols.com Leonid Vorontsov Leonids.Voroncovs@dati.lv
Leonids.Voroncovs@dati.lv wrote: > Hello. > "Art S. Kagel & Family" wrote: > > > Obnoxio The Clown wrote: > > > The 10 Golden rules are: > > > Rule number 1: Don't use RAID 5. > > ...... > > > > Rule number 10: Don't use RAID 5. > > Rule number 11: See rules 1-10! > > Can You please estimate ( in % ) performance increasing after > switching the drive from RAID 5 to RAID 10? You should expect the performance of an N-1 pair RAID 10 array, as compared to an N-way RAID5 array, to be 0-20% faster on reads (due to the ability to read either side of each mirrored pair) and 80-100% faster on writes. HOWEVER, the performance improvement, while nothing to sneeze at, is NOT the primary reason that I vehemently oppose the use of RAID5. Because of its design NO RAID5 IMPLEMENTATION can protect your system from unrecoverable damage to your data which is caused by partial media failure! RAID10 will. Period. Oh and to the poster who last year could not figure out why RAID10 is safe and RAID5 is not, I finally remembered the answer (duh). Each side of a RAID10 pair is written independently so if the data on one drive cannot be read successfully it will show as corrupt to Informix and the chunk marked down. You can then recover the damaged drive from its mirror and bring everything back up since the mirror will not be damaged. On RAID5 if a sector becomes garbage and another sector of the same stripe block is modified, since RAID5 does NOT verify its checksums EVER, the checksum will be updated with the garbage on the damaged sector and your data is now lost forever! Art S. Kagel > > > > Art S. Kagel & Family > > kagel@erols.com > > Leonid Vorontsov > Leonids.Voroncovs@dati.lv