EIM Performance tuning guide
Written By: Rohit|
July 18, 2012|
1. Separate INSERT and UPDATE: In a lot of conditions, we need to import some data in which some rows need to be updated and rest to be inserted. When you use same IFB file for both, EIM can distinguish by itself which rows to update and which to delete, but it costs some additional overhead. So if you are processing large data, then it is better to separate INSERT and UPDATE in different IFB files and run them separately which can enhance the performance of the process.
2. Optimizing the IFB file:
ONLY BASE TABLES / IGNORE BASE TABLES: A single interface table is usually mapped to several base tables. By default EIM processes each and every base table associated to that interface table which takes extra resources. So it’s better to use ONLY BASE TABLES / IGNORE BASE TABLES clause and specify the only base table you want to modify.
ONLY BASE COLUMNS / IGNORE BASE COLUMNS: It works just like the above parameter. By default EIM processes each and every base table column, so it’s better to specify base table columns you want to modify in many situations. For e.g., if you are updating a single column value, it’s better to specify that column name (along with user key of table) which can greatly enhance the performance of the process.
3. Optimizing the batch size: You can greatly enhance the performance once you find out the optimal number of rows in batches to be run on a particular table. Set Trace Flag = 1 while running the IFB because then you can see how long each step takes and how many rows were processed by the EIM process. Generally, it varies from 1000 to 15000 rows.
4. Disable Docking: Set TRANSACTION LOGGING parameter to be false in your IFB file. Logging transactions can be dropped for initial loads. But if you have mobile clients, then this parameter must be set to TRUE in order to route transactions to the mobile clients. However, during initial data loads, you can set this parameter to FALSE to reduce transaction activity to the Siebel docking tables.
5. Drop indexes for initial runs: Initial data runs can take a large amount of time which can be significantly reduce by dropping some indexes. EIM doesn’t use most of the indexes, so you can sort out the indexes which are not used by EIM process and drop them. For example, while importing your accounts (in S_ORG_EXT), you can drop all indexes except primary and unique ones.
6. Run parallel EIM tasks: This tuning technique should be used carefully and only in situations where all above techniques couldn’t increase the performance of EIM and there’s a huge amount of data to be processed.
7. Table Maintenance: 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.
8. Clean Interface tables: Delete batches from EIM tables on completion. Leaving old batches in the EIM table wastes space and could adversely affect performance.