The LTM retrieves transactions from the SQL Server log and sends them to the primary Replication Server. As long as there is space in the database log, the data server can continue to process updates. To prevent the log from filling up, you need to truncate it using the SQL Server dump transaction command.
SQL Server and the LTM cooperate to ensure that only transactions already processed by the LTM and passed to Replication Server are truncated.
The LTM maintains a secondary truncation point in the SQL Server log. The secondary truncation point is the log page that contains the begin transaction command for the oldest transaction not yet fully received by Replication Server. The LTM resets the truncation point when SQL Server returns an end-of-scan message. Two conditions cause SQL Server to return an end-of-scan message:
When the number of log records returned to the LTM has reached the number specified with the batch_sz configuration parameter
When the time interval specified by the scan_retry configuration parameter has expired
See “LTM configuration file” for information about setting these parameters in the LTM configuration file.
The batch_sz configuration parameter is the number of log records to request from the SQL Server in each batch before moving the LTM truncation point. The following events result in the LTM setting the truncation point, as shown in Figure B-3:
When the primary data server (PDS in the figure) reaches the batch_sz limit, it sends an end-of-scan message to the LTM.
When the LTM receives an end-of-scan message, it requests a new truncation point from the primary Replication Server (PRS in the figure).
The primary Replication Server returns the latest truncation point to the LTM and writes it to the rs_locater system table.
The LTM executes the dbcc settrunc command in the primary data server to set the LTM truncation point.
Figure B-3: Data server log truncation
When there are no log records, the data server log scan thread sleeps. New log activity awakens the log scan thread. The scan_retry configuration parameter limits the length of time to sleep. When the data server reaches the maximum scan retry time, and there is still no new log activity, it sends an end-of-scan message to the LTM. Processing occurs as in steps 2 through 4 in the preceding section.
When new records are added to the end of the log, the log scan thread wakes up and sends the new records. If batch_sz is not reached yet, it goes back to sleep. The time remaining in scan_retry is added to the next sleep interval, for a maximum time of scan_retry*2 seconds. When the log scan thread sleep interval has expired, the thread returns an end-of-scan message to the LTM, and a new log scan request is initiated.
If you restart an LTM while the log scan thread is sleeping,
the SQL Server rejects the LTM connection because the sleeping log
scan thread has not released the previous LTM connection. When the
thread wakes up, the SQL Server releases the previous connection
and can then accept a new LTM connection. If you create a script
to automatically restart an LTM, you should have the script sleep
for scan_retry * 2 seconds
before it restarts the LTM.