Many variables affect what impact replicating data has on your transaction processing. This section discusses some of these variables:
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.
A distributed transaction is a transaction that commits data in a single transaction over two or more database servers.
Outside of the replication environment, Dynamic Server 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 IBM Informix Dynamic Server 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 could 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).
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 located 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).
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.
After you define Enterprise Replication on a table by including that table as a participant in a replicate you cannot exclusively lock a database that is involved in replication (or perform operations that require an exclusive lock). However, you can exclusively lock a table in a database.
To use the forbidden and limited SQL statements described in this section against a table defined for replication, you must first stop (not suspend) the replicate that contains the table, before running the SQL statement. After modifying the table at all required nodes, restart the replicate. For more information, see Managing Replicates.
You cannot use the following SQL statements against a table that is included in a replicate:
The following additional limitations also apply to tables defined for replication:
For more information about CRCOLS, see Preparing Tables for Conflict Resolution.
For example, do not alter the column to add default values or other integrity constraints.
For example, if a primary key is defined on col1, do not change the primary key to col2.
Enterprise Replication permits the following SQL statements with no limitations: