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.
Insert triggers do not fire, as the HVAR 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 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 constraints in replication definitions. To avoid constraint errors, HVAR loads tables according to replication definitions.
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 noncompilable commands.
Replication Server reverts to log-order row-by-row continuous replication when it encounters:
Noncompilable commands – stored procedures, SQL statements, data definition language (DDL) transactions, system transactions, Replication Server internal markers, and rs_ticket.
Noncompilable transactions – a transaction that contains noncompilable commands.
Noncompilable tables – tables with HVAR disabled, with modified function strings, and with referential constraint relationships with tables that HVAR cannot compile.
If the replication definition does not include the replicate minimal columns clause, HVAR automatically changes a primary-key update to a delete followed by an insert. A primary-key update is either one of:
If the replication definition includes the replicate minimal columns clause, and if the group being compiled by HVAR contains an update command that modifies the primary-key columns, HVAR automatically identifies the table as noncompilable at runtime for the remaining portion of the group. The update operation applied to the table is noncompilable because HVAR cannot transform the update to a pair of operations consisting of a delete and an insert. Within the transaction group that HVAR is processing, HVAR can successfully compile into the net-change database all operations that HVAR processed before HVAR encountered the noncompilable primary-key update operation. However, within the transaction group, HVAR marks as noncompilable, the initial noncompilable primary-key update and all operations that follow it. The noncompilable state of the table is transient and lasts only for the duration of the same transaction group that HVAR is processing .
HVAR ignores parameters, such as dsi_partition_rule that can stop transaction grouping.
If errors occur during HVAR 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.
HVAR 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 commands in the replicate database: