Unable to Continue Replication in a Faster Mode

To determine the cause of replication failure, suspend replication before Replication Server retries to apply transactions, or reverts to the continuous log-order language replication mode.

Replication Server may fail to apply transactions to the replicate database if Replication Server encounters limitations, processing errors, or thresholds for faster replication modes (high-volume adaptive replication (HVAR), real-time loading (RTL), dynamic SQL, parallel DSI, or DSI bulk copy-in). Replication Server retries to apply transactions and automatically switches to the continuous log-order language replication mode if Replication Server cannot continue to use the faster modes, and even after trying to reapply transactions in smaller compilable groups in HVAR and RTL modes.

When Replication Server fails to apply transctions in a replication mode other than the continuous log-order language mode, replication performance may be affected. You can use commands such as admin stats and admin stats, {tps | cps | bps} to check replication performance.

To identify when Replication Server is failing to replicate using any of the replication modes, and to investigate replication performance problems, configure the dsi_retry parameter to suspend the DSI thread once the failure occurs and before Replication Server switches to the continuous log-order language mode from one of the other modes. When dsi_retry suspends the DSI thread, Replication Server cannot apply transactions to the replicate database, and you can analyze the Replication Server log file or dump queue for information about the failed transactions to determine the reasons for the failure to apply transactions. For example, you may see in the repserver.log file an entry such as:
I. 2012/09/11 19:53:03. A grouped transaction of 5 individual transactions has failed in database 'repl4_28382.rdb' with 'HVAR/RTL'.
DSI is now suspended because dsi_retry value '2'.
E. 2012/09/11 19:53:03. ERROR #1028 DSI EXEC(104(1) repl4_28382.rdb) - dsiqmint.c(4471)
        Message from server: Message: 546, State 1, Severity 16 -- 'Foreign key constraint violation occurred, dbname =  'rdb', table name = 'tb15_1', constraint name = 'tb15_1_col_1152004104'.
This is an error message that Replication Server generates when HVAR is applying update statements to a table with a referential constraint. Unless you use replication definitions to specify tables with referential constraints, the HVAR and RTL process to apply updates cannot avoid referential integrity constraints failures, and HVAR and RTL continue to try to apply the transactions to the replicate database using progressively smaller transaction groups. Eventually, Replication Server switches to the slower continuous log-order language replication mode when attempts with HVAR and RTL fail, resulting in an adverse impact on replication performance. To fix the HVAR and RTL processing problem, you can either use replication definitions, disable the constraint checks on the tables that cause failure and produce the error messages, or you can use the set dsi_command_convert to ‘u2di’ clause with alter connection to convert update to delete followed by insert.

When you resume the DSI thread, Replication Server continues to use the original replication mode.

You can use dsi_retry with: For example, to suspend replication to the iqdb Sybase IQ replicate database in the IQSRVR data server when RTL fails to apply compilable transactions to iqdb, before you reenable RTL, enter:
alter connection to IQSRVR.iqdb
set dsi_retry to 1
go
The dsi_retry configuration at the connection level overrides the server-level configuration. You can use dsi_retry with any replicate database that supports HVAR, RTL, dynamic SQL, parallel DSI, or bulk copy-in.
See:
Parent topic: Performance Problems