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.This has several implications:
If you define triggers at the replicate database, they do not fire when the RTL compiler removes rows. Triggers require every logged SQL statement to be applied. If you require table triggers to fire all the time, 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. See “Tables with referential constraints”.
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 non-compilable 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, data definition language (DDL) transactions, 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, with minimal column replication enabled, and with referential constraint relationships with tables that RTL cannot compile.
When you enable RTL by setting dsi_compile_enable to ‘on’ and the replication definition for the table has the replicate minimal columns clause or has the replicate_if_changed clause, Replication Server treats the table as noncompilable.
RTL automatically changes primary-key updates to a delete followed by an insert.
For tables without primary keys or where there are no table replication definitions, Replication Server converts updates as primary key updates to the table, as Replication Server treats all columns, except text or image columns, as primary keys.
RTL replication attempts to group together as many transactions as possible to maximize throughput. 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, and 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. See “Configuring RTL”.
RTL performs row-count verification to ensure integrity in replication. 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:
set temporary option identity_insert = ‘table_name’ before identity column inserts and updates
set temporary option identity insert = “” after identity column inserts and updates
