Data migration

I am going to move a 300G+ Informix database from one system to another, and due to several constraints (that I am not pleased about but must deal with), I am thinking of doing a dd copy from one set of disks to another. Has anyone ever done this before and survived? Examples of constraints: one tape drive (very long back/restore time), don't have a set of disks large enough to hold the DB for the intermediate step of dbexport/dbimport. Sent via Deja.com http://www.deja.com/ Before you buy.

There is one alternative to this, if you have connectivity between the two systems : Use HDR to carry out the "transfer". The main advantage of using HDR is that downtime is minimal because the process of getting the secondary up and running does not require the primary to be offline. I've actually used this method to reduce switchover time for an estimated 4-6 hours to a few minutes. Of course, HDR demands, at least, the following on both systems - Identical versions of Informix - Identical versions of OS - Identical Chunk links All the best Rudy jimm@burton.com wrote: > I am going to move a 300G+ Informix database from one system to another, > and due to several constraints (that I am not pleased about but must > deal with), I am thinking of doing a dd copy from one set of disks to > another. Has anyone ever done this before and survived? > > Examples of constraints: one tape drive (very long back/restore time), > don't have a set of disks large enough to hold the DB for the > intermediate step of dbexport/dbimport. > > Sent via Deja.com http://www.deja.com/ > Before you buy.

Hi Jimm, you can use dd only on the same machine. Of course it works, but you have to shut down the source database before the copy. If it is not a mission critical application this is not a problem. Regards Peter Dzvonyar email: sap-ext-001@ops.de p.dzvonyar@t-online.de _______________________________________________________________ jimm@burton.com schrieb: > I am going to move a 300G+ Informix database from one system to another, > and due to several constraints (that I am not pleased about but must > deal with), I am thinking of doing a dd copy from one set of disks to > another. Has anyone ever done this before and survived? > > Examples of constraints: one tape drive (very long back/restore time), > don't have a set of disks large enough to hold the DB for the > intermediate step of dbexport/dbimport. >

jimm@burton.com wrote in message <906kb0$rt6$1@nnrp1.deja.com>... >I am going to move a 300G+ Informix database from one system to another, >and due to several constraints (that I am not pleased about but must >deal with), I am thinking of doing a dd copy from one set of disks to >another. Has anyone ever done this before and survived? Since you seem to imply you have at least enough identical disks to take entire copy of dd'd database, have you considered using the mirroring method? It goes like this: Ensure 2nd engine is configured using identical config files and device names - no doubt that's part of the original plan. Remember, settings and names of devices are bogged into the dbspaces so names and settings must be identical. Setup source machine so that the target disks are in place for mirroring. If you already have mirror disks, just take them offline, hot-pull them, shove in the new ones, bring 'em online. Let the mirror recovery rewrite them. If you are not currently using mirroring, you will need to change the MIRROR parameter (but NOT the MIRRORPATH and MIRROROFFSET parameters), bounce the engine (ie stop/start) so that the mirroring functionality is switched on, and then go thru the motions of attaching mirrors to all existing dbspaces. Let the mirror setup write them for the first time. Now for the clever part. Since you want a faithful replication you will need to temporarily stop the engine. Pull the disks and when the source engine comes up it will detect total failure of all mirror devices and mark them down. You may then and only then insert the original mirrors if you had any. Mark them up, let them get refreshed.... If you don't want mirroring on the original machine, now would be a good time to detach them. Meanwhile, wander over to the new box with 20 disks balanced on both arms. For fun, try to beat the current disk-juggling record set by some anonymous drunk down the pub on night: 5. Plug 'em in to the new box. Bring that engine up. Do what you need if you want mirrors on that box too. How's that sound for a plan? It also allows all the replication to be performed on an engine that may actually be performing real work as well, and the only downtime would be the time it takes to switch on mirroring (if you aren't already using it - that requires a bounce of the engine) and then some medium level performance hit as the mirror recovery takes place on the source engine. BUT - if your task is to setup legitimate hot-swapping of boxes (ie effectively mirrored machinery) then you really should look at the official offering of replication from Informix because that's exactly what it's been invented for. Mirror the machinery and setup for hot-swapping of production database should the production box die.

Get my dbcopy utility from the package utils2_ak from the IIUG Software Repository, it will copy your table(s) for you and with the AWK scripts in my package utils3_ak you can easily use dbschema or myschema to create a dbcopy script to move the entire database in parallel using the mkdbcopy.awk script. Dbcopy is several times faster than doing the copy in dbaccess and safer than using dd and it does not require the sourcce server to be offline. Art S. Kagel jimm@burton.com wrote: > > I am going to move a 300G+ Informix database from one system to another, > and due to several constraints (that I am not pleased about but must > deal with), I am thinking of doing a dd copy from one set of disks to > another. Has anyone ever done this before and survived? > > Examples of constraints: one tape drive (very long back/restore time), > don't have a set of disks large enough to hold the DB for the > intermediate step of dbexport/dbimport. > > Sent via Deja.com http://www.deja.com/ > Before you buy.