By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
438,227 Members | 1,026 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 438,227 IT Pros & Developers. It's quick & easy.

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

P: n/a
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
Share this Question
Share on Google+
1 Reply


P: n/a
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.