HVAR 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 change in replication behaviour due to HVAR has several impacts:
If you define triggers at the replicate database, they do not fire when the HVAR compiler removes rows. Triggers require every logged SQL statement to be applied. If you require table triggers to fire all the time, disable HVAR compilation for that table.
HVAR does not apply row changes in the same order in which the row changes are logged. To apply changes to a replicated table in log order, disable HVAR 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, HVAR loads tables according to replication definitions. See “Tables with referential constraints”.
Replication Server does not support customized function-strings or any parallel DSI serialization methods, except for the default wait_for_commit method, when you enable HVAR. HVAR treats customized function strings as non-compilable commands.
HVAR does not compile some types of transactions called noncompilable transactions and some types of tables called noncompilable tables. Replication Server reverts to log-order row-by-row continuous replication when it encounters these operations:
Noncompilable transactions – 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 HVAR disabled, with modified function strings, with minimal column replication enabled, and with referential constraint relationships with tables that HVAR cannot compile.
When you enable 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 non-compilable.
HVAR automatically changes primary-key updates to a delete followed by an insert.
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.
HVAR replication attempts to group together as many transactions as possible to maximize throughput. HVAR ignores parameters, such as dsi_partition_rule that can stop transaction grouping.
If errors occur during HVAR processing, Replication Server retries HVAR with progressivley smaller transaction groups until it identifies the transaction that failed HVAR compilation, and then applies the transaction using continuous replication.
To realize performance benefits of HVAR, 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 HVAR”.
HVAR performs row count verification to ensure integrity in replication.
When there are columns with identity datatype in a replication definition, Replication Server executes on Adaptive Server, the command:
set identity_insert_table_name on before identity column inserts and set identity_insert_table_name off after identity column inserts
set identity_update_table_name on before identity column updates and set identity_update_table_name off after identity column updates
HVAR is especially useful for creating online transaction processing (OLTP) archiving and reporting systems where the replicate databases have the same schemas as the primary databases.
