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 referential constraints in replication definitions. To avoid constraint errors, RTL loads tables according to replication definitions.
RTL for replication into Sybase IQ does not support customized function strings or any parallel DSI serialization methods, except for the default wait_for_commit method. RTL treats customized function strings as noncompilable commands.
RTL does not compile some types of commands called noncompilable commands and some types of tables called noncompilable tables. Replication Server reverts to log-order, row-by-row continuous replication when it encounters these commands, transactions, or tables:
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.
RTL automatically changes primary-key updates to a delete followed by an insert.
RTL ignores parameters such as dsi_partition_rule that can stop transaction grouping.
If errors occur during RTL processing, Replication Server retries RTL with progressively smaller transaction groups until it identifies the transaction that failed RTL compilation, then applies the transaction using continuous replication.
To realize the performance benefits of RTL, 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 this Sybase IQ command in the replicate database: