informix migration

hello all, we will be migrating to a new HP box and going to infx 9.4 at the same time. we are currently on 9.21. can anyone share ideas, experiences, etc for making a smooth transition? we believe it would be best to start with 9.4 clean on the new box (using dbexport/import) instead of putting on 9.21 and using tape to move the old data over and then upgrading to 9.40. how about methods for grabbing chunk configurations, etc for easier modifications to sizes, etc? Thanks in advance, tom

On 4 Nov 2003 06:46:58 -0800, tomcaml@yahoo.com (tomL) wrote: >hello all, > >we will be migrating to a new HP box and going to infx 9.4 at the same >time. we are currently on 9.21. can anyone share ideas, experiences, >etc for making a smooth transition? > we believe it would be best to start with 9.4 clean on the new box >(using dbexport/import) instead of putting on 9.21 and using tape to >move the old data over and then upgrading to 9.40. >how about methods for grabbing chunk configurations, etc for easier >modifications to sizes, etc? > >Thanks in advance, >tom A few observations: I think that there are tools on the IIUG website to handle chunk configuration by recreating the necessary onspaces commands. Remember that 9.4 will allow you to have chunk sizes greater than 2Gig. Another option might be to use the HPL in 'no convert' mode to unload and reload data. Dbexport and dbimport are OK, too, depending on the volume of data. JWC

Correct - also moving from 32 bit to 64 bit.....is there something in that move that has to be dealt with also? i know a recompile of UDR's is necessary but since we are doing a clean install on the 64 bit with informix 9.40, that will already be done. Thanks Tom Plus, looks like you might be moving from 32-bit to 64-bit?? Check out Art Kagel's 'dbcopy' utility, which is in his utils2_ak package at: http://www.iiug.org/software/index_DBA.html dbcopy works on a table-by-table basis, but you can copy multiple tables in parallel. dbcopy is quite fast, without having to use intermediate unload/load flat-files. I suggest that you create database and tables *only* on target, copy over data via dbcopy, then create indexes, constraints, etc. That's the strategy that I have used in the past. HTH, Paul Mosser

We are currently contemplating a very similar migration (9.21 to 9.4 on a new machine-- in our case to a new, upgraded Sun box). We are finding..., shall we say... "opportunities for professional growth" with dbexport and dbimport. Currently, we have a tech support case open with IBM on the problem, but the summary is that dbexport runs successfully and produces a .sql file that is unusable by dbimport. So, it may be that we can't use dbexport/dbimport. Apparently this problem has existed (and been documented by IBM and others) for several years, without being fixed. There is an alternative to dbexport/dbimport (which we haven't tried yet) at IIUG. The point is that IDS is an industrial strength, enterprise level product. It (and fundamental, mature, bundled utilities such as dbimport/dbexport) should absolutely work. IBM shouldn't have to depend on "the kindness of strangers" to fix necessary, basic, but defective functionality which comes bundled with their product. (In our opinion, of course-- we realize that IBM, or others, may find this level of quality perfectly acceptable. They certainly have a right to their opinions.) We, however, do have an Other :-) possible alternative on the horizon. DG "John Carlson" <john_carlson@whsmithusa.com> wrote in message news:gknfqvgmq1ueldffm1lom5ei0p6npuhifb@4ax.com... > On 4 Nov 2003 06:46:58 -0800, tomcaml@yahoo.com (tomL) wrote: > > >hello all, > > > >we will be migrating to a new HP box and going to infx 9.4 at the same > >time. we are currently on 9.21. can anyone share ideas, experiences, > >etc for making a smooth transition? > > we believe it would be best to start with 9.4 clean on the new box > >(using dbexport/import) instead of putting on 9.21 and using tape to > >move the old data over and then upgrading to 9.40. > >how about methods for grabbing chunk configurations, etc for easier > >modifications to sizes, etc? > > > >Thanks in advance, > >tom > > A few observations: > I think that there are tools on the IIUG website to handle chunk > configuration by recreating the necessary onspaces commands. Remember > that 9.4 will allow you to have chunk sizes greater than 2Gig. > > Another option might be to use the HPL in 'no convert' mode to unload > and reload data. Dbexport and dbimport are OK, too, depending on the > volume of data. > > JWC >

On Tue, 04 Nov 2003 15:10:06 -0500, tomL wrote: > Correct - also moving from 32 bit to 64 bit.....is there something in that > move that has to be dealt with also? i know a recompile of UDR's is necessary > but since we are doing a clean install on the 64 bit with informix 9.40, that > will already be done. > > Thanks > Tom > > > Plus, looks like you might be moving from 32-bit to 64-bit?? > > Check out Art Kagel's 'dbcopy' utility, which is in his utils2_ak package at: > http://www.iiug.org/software/index_DBA.html > > dbcopy works on a table-by-table basis, but you can copy multiple tables in > parallel. dbcopy is quite fast, without having to use intermediate > unload/load flat-files. I suggest that you create database and tables *only* > on target, copy over data via dbcopy, then create indexes, constraints, etc. > That's the strategy that I have used in the past. To follow up on this strategy, my dbschema replacement utility offers features to aid this process. If you give it two filenames on the commandline instead of one myschema will write all create table statements to the first file and all indexes, constraints, and privelege DDL to the second file. There is even an optional third file that can contain UPDATE STATISTICS commands to duplicate the level of stats present in the source database. Myschema is part of the package utils2_ak (as is dbcopy). Art S. Kagel > HTH, > Paul Mosser

On Tue, 04 Nov 2003 15:10:45 -0500, David E. Grove wrote: I agree. As one of the kind strangers (strange in both senses of the word ;-) and author of the 'alternative' I cannot agree more, the product should work and folk should use my tools for the extra features they provide that are too marginal for IBM to include not for basic functionality. On that note, David, you do not have to go whole hog and get myexport to replace the dbimport. It may be possible to just use myschema with its dbexport compatibility option (-l) to replace the defective schema that dbexport sometimes generates. Myschema is included in the package utils2_ak. Art S. Kagel > We are currently contemplating a very similar migration (9.21 to 9.4 on a new > machine-- in our case to a new, upgraded Sun box). We are finding..., shall > we say... "opportunities for professional growth" with dbexport and dbimport. > Currently, we have a tech support case open with IBM on the problem, but the > summary is that dbexport runs successfully and produces a .sql file that is > unusable by dbimport. So, it may be that we can't use dbexport/dbimport. > Apparently this problem has existed (and been documented by IBM and others) > for several years, without being fixed. There is an alternative to > dbexport/dbimport (which we haven't tried yet) at IIUG. The point is that IDS > is an industrial strength, enterprise level product. It (and fundamental, > mature, bundled utilities such as dbimport/dbexport) should absolutely work. > IBM shouldn't have to depend on "the kindness of strangers" to fix necessary, > basic, but defective functionality which comes bundled with their product. > > (In our opinion, of course-- we realize that IBM, or others, may find this > level of quality perfectly acceptable. They certainly have a right to their > opinions.) > > We, however, do have an Other :-) possible alternative on the horizon. > > DG > > > > > "John Carlson" <john_carlson@whsmithusa.com> wrote in message > news:gknfqvgmq1ueldffm1lom5ei0p6npuhifb@4ax.com... >> On 4 Nov 2003 06:46:58 -0800, tomcaml@yahoo.com (tomL) wrote: >> >> >hello all, >> > >> >we will be migrating to a new HP box and going to infx 9.4 at the same time. >> >we are currently on 9.21. can anyone share ideas, experiences, etc for >> >making a smooth transition? >> > we believe it would be best to start with 9.4 clean on the new box >> >(using dbexport/import) instead of putting on 9.21 and using tape to move >> >the old data over and then upgrading to 9.40. how about methods for grabbing >> >chunk configurations, etc for easier modifications to sizes, etc? >> > >> >Thanks in advance, >> >tom >> >> A few observations: >> I think that there are tools on the IIUG website to handle chunk >> configuration by recreating the necessary onspaces commands. Remember that >> 9.4 will allow you to have chunk sizes greater than 2Gig. >> >> Another option might be to use the HPL in 'no convert' mode to unload and >> reload data. Dbexport and dbimport are OK, too, depending on the volume of >> data. >> >> JWC >>

I just finish a case migration from 7.31 to 9.4,32 bit to 64 bit,But I think there are some bug in 9.4,If your 9.21 is stabily,maybe you can migrate later -- Posted via http://dbforums.com