Best Practices

This document describes best practices for using the Event Replicator Target Adapter. It covers the following topics:


Improving Overall Performance

To improve the performance of your Event Replicator Target Adapter installation consider the following suggestions.

  1. Set the compression for data that comes from any webMethods EntireX sources to zero (0). This turns off compression entirely. Decompressing the compressed data, especially large quantities of data, will slow replication processing down. For more information about setting this compression value, read Defining a New webMethods EntireX Source Definition.

  2. Try to maintain a one-to-one relationship between the number of Event Replicator Target Adapter engine threads and the number of active source definitions.

    For more information about maintaining the configuration engine definition, read Maintaining the Event Replicator Target Adapter Engine Configuration.

  3. Install the Event Replicator Target Adapter on a separate server from the relational database you will be updating.

  4. Install the Event Replicator Target Adapter on a moderately powerful machine. The minimum requirements for this machine are described in Space Requirements and Memory Requirements.

  5. Install the Event Replicator Server, the Event Replicator Target Adapter, and the target relational database on the same network segment.

  6. If your target database is running in a cloud environment (e.g. AWS), you will get better performance if you also run your Event Replicator Target Adapter in the same cloud service.

In addition, read the other sections in this Best Practices documentation for information on improving the performance of initial-state processing.

Processing Initial-State Data

Performance Tips

If possible, use one of the Loaders provided with the Event Replicator Target Adapter for initial-state processing. At this time, support is provided for the Oracle SQL *Loader, the Microsoft SQL Server Bulk Copy (bcp) Utility, Teradata MultiLoad Utility, the DB2 CONNECT IMPORT Command and the PostgreSQL psql Utility.

In addition, if you are using a webMethods EntireX source, the initial-state process will run faster if the persistent store is turned off during the run. For more information on doing this, refer to your webMethods EntireX documentation.

When Initial-State Processing Fails While Using a Loader

Start of instruction setIf an initial-state process fails between the Event Replicator Server and the Event Replicator Target Adapter while using a Loader, complete the following steps:

  1. Determine why the initial-state process failed and correct it. The log file or console messages will show errors after the initial-state process has started. No errors and the "Initial-State completed" message indicates that all is well.

  2. Depending on the reason the initial-state process failed, you may need to drain the queue between the Event Replicator Server and the Event Replicator Target Adapter. To do this, you can use the etbivp or mqsivp tools, or any other methods for draining queues provided by webMethods EntireX Broker or MQ Series.

  3. Depending on the reason the initial-state process failed, you may need to drop the relational database (RDBMS) tables using the appropriate RDBMS tool. Only the tables created or used by the particular initial-state process will need to be dropped.

  4. Restart the initial-state process.