Enhanced Retry Mechanism

The enhanced retry mechanism improves replication performance by reducing the number of times Replication Server retries compilation and bulk apply.

RTL attempts to group as many compilable transactions as possible together, compile the transactions in the group into a net change, and then use the bulk interface in the replicate database to apply the net changes to the replicate database. RTL invokes the retry mechanism when a replicate transaction resulting from RTL processing fails. If transactions in a group fail, RTL splits the group into two smaller groups of equal size, and retry the compilation and bulk application on each group. The retry mechanism identifies the failed transaction, allows Replication Server to execute error action mapping, and applies all transactions preceding the failed transaction in case DSI shuts down.

The net-change database in RTL acts as an in-memory repository for storing the net row changes of a transaction, that is, the compiled transaction. The content of the net-change database is an aggregation of commands from different primary transactions that RTL is not applying in log order. Therefore, there is no means to identify a failed transaction without a retry mechanism. The retry mechanism splits a group and retries compilation and bulk application continuously as long as a transaction in the group fails. This continuous retry process can degrade performance.

The enhanced retry mechanism splits the group into three groups of equal size when RTL encounters a group containing transactions that fail, enabling the mechanism to more efficiently identify the group containing the failed transaction.

In addition, you can use the dsi_compile_retry_threshold parameter to specify a threshold value for the number of commands in a group. If the number of commands in a group containing failed transactions is smaller than the value of dsi_compile_retry_threshold, Replication Server does not retry processing the group in RTL mode, and saves processing time, thus improving performance. Instead, Replication Server switches to continuous replication mode for the group. Continuous replication mode sends each logged change to the replicate database according to the primary database log order.