Re: daily migration of Informix 9.4 databases from AIX to RedHat

What's the bottleneck for your unload/load procedure? You say it is 'becoming too slow' but by identifying the factor that slows down the procedure you can do something about it. For example, it may be that the unload is too slow. Or alternatively perhaps the Linux machine is too slow to load the data. Stefan Voets <stefan_voets@hotmail.com> wrote: > Thank you all for the tips, although I still don't feel that ER is the way > to go > > why ? > > we often have small table changes on the master server (srv1) > > so ... when using ER ... we first have to stop the replicate, delete it, > make the modifs on the 2 servers, redefine the replicate & restart it again > > people over here don't seem to like this behaviour, nor seem to be able to > adhere to this simple procedure > > anyway ... thanks > > other suggestions still welcome > > "Andrew" <ahamm@mail.com> wrote in message > news:bh9cdd$vttg8$1@ID-79573.news.uni-berlin.de... >> Stefan Voets wrote: >> > >> > srv1 AIX p-series server (AIX 5.1) & IDS 9.40.FC1 >> > srv2 intel hardware with redhat linux (8.0) & IDS 9.40.UC1 >> > >> > There are a couple of dbspaces that should be equalized every night. >> > At the moment we are using load/unloads to realize this, but the >> > entire process takes to long to complete during one night ... >> > >> > I considered following options : >> > >> > a) HDR : different OS'ses => not possible >> > c) ONBAR backup/restore => not possible because of different OS'ses >> >> Both written out principally because the processors are different. Don't >> know much about P-series, but I assume they are using the RISC-6000 chip? >> Not binary compatible with Intel. >> >> > b) ER : had a bad experience with this => not an option >> >> What bad experience? If it didn't work for you then something was not > setup >> properly. This is the premier solution I feel. Better to have a > post-mortem >> about your ER failure and solve it. It can work and does work for many >> people in exactly your situation. I can immediately think of a few reasons >> that could have killed your previous ER project - all setup issues. >> >> The trigger-and-update suggestion made by someone else is a half-arsed >> solution that is worse than ER. If the remote engine goes down, the other >> engine's SQLs will fail or at the VERY least the replication will be > broken. >> Do not consider this option. Sorry Michael - ER was invented precisely to >> get away from the problems of trigger based replication, making trigger >> based replication obsolete except on sites that, ummm, haven't been >> modernised. >> >> ONBAR suggestion: I don't know onbar sufficiently (what have I been > DOING?) >> but I'd wager the binary compatibility issue would also knock this one > down. >> >> Disk snapshots using SAN servers - once again, 6000 and Intel will not >> understand each other's data. >> >> HPL pipelined unload could work, but the source database would have to be >> totally silent during the process - ie no changes allowed or you'll get >> inconsistencies. >> >> > >