Re: Checking the replication
See below.... "Colin Bull" <Colin.Bull@videonetworks.com> wrote in message news:cfa6vu$l74$1@news.xmission.com... > > Madison Pruet wrote > > > I will be giving a replication tutorial at the user > > conference which will include various ways to verify > > replication tables are in sync as well as providing a toolkit > > of several utilities to aid in replication support. > > > Where is this ? Currently on my workstation. ;-) > And if us plebs cannot get there, are there likely to be any resources > we can download ? I can't make the toolkit available until after user conference. I'm not sure if I will be able to make the presentation available or not since it is a tutoral. > > By coincidence I have just received a project which states - > REQ-6: Enterprise Replication will be able to recover synchronisation > up to 48 hours after a database failure. No problem. Even if we destroy and restart the replication. > REQ-7: DBA's will be able to prove that the servers are synchronised. This may be a problem unless the tables are quiesent and the queues are drained. Remember with continuous replication, stuff is constantly changing. It's bad enough with a simple source/target. But consider the situation with multiple nodes with update anywhere. However, the resync tool works in a reporting mode which would give an idea of how in-sync/out-of-sync the tables are (ignoring inflight data). > REQ-8: DBA's will be able to synchronise servers that have become > unsynchronised. No problem. The toolkit includes several utilities that aid in resyncing the tables, including multi-node resync. By that I mean if there are 50 nodes with update anywhere, then all 50 can be resynced at the same time, and in just about the same amount of time that it would take to resync one source/target. N.B. by resync, I do not mean simply allowing normal replication to continue. I mean the drastic situation where existing replication queues must be destroyed and replication is restarted from scratch. > > Must check my passport just in case :-) > > Colin Bull > Videonetworks.com > > > > > ________________________________________________________________________ > This email has been scanned for all known viruses by the MessageLabs Email > Security System. > ________________________________________________________________________ > > sending to informix-list
I neglected to mention, that the faster utilities will require 9.x. I've got stuff that works on 7.31, but the really cool stuff requires 9.4. M.P. . "Madison Pruet" <mpruet@comcast.net> wrote in message news:rS6Sc.232858$a24.86555@attbi_s03... > See below.... > "Colin Bull" <Colin.Bull@videonetworks.com> wrote in message > news:cfa6vu$l74$1@news.xmission.com... > > > > Madison Pruet wrote > > > > > I will be giving a replication tutorial at the user > > > conference which will include various ways to verify > > > replication tables are in sync as well as providing a toolkit > > > of several utilities to aid in replication support. > > > > > Where is this ? > > Currently on my workstation. ;-) > > > And if us plebs cannot get there, are there likely to be any resources > > we can download ? > > I can't make the toolkit available until after user conference. I'm not > sure if I will be able to make the presentation available or not since it is > a tutoral. > > > > > By coincidence I have just received a project which states - > > REQ-6: Enterprise Replication will be able to recover synchronisation > > up to 48 hours after a database failure. > > No problem. Even if we destroy and restart the replication. > > > REQ-7: DBA's will be able to prove that the servers are synchronised. > > This may be a problem unless the tables are quiesent and the queues are > drained. Remember with continuous replication, stuff is constantly > changing. It's bad enough with a simple source/target. But consider the > situation with multiple nodes with update anywhere. However, the resync > tool works in a reporting mode which would give an idea of how > in-sync/out-of-sync the tables are (ignoring inflight data). > > > REQ-8: DBA's will be able to synchronise servers that have become > > unsynchronised. > > No problem. The toolkit includes several utilities that aid in resyncing > the tables, including multi-node resync. By that I mean if there are 50 > nodes with update anywhere, then all 50 can be resynced at the same time, > and in just about the same amount of time that it would take to resync one > source/target. > > N.B. by resync, I do not mean simply allowing normal replication to > continue. I mean the drastic situation where existing replication queues > must be destroyed and replication is restarted from scratch. > > > > > Must check my passport just in case :-) > > > > Colin Bull > > Videonetworks.com > > > > > > > > > > ________________________________________________________________________ > > This email has been scanned for all known viruses by the MessageLabs Email > > Security System. > > ________________________________________________________________________ > > > > sending to informix-list > >