Re: Best way to migrate to new machine w/ min downtime.

Praxis International's (web site: http://www.praxisint.com) OmniCopy might work. It is not a data replicator as such, but a snapshot copy distribution mechanism. It extracts data from the old database (you can take whole tables or select specific rows and columns and rows), transmit it and apply it to the target using SQL transactions. By using SQL inserts it should avoid the problem of different chunk configurations. That will get you copies of the databases at a point in time. If you can't switch users over immediately then you can combine OmniCopy with Praxis' OmniReplicator. OmniReplicator transmits changed data from a source to a target, again as SQL transactions so the different chunks shouldn't matter. That way you could stop the user systems, run OmniCopy, fire up OmniReplicator and restart the user systems. OmniReplicator will keep the old and new databases in synch until you can migrate the users over. Both OmniReplicator and OmniCopy are driven off the same base of metadata defining what data is sent where, so it shouldn't take long to fire up OmniReplicator once OmniCopy is finished. And because they share the metadata, you only need to define the data movement requirements once even though you will be using one product to create the initial database copy and another product to maintain synchronization until you can get the users moved over. The metadata is defined by a common graphical user interface (OmniDirector). Cosmo Lee wrote: > > Nils Myklebust wrote: > > > > Cosmo Lee <cosmo@echonyc.com> wrote: > > > > :I need to migrate a client from one machine to another. The problem is > > :that the machine is online (pun intended) all of the time, so they can > > :only afford a minimum of downtime. > > : > > :My thought is that I need to run a level 0 archive, load that onto the > > :new machine, then just before we're ready to cut over, take the old > > :machine offline, bring the logs over from the old machine to the new > > :machine, roll them forward on the new machine, then bring the new > > :machine online. > > > > This would work if the versions of OnLine are exactly (or very near) > > the same and the machines and OS are similar enough. > > > > No, they are not the same. The OS and OnLine are the same, but the > disk/chunk partitions are not at all similar. This is the crux of my > problem. > > > :My concern is that certain utilites seem to be chunk or page specific. > > :The new machine will not have the same partitioning as the old machine. > > :So I need to avoid any utilities which would rely on such specifics. > > > > Is there any reason why you can't set up the machines to be initially > > equivalent. You do use symbolic links so even if the disks/device > > drivers aren't exactly the same it should be doable. > > > > Yes. One of the reasons we're moving to the new machine is because the > chunk allocation on the old machine is badly configured. If I set the > new machine to have the same disk/chunk configuration, I'd just wind up > with the same bad chunk configuration. So, I'm not sure what this would > do for me. > > > :Which backup utility would be best in such a case? I believe that > > :Ontape is not usable because it tries to restore to the same device, > > :(these will be different on the new machine) correct? Unload and > > :Dbexport don't keep logs after running, so I can't do a roll-forward. > > :Is OnArchive the choice in this scenario??? > > > > I don't know OnArchive very well, but judging from the problems people > > have had it may not be a good option. I don't know if it can restore > > to different dbspaces. > > > > One other idea *might* be to set up replication between the two > > machines. In that case you should be able to switch over with > > virtually no downtime at all. This of course requires fairly similar > > machines, OS and Informix versions as well. If they are too different > > you may be able to use the products from Praxis if they aren't too > > expensive for the purpose. > > > > Replication won't work because, as I said, the chunks are configured > differently. > > One solution I thought might work is to run audit trails on all the > tables of the database on the old server, dbexport, load all the data > onto the new server, then run a `restore table` on the new server with > the audit trails from the old server. But `restore table` appears to > only be available with SE. > > It seems to me a glaring omission in the product that Informix does not > provide a way to migrate data from one machine to another - of a > different configuration, without having to incur significant downtime. > > In this case, it seems the only option is to bring the old system down, > do a dbexport of the entire database, then do a complete dbimport on the > new system before we can bring up the new system. This would result in > over twelve hours of downtime given the amount of data this client has. > > My client simply cannot afford that! What do other companies do in such > a case? I can't imagine that a bank moving to a new machine could bring > down their mission-critical ATM servers for a significant amount of > time, in order to migrate hardware. It just doesn't make sense to me. > > Someone please tell me there is another way! > > -- > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * > Blah Blah Lounge - "Do You Have Something Smart To Say?" > > Cosmo Lee email: cosmo@echonyc.com Brooklyn, NY > * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * -- Joel Klebanoff Klebanoff Associates, Inc. Toronto, Ontario, Canada (416) 924-6510