For most primary databases, many users and applications can create transactions simultaneously. Funneling all of these transactions to the replicate through a single connection can create a serious bottleneck. This bottleneck can cause periods of unwanted latency between the primary and the replicate.
The benefit of enabling parallel DSI within Replication Server is to reduce this potential bottleneck by processing multiple transactions across multiple replicate databases at the same time.
The risk in enabling parallel DSI is the introduction of contention between the multiple replicate connections and their transactions. The simultaneous application of transactions against the replicate may introduce competition between the transactions for replicate resources, creating a different kind of bottleneck.
As a result, using parallel DSI threads successfully requires an in-depth knowledge of your replication environment and iterative testing to determine which of the parallel DSI tuning parameters are most beneficial. The objective is to provide high throughput while controlling the amount of contention introduced at the replicate.
For example, consider a body of work that includes 1000 transactions that must be replicated. It will take some time to send all 1000 transactions across a single replicate connection. However, attempting to configure and use 1000 connections, one for each transaction, will likely result in contentions and strained server resources. A successful configuration requires a balance between the two scenarios; it depends on both the transaction profile and the impact of issuing those transactions against the replicate using parallel DSI.
In a second example, two serial transactions issued at the primary each perform a single update operation to the same table row. If these two transactions are attempted in parallel at the replicate by two connections, the first transaction to access the table row is granted exclusive access. The second transaction must wait until the first transaction has either committed or rolled back and thus released the row. Although both transactions are ultimately applied, there is no benefit from the parallel DSI configuration. The transactions are processed serially in the same way they would have been processed without parallel DSI. The contention has nullified any benefit from using parallel DSI.
