Steps to tune EIM batches to improve performance

Here are some options that can be tried to improve Enterprise Integration Manager
(EIM) performance:

Best Practices from Siebel side -

1. Make sure Oracle database configuration are set as per recommended by

oracle in order to improve EIM throughput
2. If there are any WF policies on any of the entity that you are loading it is ideal
if you can drop the triggers with the help of the DBA and complete your load.
Once the load is completed u can regenerate them again.
3. Check to make sure all the standard indexes are in existence for the tables
involved.
4. Limit tables and columns to be processed using ONLY BASE
TABLES/COLUMNS configuration parameters to minimize the work that EIM
has to perform.
5. Consider switching off Siebel transaction logging during the EIM run. This will
definitely improve performance; however, it must be balanced with the need
for mobile users to re-extract afterwards.
• This parameter specifies whether the transactions to be logged to a file
or docking transaction table.
• Valid values are TRUE or FALSE.
• If set to TRUE, the transaction details are logged into the directory
<SIEBEL_FILE_SYSTEM>EIM.
• If set to FALSE, the transaction details are logged into the
S_DOCK_TXN_LOG table.
• This parameter doesn’t make sense, if DOCKING: TRANSACTION
LOGGING parameter in System Preferences is set to FALSE.
6. Try different batch sizes. Often, large batch sizes are not the most efficient.
Siebel Systems recommends that customers use a batch size no more than
5000 rows, preferably less than 2000 rows in a single batch.
7. Try using batch ranges (BATCH = x-y). This allows users to run with smaller
batch sizes and yet avoid the startup overhead on each batch.
8. Perform regular table maintenance on interface tables. Frequent insert or
delete operations on interface tables can cause fragmentation in the table.
The database administrator will know how to detect and correct
fragmentation in the EIM interface tables.
9. Delete batches from interface tables on completion. Leaving old batches in
the EIM interface table will waste space and could adversely affect
performance.
10.Run independent EIM jobs in parallel. EIM jobs that have no interface or base
tables in common can be run in parallel.
11.Set the USING SYNONYMS parameter to false in the .IFB file to indicate to EIM
that account synonyms do not need to be checked.
12.ORACLE INSERT APPENDS MODE: The default value is FALSE, which means
EIM does not use use append mode for insert at EIM process step 9, avoiding
a deadlock when running parallel EIM processes. If you need to improve step
9 performance, you can set the value to TRUE
 13.USE ESSENTIAL INDEX HINTS: Default value is TRUE

Best Practices from Oracle side –

1. Check that database stats are updated after data load

--Will use the proper indexes rather than full table scan
2. Check for the table fragmentation. Prior to running EIM it is important to
clean up fragmented objects, especially those that will be used during the
EIM processing. The following SQL statement can be used to identify objects
with greater than 10 extents:
SELECT segment_name,segment_type,tablespace_name,extentsFROM
dba_segmentsWHERE owner = (Siebel table_owner)and extents > 9;
To fix fragmentation, the objects will need to be rebuilt with appropriate
storage parameters. Always be careful when rebuilding objects because of
defaults, triggers, etc. on the objects
3. When purging data from the EIM table, use the TRUNCATE command as
opposed to DELETE. The TRUNCATE command will release the data blocks
and reset the high water mark while DELETE will not, thus causing additional
blocks to be read during processing. Also, be sure to drop and re-create the
indexes on the EIM table to release the empty blocks.
4. When dealing with huge volume of data upload, we can have index strategy
in place to make the process faster. This will impact the other part of
application who are accessing the involved object. So we need to be careful
before we think about it. Example of Index strategy is mentioned below-=
Target Table Indexing Strategy: For the target base table (e.g. S_ORG_EXT)
we would only require the Primary Index ("Px" for example P1) and the
Unique Indexes ("Ux" for example U1) and drop the remaining indexes for the
duration of the EIM import. It has often been found that the "Fx" and "Mx"
indexes can be dropped after an in depth SQL analysis of sample EIM runs.
Non-target Table indexing Strategy: For the child tables (e.g. S_ADDR_ORG)
we would only require the Primary Index ("Px"), the Unique Indexes ("Ux")
and the Foreign Key Indexes (needed for setting Primary Foreign keys in the
parent). It has often been found that the "Fx" and "Mx" indexes can be
dropped after an in depth SQL analysis of sample EIM runs.