When the database log is full, Adaptive Server cannot continue to process updates. To solve this problem you must truncate the log. However, you should not truncate transactions from the log before the RepAgent has passed them successfully to the Replication Server.
Adaptive Server uses truncation points to ensure that only transactions processed by the RepAgent are truncated. A secondary truncation point marks the place in the primary database log up to which the RepAgent has processed transactions. The RepAgent periodically updates the secondary truncation point to reflect transactions successfully passed to the Replication Server. Adaptive Server will not truncate the log past the secondary truncation point. For more information about database log truncation see Replication Server Administration Guide Volume 1.
There are, however, times when it is necessary to truncate the log beyond the secondary truncation point. For example, if the RepAgent cannot access the Replication Server and the log fills, you may want to truncate the log at the secondary truncation point rather than extending the log or preventing clients from updating the primary database. Truncating the log can cause inconsistencies between the primary and replicate databases. To resolve these inconsistencies, see “Log truncation problems”.
To truncate the database log at the secondary truncation point:
Verify that the secondary truncation point is set for the database. See “Verifying the state of the secondary truncation point”.
Turn off the secondary truncation point in the database. See “Turning off the secondary truncation point in a database”
Dump the database log. See the Adaptive Server Enterprise Reference Manual.
Set the secondary truncation point. See “Setting the secondary truncation point”
