RE: Migration question

Are you doing this with transaction logging enabled ? You can create the schema, disable transaction logging, and populate your tables using table-to-table insert scripts. (also remember to disable indexes, constraints, etc.) Or use HPL as also suggested in this thread. -----Original Message----- From: owner-informix-list@iiug.org [mailto:owner-informix-list@iiug.org] On Behalf Of David E. Grove Sent: 15 April 2005 02:01 AM To: informix-list@iiug.org Subject: Migration question We would like to migrate from 9.21 to 10.0 on a new machine. We are also changing the storage regime. In testing, dbexport (without -ss) followed by dbimport on the new machine works just fine, but it does mean the system will be unavailable for about 5 hours when we do it for real. (In our test sessions, we do the dbexport from a research machine, as described below.) We can live with this, but I'm wondering if there is a way to reduce the downtime. In the past, I have been able to reduce or eliminate downtime when portions of the data needed to be exported by creating an archive (no downtime) and then restoring the archive on a twin research machine. From the research machine I could dbexport or onunload to my heart's content. No impact on users. I'm wondering if there is some clever way to reduce downtime for the Great Migration mentioned in first sentence. I can still create an archive and restore it on the research machine, and then dbexport/dbimport from research machine to the new machine. But, that leaves the final product on the new machine several hours out of sync with the production box (it would have continued to operate). Is there an alternative to the "brute force" way of just downing the system, dbexport/dbimport from old to new system (with the new dbspaces that are unrelated to the current production system). As I said, the downtime is feasible, just not desirable. DG sending to informix-list

"Dirk Moolman" <DirkM@mxgroup.co.za> wrote in message news:1113916359.f5c9344bed508aacf59a9907985ce0e2@teranews... > > Are you doing this with transaction logging enabled ? > > You can create the schema, disable transaction logging, and populate > your tables using table-to-table insert scripts. > (also remember to disable indexes, constraints, etc.) Just to make sure I'm understanding you... You mean make the schema on the new machine (say, with dbschema). Then, write a script that, table by table, does "INSERT INTO <table-in-new-database>... SELECT... FROM <table-in-old-database>..." ? I'm thinking it might take a while. Mightn't we have problems from old tables being updated while script is running? What I mean is we might not get a consistent state of the database transferred to the new system??? I may be misinterpreting or misunderstanding. DG