RE: Database replication to facilitate OS upgrade.

> -----Original Message----- > From: informix-list-bounces@iiug.org [mailto:informix-list- > bounces@iiug.org] On Behalf Of Clancy > Sent: Monday, March 31, 2008 12:21 PM > To: informix-list@iiug.org > Subject: Database replication to facilitate OS upgrade. > > Hello, > Does anyone know of or have any success using any third party products > to replicate an Informix instance across two servers with different > operating systems? The reason I ask is we have a 32 to 64 bit OS > upgrade coming up this year. If I follow the IBM provided > methodology, we will be out 12 to 14 hours doing the dbexport/unload > and dbimport/load steps of this. Since it is different OS's and we > want to optimize the layout of tables and indexes, HDR will not work. > I will have a machine in waiting with 64bit OS and IDS v11 loaded up > on it. > If I could get my wish, here is what I would want to happen: > I want to replicate all of the data within our OLTP database from a > point in time from our 32-bit instance to a remote 64-bit instance. > This would have to occur without interrupting the 32-bit instance from > servicing client requests and continue to process DML. Once all the > data from the point in time is on the 64-bit instance, I would want to > replay all of the SQL statements that occurred on the 32-bit instance > since that "point in time" onto the 64 bit instance. Slowly but > surely, the difference in the data between the 64-bit and 32-bit > instance would be none. Once they are completely in sync, I could > take a small outage; redirect the clients to the 64-bit instance; and > viola, the Cheetah running on 64-bit Linux with the minimum amount of > downtime for the migration. > Is it a pipe dream? I have looked around and found a few products, > but nothing that appears to work properly. I had to do this same > thing 2 years ago from Solaris 8 to 10 and the only avenue available > was dbexport/dbimport. If we do have to take an outage, we are > considering using the HPL for speed and doing any static tables before > the outage, but as always, any pertinent insight or direction that > anyone could provide would be appreciated. It won't give you your ideal scenario, but what I have used in similar migrations is Art Kagel's "dbcopy" utility. It is overall faster than dbexport/dbimport, does not require the intermediate flat file space (unload files), and works with disparate versions / OS's. It is in the IIUG software repository, as part of the utils2_ak package. What dbcopy does is to simply copy data rows directly from one host/db/table to another host/db/table. I would recommend build your target instance, create the target db (unlogged), create tables only (no indexes or constraints), stop all activity on the source db, run script of parallel dbcopy commands to populate the data, build indexes/constraints/etc. on the target instance (using PDQ!), turn on logging for the new db, then move the clients to the new instance. Yes, it does require an outage, but it is faster than the "official" migration route. HTH, Paul M.