Siebel Performance Tuning Guide > Tuning Siebel EIM > Troubleshooting Siebel EIM Performance >

Additional Indexes on Siebel EIM Tables

This topic is part of Troubleshooting Siebel EIM Performance.

An examination of the data access path will assist you in determining whether additional indexes are necessary to improve the performance of the long-running SQL. In particular, look for table scans and large index range scans. In the following example, after evaluating the inner loop of the nested select, it was recommended to add an index on all T2 columns.

Inner loop:

(SELECT MIN(ROW_ID)

FROM siebel.EIM_ACCOUNT T2

WHERE (T2.T_ADDR_ORG__EXS = 'Y' AND

T2.T_ADDR_ORG__RID = T1.T_ADDR_ORG__RID AND

T2.IF_ROW_BATCH_NUM = 105 AND

T2.IF_ROW_STAT_NUM = 0 AND

T2.T_ADDR_ORG__STA = 0))

The index was created to consist of T2 columns used in the WHERE clause with ROW_ID at the end of the index. This influenced the database optimizer to choose this index for index-only access. Since the query wants the minimum (ROW_ID), the very first qualifying page in the index will also contain the lowest value.

NOTE:  All EIM indexes MUST start with IF_ROW_BATCH_NUM, or else serious performance and contention issues are unavoidable.

Adding Indexes to Improve Performance of S_ORG_EXT

The S_ORG_EXT table has indexes on many columns, but not all columns. If you have a large number of records (such as several million accounts) in S_ORG_EXT, then you can get a performance improvement in deleting and merging by adding an index to one or more of the following columns:

• PR_BL_OU_ID
• PR_PAY_OU_ID
• PR_PRTNR_TYPE_ID
• PR_SHIP_OU_ID

You can make subqueries to base tables that access only indexes. Performance is enhanced because all related records are physically collocated and because index leaf pages contain many more records per page than wider base table pages. Before implementing any additional indexes, first discuss this with qualified support personnel.