Transaction processing impact
Many variables affect the impact that replicating data has on your transaction processing.
- Replication volume
- To determine replication volume, you must estimate how many data rows change per day. For example, an application issues a simple INSERT statement that inserts 100 rows. If this table is replicated, Enterprise Replication must propagate and analyze these 100 rows before applying them to the targets.
- Distributed transactions
- A distributed transaction is a transaction that commits
data in a single transaction over two or more database servers.
Outside of the replication environment, HCL OneDB™ uses a two-phase commit protocol to ensure that the transaction is either committed completely across all servers involved or is not committed on any server. For more information about the two-phase commit protocol, see the HCL OneDB Administrator's Guide.
In a replication environment, when a distributed transaction is committed across the source servers, each part of the transaction that applies to the local server is written to the local logical logs. When Enterprise Replication retrieves the transaction from the logical logs and forms its transaction data, it is unable to identify the separate transaction data as the original single transaction.
This situation might result in Enterprise Replication applying one transaction successfully while aborting another. Another result might be a time lapse between the application of one transaction and another (depending on how much transaction data is in each server's send queue and the state of the server).
- Large transactions
- While Enterprise Replication is able to handle large transactions,
it is optimized for small transactions. For best performance, avoid
replicating large transactions.
Large transactions are handled with a grouper paging file in temporary smart large objects. Enterprise Replication can process transactions up to 4 TB in size. For more information, see Setting Up the Grouper Paging File. You can view Enterprise Replication grouper paging statistics with the onstat -g grp pager command (see onstat -g grp: Print grouper statistics).
Instead of using Enterprise Replication to perform a batch job, use BEGIN WORK WITHOUT REPLICATION to run the batch job locally on each database server. For more information, see Blocking Replication.