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 [mailtowner-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@t eranews...
>
> 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