Splitting the replication load into multiple process groups for optimal performance

You will often notice that when replication is implemented in very busy systems, a single Extract/Replicat process is not sufficient to keep up with the rate of change. In most cases, you will find that it is the Replicat process that is causing the bottleneck. This is due to the fact that the Replicat or Apply process works in a serial fashion. All the changes read from the trail files are re-constructed into the SQL statements. These statements are then run in the target database one-by-one. Unless you have deliberately created a configuration with a set delay between the systems, it is usually desired to have the least lag between the source and target environments. The performance of a replication technology is often judged by the rate at which it is capable of keeping the changes replicated from the source environment to the target environment, even when the systems are under peak loads. One of the easiest...