RTL applies only the net-row changes of a transaction while maintaining the original commit order, and guarantees transactional consistency even as it skips intermediate row changes.
Insert triggers do not fire, as the RTL process performs a bulk load of net new rows directly into the table. Update and delete triggers continue to fire when Replication Server applies the net results of compilation to the replicate database. However, row modifications that Replication Server compiles, and that are no longer in the net results, are invisible to the triggers. Triggers can detect only the final row images.
Suppose you use Replication Server to audit user updates using a last_update_user column in a table schema with a trigger logic that associates a user to any column in the table modified by the user. If userA modifies colA and colC in the table and then userB modifies colB and colD, when the trigger fires, the trigger logic can detect only the last user who modified the table, and therefore the trigger logic associates userB as the user that modified all four columns. If you define triggers that contain similar logic where every individual row modification must be detected, you may have to disable RTL compilation for that table.
RTL does not apply row changes in the same order in which the changes are logged. To apply changes to a replicated table in log order, disable RTL compilation for that table.
If there are referential constraints on replicate tables, you must specify the constraints in replication definitions. To avoid constraint errors, RTL loads tables according to replication definitions.
RTL does not support any parallel DSI serialization methods, except for the default wait_for_commit method.
Replication Server reverts to log-order, row-by-row continuous replication when it encounters:
Noncompilable commands – stored procedures, SQL statements, system transactions, and Replication Server internal markers.
Noncompilable transactions – a transaction that contains noncompilable commands.
Noncompilable tables – tables with RTL disabled, with customized function strings, and with referential constraint relationships with tables that RTL cannot compile.
For tables without primary keys where there are no table replication definitions, Replication Server converts updates to the table to primary-key updates as Replication Server treats all columns, except text or image columns, as primary keys.
RTL ignores parameters such as dsi_partition_rule that can stop transaction grouping.
If errors occur during RTL processing, Replication Server retries compilation with progressively smaller transaction groups until it identifies the transaction that failed compilation, then applies the transaction using continuous replication.
To realize performance benefits, keep the primary and replicate databases synchronized to avoid the overhead of additional processing by Replication Server when errors occur. You can set dsi_command_convert to i2di,u2di to synchronize the data although this also incurs a processing overhead. If the databases are synchronized, reset dsi_command_convert to none.
RTL performs row-count validation to ensure replication integrity. The row-count validation is based on compilation. The expected row count is the number of rows remaining after compilation.
When there are columns with identity datatype in a replication definition, Replication Server executes these Sybase IQ commands in the replicate database: