DB Start Port

TomBascom

Curmudgeon
Interesting.

I too have observed that replication data transfers are "chunky". When there isn't much going on those last few transactions can hang around for a long time waiting to be sent to the target. It's one of those things in the back of my mind that I'd like to ask about but something else usually comes up...
 

Rob Fitzpatrick

ProgressTalk.com Sponsor
My first test, with two targets, looked something like this:

Code:
// source
find first customer.
name = 'update1'.

And then later:

Code:
find first customer.
find next customer.
name = 'update2'.

Code:
// target
find first customer.
display name.
pause.
find next customer.
display name.

For a considerable amount of time (many minutes, perhaps longer) after the transaction committed on the source I was still seeing "Lift Line Skiing" on the target, rather than 'update1'. I was wondering whether, given the small size of the update, it was sitting entirely in the target's BI output buffer and the changes were not yet written to the buffer pool. Note I was running simple small sports DBs with all defaults and no page writers. But I would expect, even in that case, that the RL_TEND note would cause the rpagent to flush the BI buffer to make the transaction durable. Various target resyncs/restarts later, the updates eventually got there. I was just surprised at how long they remained "in flight".
 

Cringer

ProgressTalk.com Moderator
Staff member
Is that your actual code? Or edited for succinctness? If it's the real code, I wonder if it has to do with the share locks?
With a single target on 10.2B (the most recent Replication environments I worked with) I've never seen any noticeable delays in data transfer.
 
Top