RE: dbspaces migrating from 7.3 to 9.4

Gary This has been discussed previously without any conclusive results. My personal view is that you should create several spaces for your data and some more for your indexes. Split your heavily used tables out to separate spaces. Try to get through any LVM and place each space on its own spindle where possible. Where you have more that (say) 5 million rows in a table then put the indexes in their own dbspace. Between 1 and 5 million rows then detach the indexes in the same space. Less than 1 million rows keep the indexes attached. Pick two or three chunks sizes and stick to them (makes admin easier and more understandable to 'strangers'). I would suggest some 4Gb chunks and some 8Gb chunks. I have just been through the same exercise with the above 'rules' and have produced (what I consider to be) a well balanced engine which achieves excellent performance (some of this may be due to massive increases in proc speed and memory, but hey! whose counting :-) ). Joking aside my view is several spaces makes admin much easier and improves performance if they are on separate spindles. Keith -> -----Original Message----- -> From: Gary Quiring [mailto:gquiring@gmail.com] -> Sent: Friday, April 21, 2006 12:45 PM -> To: informix-list@iiug.org -> Subject: dbspaces migrating from 7.3 to 9.4 -> -> -> I am moving a 7.3 DB to 9.4 on a new server. With the 7.3 -> DB I have 110 2gig -> spaces. Should I just make the 9.4 one large space or are -> there issues with -> making dbspaces that large? The new server will be about -> 300gig of raw space. -> -> Thanks -> Gary Quiring -> -> _______________________________________________ -> Informix-list mailing list -> Informix-list@iiug.org -> http://www.iiug.org/mailman/listinfo/informix-list -> ********************************************************************************** This message is sent in strict confidence for the addressee only. It may contain legally privileged information. The contents are not to be disclosed to anyone other than the addressee. Unauthorised recipients are requested to preserve this confidentiality and to advise the sender immediately of any error in transmission. This footnote also confirms that this email message has been swept for the presence of computer viruses, however we cannot guarantee that this message is free from such problems. **********************************************************************************

I think David Williams previously pointed out that very large chunk sizes might susceptible to long checkpoint times. I've created some large chunks and been advised by IBM Informix Tech Support that more, smaller dbspaces (specifically dbspaces, not chunks) will give better checkpoint performance. Although I have not actually personally been convinced by the argument some pretty smart people on here, including Art, Marco and Obnoxio have given the same advice. >> My personal view is that you should create several spaces for your data and some more for your indexes. Split your heavily used tables out to separate spaces. Try to get through any LVM and place each space on its own spindle where possible. You write like a man stuck in the 1980s, Keith, rather than somone who has a shiny and expensive SAN that takes care of all this sort of stuff for him ... >> Pick two or three chunks sizes and stick to them (makes admin easier and more understandable to 'strangers'). You've never been a contractor then ...? ;-)

Captain Pedantic wrote: > I think David Williams previously pointed out that very large chunk sizes > might susceptible to long checkpoint times. I've created some large chunks > and been advised by IBM Informix Tech Support that more, smaller dbspaces > (specifically dbspaces, not chunks) will give better checkpoint performance. > Although I have not actually personally been convinced by the argument some > pretty smart people on here, including Art, Marco and Obnoxio have given the > same advice. > Yes I have. At checkpoint time one page cleaner gets assigned to each chunk. If you have a very large chunk the a single page cleaner gets assigned. The means at most 1 cpu can be submitting the i/o requests. Also if you get a disk error the smallest item you can restore is a single dbspace. I would rather restore a 32Gb dbspace than a 300Gb one! Finally if you are backing up or restoring 300Gb you probably want to do that in parallel. You can use onbar and ism to get 4 parallel streams but they backup dbspaces in parallel. With one dbspace you get no parallelism. You might also want to consider fragmenting tables/indexes to get better performance as well. For that you need multiple dbspaces. I would use 4/8 gb chunks and 32Gb dbspaces. > >> My personal view is that you should create several spaces > for your data and some more for your indexes. > Split your heavily used tables out to separate spaces. > Try to get through any LVM and place each space on its own > spindle where possible. > > You write like a man stuck in the 1980s, Keith, rather than somone who has a > shiny and expensive SAN that takes care of all this sort of stuff for him > ... > > >> Pick two or three chunks sizes and stick to them (makes admin > easier and more understandable to 'strangers'). > > You've never been a contractor then ...? ;-)