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:
• 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.
• RTL does not support customized function strings and treats customized function strings as noncompilable commands.
• 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, and rs_ticket.
• 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. • Runtime noncompilable tables - this occurs when a transaction contains minimally
packed updates, for example when using the replicate minimal columns clause in the replication definition for that table, and when the transaction modifies the primary key value.
• Replication Server does not support RTL for Sybase IQ views. Set dsi_compile_enable
off for the view to mark the view noncompilable.
• 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:
• set temporary option identity_insert= 'table_name' before identity column inserts and updates.
• set temporary option identity insert= “” after identity column inserts and updates. • When converting from microseconds in the primary data server to milliseconds on the
Sybase IQ replicate data server, Replication Server pads the last three digits of the microsecond with zeros in the time, datetime, and smalldatime columns in the TIMESTAMP datatype causing replication to fail. See Sybase IQ Reference: Building Blocks, Tables, and Procedures > Compatibility with Other Sybase Databases > Data Types > Date, Time, Datetime, and Timestamp Data Types > Compatibility of Datetime and Time Values from ASE .
When you manually materialize a replicate table using the Sybase IQ INSERT ... LOCATION statement, Sybase IQ fills in the last three digits of the microsecond in TIMESTAMP columns to use the values 000, 333, or 666. For example:
insert test_datetime_iq4 location 'zeus.primaryDB4' { select c1,c2,c3,c4,c5 from test_datetime_iq4 } where c2 is datetime and c4 is time.
To ensure that RTL continues to replicate to Sybase IQ after you use INSERT ... LOCATION
to materialize a table, manually materialize the Sybase IQ tables by enforcing explicit conversion of the TIMESTAMP datatype:
insert test_datetime_iq4 location 'zeus.primaryDB4' { select c1,convert(varchar,c2,109),
c3,convert(varchar,c4,20),c5 from test_datetime_iq4 }
• By default, Oracle performs minimal logging. Therefore, if you are using database replication definitions, either create table replication definitions or enable full logging to ensure the update command works correctly. If you choose to create table replication definitions, you can create the definitions in Replication Agent or Replication Server: • Replication Agent for Oracle – to automatically create replication definitions at
Replication Server when one or more tables are marked for replication, either set
pdb_auto_create_repdefs to true before you mark the table for replication or execute
rs_create_repdef after you mark the table . See the Replication Agent Reference Manual in Replication Server Options.
• Replication Server – execute create replication definition with the send standby
clause to create the replication definition directly in Replication Server. See the Replication Server Reference Manual.
See also
• Tables with Referential Constraints on page 135 • RTL Performance Tuning on page 125