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.