You can configure a database connection so that transactions are applied to a replicate data server using parallel DSI threads rather than a single DSI thread. Applying transactions in parallel increases the speed of replication, yet maintains the serial commit order of the transactions that occurred at the primary site.
When parallel DSI threads are active, Replication Server normally starts processing a transaction before the preceding transaction has committed and after the DSI has seen the commit record for the next transaction. The commit is delayed until it is determined that all preceding transactions have committed. Replication Server can maintain the order in which transactions are committed and detect conflicting updates in transactions that are executing in parallel simultaneously, using either of these methods:
Internally, using Replication Server internal tables and function strings, or
Externally, using the rs_threads system table in the replicate database.
Replication Server can achieve additional parallelism in the way it processes transactions containing a large number of operations with parallel DSI threads. Large transactions begin processing before the DSI has seen the commit record. While this means a large transaction can be processed sooner, it also means that in a warm standby situation, Replication Server might start processing a transaction that is ultimately rolled back. However, with subscription replication, the rollback transaction would be caught by the DIST thread.
Replication Server provides other options for maximizing parallelism and minimizing contentions between transactions. For example:
Transaction serialization methods allow you to choose the degree of parallelism your system can handle without inducing conflicts.
Transaction partitioning rules provide additional tuning to affect how transactions are grouped and distributed to avoid contention in the replicate database.
