Enterprise Replication queues
The thread starts with a question about Enterprise Replication send/receive queues: how many there are and whether one server on a slow network link slows replication to the others. Madison Pruet answers that each server has a single send queue but multiple send threads working at different points in it, so a slow link to one target does not hold up delivery to the others. A second poster then piggybacks a different issue — queued data for two tables not clearing after days, with an open IBM support call. The only guidance given was that older server versions reported queued-bytes figures incorrectly and that the transaction count is what matters; no resolution to that case is recorded in the thread.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
How many send - receive queues are there in ER. What is the impact of having one server on a slow network link. For e.g., if servers A & B are connected in ER through a good link, but C is on a slow link. I would expect replication from A/B to C would be slow. But I hope there is no impact on replication between A & B.
Each server has one send queue, but multiple send threads and each send thread can be at a different point in the send queue. There would be no impact on the delivery to one server if another server has a slow network. M.P. From: "GURPREET SACHDEVA" <gusachde@cisco.com> To: ids@iiug.org Date: 02/09/2012 02:15 AM Subject: Enterprise Replication queues [26207] Sent by: ids-bounces@iiug.org How many send - receive queues are there in ER. What is the impact of having one server on a slow network link. For e.g., if servers A & B are connected in ER through a good link, but C is on a slow link. I would expect replication from A/B to C would be slow. But I hope there is no impact on replication between A & B. ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
As I stated in my post the queues are not clearing - not a performance issue- after 26 hours data still in q for the 2 tables. I would have thought that the source table would be diffrent than destination table. My thinking that the change is made there then replicated to the destination. Is this not how it works?
FOr what its worth I have logged a support call with IBM about this problem
I have logged a support call with IBM about this q but still no solution after two weeks. Surely someone must have struck this problme - how can data q for a week and still not get updated on target server ? any experts out there
There were some problems with the queued bytes on older versions of the server. The only thing that you should worry about is the number of transactions queued. From: "KARL OLIVER" <karl.oliver@maf.govt.nz> To: ids@iiug.org Date: 02/29/2012 06:38 PM Subject: Re: Enterprise Replication queues [26410] Sent by: ids-bounces@iiug.org I have logged a support call with IBM about this q but still no solution after two weeks. Surely someone must have struck this problme - how can data q for a week and still not get updated on target server ? any experts out there ******************************************************************************* Forum Note: Use "Reply" to post a response in the discussion forum.
I have logged a support call with IBM about this q but still no solution after two weeks. Surely someone must have struck this problme - how can data q for a week and still not get updated on target server ? any experts out there