Coordinating Adaptive Server log truncation

As long as there is space in the Adaptive Server database transaction log, Adaptive Server continues to process transactions. To prevent the log from filling up, it must be emptied (“truncated”) periodically. You can use the Adaptive Server dump transaction command or set the Adaptive Server trunc log on chkpt option to “on” so that the log truncates automatically.

Each primary database maintains primary and secondary truncation points in its database log. The primary truncation point marks the last log record Adaptive Server has finished processing. The secondary truncation point normally marks the log record that contains the begin transaction command for the oldest open transaction not yet fully applied by Replication Server. Replication Server stores a copy of the latest secondary truncation point in the rs_locater table of the RSSD.

RepAgent requests a new secondary truncation point when it has scanned a predetermined number (batch) of records or has reached the end of the log and there is no new activity. Replication Server acknowledges receipt of a batch of transaction records by giving RepAgent the information that allows it to move the secondary transaction point.

Adaptive Server makes sure that only transactions already processed and passed to the Replication Server are deleted by never truncating the log past the secondary truncation point.

RepAgent updates the secondary truncation point as shown in Figure 2-4.

Figure 2-4: Adaptive Server log truncation

Figure 2-4 shows how Rep Agent updates the secondary truncation point. It requests a new secondary truncation point from the primary Replication Server. The primary Replication Server returns the latest secondary truncation point to the Rep Agent and also writes it into the R S underscore locater system table. The secondary truncation point is updated in the transaction log. At the next checkpoint or dump transaction command, the log is truncated up to the new secondary truncation point.

RepAgent requests a new secondary truncation point from the primary Replication Server.
The primary Replication Server returns the latest secondary truncation point to the RepAgent and also writes it into the rs_locater system table.
RepAgent updates the secondary truncation point in the transaction log.
At the next checkpoint or dump transaction command, the log is truncated up to the new secondary truncation point.

Schema information describes the structure of the database. Each time you change the schema of a database object—such as dropping a table, creating a clustered index, or renaming a column—Adaptive Server records current schema information for that object. Thus, when RepAgent scans the transaction log, it can always retrieve the correct schema for a table or procedure—even if the original database object has been changed or no longer exists. You do not need to drain the transaction log before executing schema changes at the primary site.