When transactions purg from Replication servers

[suznCB]

Kindly advice me when we have two replication servers how or when transactions fare removed from the primary replication server ?

In our case even transactions applied in the destination database, the queues not purg its content

It almost will be full

Regards

[Mark_A_Parsons]

Conditions that can lead to stable device space not being truncated/released:

• long-running/open transaction in the primary db
• non-zero save intervals on routes or DSI connections; config name: save_interval; displayed in admin who,sqm output
• non-zero values for dsi_non_blocking_commit (implemented under the covers as a save interval)

Another, albeit rare, occasion would be orphaned rows in rs_segments (ie, rows in rs_segments with non-zero q_number values that do not have a matching row in either rs_databases or rs_sites); fixing this issue would require direct modifications of the RSSD tables and is not recommended unless instructed by tech support.

[suznCB]

Thanks for replying

actually, both of the two configs: save_interval and dsi_non_blocking_commit (from admin config result) is zero,

I should add something that the primary replication server RS1 manages a Warm standby replication and the related stable queues become empty after they applied to the standby database , but this replication server RS1 is also the source of a route to another replication server RS2 which manages MSA replication, and the stable queues at RS1 which don't purge are related to the route.

and in admin who,sqm the save interval for that queue is zero

at RS2 the stable queues are empty after transactions applied on subscription database.

now, all route queue's partitions are full, and the route doesn't move any data to the destination replication server,

we tried to test it by creating an error class at RS1.rssd and it didn't move to RS2.rssd2

[Mark_A_Parsons]

Sounds like a potential route issue; consider reviewing:

• admin who_is_down - verify route is up
• rs_helproute - run at both RSSDs and verify both show Active
• suspend route and then resume route - verify no issues/errors reported in the errorlog

[sladebe]

Here's a good writeup for how long log records (where typically each log record corresponds to a row that was modified) are kept in the primary database's transaction log:

Repserver Admin Guide 1 -> SAP Replication Server Technical Overview -> Transaction Handling with Replication Server -> Transaction Processing by the Replication Agent -> Coordinate Adaptive Server Log Truncation

help.sap.com/docs/SAP_REPLICATION_SERVER/9dc6170db0d24bb9bc901a44187b0636/fd461172bd1c1014a9eecd86e9...

The key point is, the secondary truncation point marks the log record that contains the begin transaction command for the oldest open transaction not yet fully applied by Replication Server.

Transaction log rows in front of the the secondary truncation point (later in time) can't be deleted. Once the oldest transaction commits to all the replicates, the secondary truncation point on the primary can be moved forward (to a more recent time), permitting all the trans log rows older than the secondary truncation point to be truncated.

I think the old transaction log entries don't actually get deleted until a periodic checkpoint operation runs in the primary ASE server. So there can be some lag between when the secondary truncation point moves and the transaction log rows actually get deleted. You can use "dump transaction <dbname> with truncate_only" to rush things (only truncates/deletes trans log rows no longer needed)

[suznCB]

thanks for replying

referring to my comment above, there is no issue with truncation point as data is removed from queues related to warm standby replication.

to be more specific, the problem is related to a route's queue, and then it become related to the route itself also.