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)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.