Showing results for 
Search instead for 
Did you mean: 

Sybase Replication Warm Standby : how long does a transaction remains in the LDS inbound queue

Former Member
0 Kudos

I am replicating data from sourcedb1 (syb ASE AIX 1254 2k pages) to targetdb1 (syb ASE linux 1254 2k pages) and recently we added targetdb2 (syb ASE Linux 157 8k pages)

targetdb1 only contains a subset of table and targetdb2 is a warm standby database.

When I execute larger transactions, there are executed fast on both target servers, no issues.

But the inbound queue of my LDS keeps this transaction long time and is using disk space. My monitoring script assumes that there is a large backlog. 150000 record inserts arrives in seconds on both target servers, but takes over 15 minutes to be removed to be removed from the inbound LDS queue.

How long does replication server stores this information in the inbound stable queue?  And is there a way to control this?

Best regards,

Toon Eysakkers

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos


Data in the inbound queue, regardless of whether it is warm standby or non-warm standby, stays in the queue until the oldest transaction in the queue is successfully applied at the target (generally) and the "save_interval" is met.

The more technical answer also includes ...and when the SQT & SQM threads are given time to do this cleanup work.

There is another question here.  When you added the warm standby, did you mark the tables with sp_reptostandby ?  If so, transactions for all tables (and optionally DDL and sp* procedures) are now getting into the inbound queue, whereas before, they may have not.  Therefore, legitimately, you might actually have more data in the stable device before RS applies the commit to the standby database, which makes the segments eligible for release of the stable device space.

The inbound queue is NOT in transaction order.  Therefore, a transaction that has a lot of other transaction work recorded during that transaction, will not release the stable device space until the first transaction has been committed (and this is relative).  You will be able to see this by doing an admin who, sqt as the display shows you where the oldest open transaction starts, from the SQT point of view.

If this only started happening after you added the warm standby, and you had always had the database marked with sp_reptostandby, make sure that after initialization of the warm standby, you have resumed the ACTIVE DSI as well as the standby DSI.

There is also the possibility that your RS is now so busy, that the SQT and SQM don't check often enough to see if there are segments that are no longer needed in the stable device.

I'm assuming that you have already taken a look at the RS log and see no warning or error messages.

I would suggest opening up an incident and let someone in support take a look at the issue.

Answers (0)