Advice req -- mirroring considerations
Posted in 2000
Topics: Performance & Tuning, Server Administration, Versions, Editions & End-of-Life
Informix: IDS 7.30.uc7 (possibly 7.31.uc4 within a few months) O/S: HPUX 10.20 Hardware: HP K200 4-way (no N-class box in sight, yet) Instance size: app. 20G Here's my situation. My SysAdmin is finally able to talk about updating my production system to 'higher availability' using HPUX Mirror/UX. I'll be able to get some extra 8G and 4G drives, and the current talk was mirroring the entire system. (I may have to share a controller with the OS, but that's another issue altogether.) His recommendation was to use the 8G drives as the mirrored side of the system, while using an 8G and the 4G and 2G drives as the primary side of the system. While it sounds OK to me (relatively easy to implement), it would probably degrade performance in the event that we have a drive go bad, even though that's only happened once. (At the least, the system would still be up.) I'd like any comments about striping, as well, if you would think it beneficial. I'd like to be able to continue to use Informix fragmentation (by expression, currently), so I'd consider striping only if the argument is convincing enough. Any ideas, insights, or opinions by those of you successfully implementing and maintaining the abovementioned? Thanks in advance! -- John Carlson Informix DBA WHSmith USA #include std_disclaimer.h /* These are my opinions, not my company's opinion */
In article <387B6CA7.7AF33890@bellsouth.net>, Carlson@WHSmith <carlson1@bellsouth.net> writes >Informix: IDS 7.30.uc7 (possibly 7.31.uc4 within a few months) Now!! Don't wait...is UC5 out yet? I know that 7.32 is alive somewhere within Informix as Techinfo bug reports mention it.. >O/S: HPUX 10.20 >Hardware: HP K200 4-way (no N-class box in sight, yet) >Instance size: app. 20G > >Here's my situation. > >My SysAdmin is finally able to talk about updating my production system >to 'higher availability' using HPUX Mirror/UX. I'll be able to get some >extra 8G and 4G drives, and the current talk was mirroring the entire >system. (I may have to share a controller with the OS, but that's >another issue altogether.) > >His recommendation was to use the 8G drives as the mirrored side of the >system, while using an 8G and the 4G and 2G drives as the primary side >of the system. While it sounds OK to me (relatively easy to implement), >it would probably degrade performance in the event that we have a drive >go bad, even though that's only happened once. (At the least, the >system would still be up.) > >I'd like any comments about striping, as well, if you would think it >beneficial. I'd like to be able to continue to use Informix >fragmentation (by expression, currently), so I'd consider striping only >if the argument is convincing enough. Any ideas, insights, or opinions >by those of you successfully implementing and maintaining the >abovementioned? > >Thanks in advance! Mirroring everything onto a different controller. Stripe across the mirrors (RAID 10). Fragment there-after. Each fragment = a slice across the disks Mirrored Disk 1 +----+ +FFFF+ +rrrr+ +aaaa+ +gggg+ +mmmm+ +eeee+ +nnnn+ +tttt+ +1122+ ------ Mirrored Disk 2 +----+ +FFFF+ +rrrr+ +aaaa+ +gggg+ +mmmm+ +eeee+ +nnnn+ +tttt+ +1122+ ------ Make 1 dbspace = 1 chunk = 1 fragment = 1 striped/mirrored 2Gb device Hence each chunk is a set of stripes across mirrored disks. Each fragment is part of a dbspace i.e. part of a chunk. -- David Williams