467,185 Members | 1,215 Online
Bytes | Developer Community
Ask Question

Home New Posts Topics Members FAQ

Post your question to a community of 467,185 developers. It's quick & easy.

DB2 Replication having slow apply (update) at the target server

Hello,everyone.

I'm setting a db2 replication environment using UDB version 8.1.5
running on Windows 2000 servers. The source server is on a Windows
server with the capture program running while the target server is on
another Windows server running the apply program. This replication set
up has a mix of bidirectional and unidirection data exchange. User
copy is used for the unidirectional data. I'm having the following
issue.
1. It seems like it takes about (3-5) for a transaction record to get
applied at the target server (LAN environment, actually they are the
same switch (apply/capture servers). I.E. the target server sends 1
record change every 3/5 seconds. Then it stops and waits for another
such interval to send the next one. That is unfeasible for our
replication purpose. If there were 1,000 being input per second, users
would need to have to 83 minutes for the data coming across to the
target server.

Is there a way to speed up or apply data change as it happens rather
than waiting for it to get applied at periodic interval.

What is log-based replication? Is that something that can help achieve
near real-time replication?

Thanks so much.

Trent
Nov 12 '05 #1
  • viewed: 2620
Share:
1 Reply
Trent,

There are two common techniques used by replication for capture of the
changes.

One is trigger based (where update/insert/delete) triggers are used to
generate the changes that are put into some form of a staging table. The
staging table is then periodically polled to pull the delta into the target
table.

The other is a log based technique in which there is a snoopy process which
will build the differences into and then apply them in some way.

In the current (pre 8.2) releases, the log based capture is used on DB2
sources and the trigger based capture is used for non-db2 sources. However,
even the log based capture is placing the changes into a staging table
(CD/UOW) and then the apply is polling that staging table to determine what
to apply.

Not to worry...

We are in the process of announcing a new version of replication which will
address the issues that you are wanting addressed. This will be discussed
next week in the DM Technical Conference in some detail. So I don't want to
go into too many details here.

However, the IDS folks that might be reading this, I'm talking about a
performance difference that roughly is equivalent to the ER performance
differences pre/post 9.30.

"Trent" <pi****@yahoo.com> wrote in message
news:7a**************************@posting.google.c om...
Hello,everyone.

I'm setting a db2 replication environment using UDB version 8.1.5
running on Windows 2000 servers. The source server is on a Windows
server with the capture program running while the target server is on
another Windows server running the apply program. This replication set
up has a mix of bidirectional and unidirection data exchange. User
copy is used for the unidirectional data. I'm having the following
issue.
1. It seems like it takes about (3-5) for a transaction record to get
applied at the target server (LAN environment, actually they are the
same switch (apply/capture servers). I.E. the target server sends 1
record change every 3/5 seconds. Then it stops and waits for another
such interval to send the next one. That is unfeasible for our
replication purpose. If there were 1,000 being input per second, users
would need to have to 83 minutes for the data coming across to the
target server.

Is there a way to speed up or apply data change as it happens rather
than waiting for it to get applied at periodic interval.

What is log-based replication? Is that something that can help achieve
near real-time replication?

Thanks so much.

Trent

Nov 12 '05 #2

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

2 posts views Thread by Keith Elkin | last post: by
2 posts views Thread by Stephen Brown | last post: by
1 post views Thread by Joseph Chase | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.