While Replication Server is extensible to meet the needs of replicate data servers (customizable function strings and error handling, custom datatype definitions, and translations between datatypes), Replication Server support of primary data servers is limited.
The Replication Server interface for primary data servers is its proprietary Log Transfer Language (LTL). Transactions from a primary data server must be translated to LTL to be delivered to a primary Replication Server. Therefore, primary data servers are limited to those for which Sybase provides a Replication Agent to perform the translation to LTL for primary database operations.
Replication Server interfaces on both the primary and replicate sides are supported by the underlying Open Client/Open Server interface running on TDS.
The primary Replication Server maintains a “locator” value (LTM locator), which is used to identify the last point in a transaction log from which all data has been successfully received by the primary Replication Server. The Replication Agent periodically requests this value from the Replication Server connection to identify a position in the transaction log, which can then be used to identify where older data can be released or removed from the log.
There is a performance trade-off in determining how often to request an LTM locator update. Frequent queries of the LTM locator value from a Replication Server can slow down replication (the Replication Agent must stop sending LTL commands long enough to request and receive the LTM locator value) while it provides more frequent opportunities to release data from the log. When restarting, the Replication Agent must re-send all data in the log that exists since the last LTM locator value was received from Replication Server.
Generally, if replication throughput performance is a priority, you should acquire enough log resource to allow less frequent log truncation and less frequent retrieval of the LTM locator value. If log resources are scarce, more frequent retrieval of the LTM locator value and more frequent truncation may be necessary.
For more information on using the LTM locator, refer to the appropriate Replication Agent Administration Guide.
The number of bytes of information sent to Replication Server has a direct impact on the performance of the replication system; more data and commands received by Replication Server require more work and time to process. In addition, more data also requires more resources from the network environment. There are several configuration options available for the Replication Agent that you can use to minimize this impact. Among these are:
Using the RSSD. By reading replication definitions from the RSSD, the Replication Agent can send the column data in the same column order as specified by the replication definition. This allows Replication Server to bypass sorting the column information before processing. Furthermore, column names are not sent with the data, which reduces the number of bytes of information required.
Sending minimal columns. When an update operation occurs on a table, only a portion of the columns may have been altered. By sending the before and after images of only those columns that changed, the Replication Agent sends less information.
Batch mode. A Replication Agent must “wrap” transactions in a limited amount of administrative LTL for the Replication Server. In batch mode, the Replication Agent can wrap multiple commands in the same set of administrative commands, which reduces the overall LTL generated and processed by the network and the Replication Server.
In addition to batch mode, most Replication Agents have a “batch timeout” parameter, which allows a partial batch to be sent to the Replication Server after the Replication Agent waits a specified period of time and no additional transactions are received to fill the batch.
Replication Agent batch mode should not be used if any
Replication Server user-defined datatype (UDD) translations are
used, either
column-level or class-level.
Origin time. Each transaction sent to Replication Server has an origin queue ID. The origin queue ID may include the time that the transaction was committed at the primary database. If the origin time is not sent by the Replication Agent, its processing effort is reduced somewhat, but the quantity of LTL sent to the Replication Server is the same.
The origin time must be sent if you want to use Replication
Server Manager to calculate replication latency.
For a complete description of the Replication Agent configuration parameters that affect LTL output, refer to the appropriate Replication Agent Administration Guide.
