The following guidelines are recommended for improving EIM performance:
Verify that all indexes exist for the tables involved. Keep in mind, however, that for large loads you should drop most of the indexes from the target tables to increase the speed of the process, rebuilding those indexes afterward when the process is finished.
Limit tables and columns to be processed using ONLY BASE TABLES/COLUMNS configuration parameters to minimize EIM processing.
Consider disabling the Docking: Transaction Logging system preference during the EIM run. Switching off transaction logging improves performance; however, this benefit must be balanced with the need for mobile users to reextract afterward.
Altering batch sizes to find the optimal batch size for a given business component typically helps resolve performance issues. The batch size is dependent upon the quantity of data and which type of EIM process you are running.
NOTE: Although the limit of rows you can process is directly related to the capabilities of your database server, executing batches greater than 100,000 rows is strongly discouraged.
For EIM delete processes that use the DELETE EXACT parameter, use a batch size of 20,000 rows or less.
Try using batch ranges (BATCH = x-y). This allows you to run with smaller batch sizes and avoid the startup overhead on each batch. The maximum number of batches that you can run in an EIM process is 1,000.
Perform regular table maintenance on EIM tables. Frequent insert or delete operations on EIM tables can cause fragmentation. Consult your database administrator to detect and correct fragmentation in the EIM tables.
Delete batches from EIM tables on completion. Leaving old batches in the EIM table wastes space and could adversely affect performance.
Run independent EIM jobs in parallel.
Set the USING SYNONYMS parameter to FALSE in the .IFB file to indicate that account synonyms do not need to be checked.
If no other strategy appears to be successful, use the SQLPROFILE parameter to identify slow-running steps and queries. For more information, see Using the SQLPROFILE Parameter.