Making Siebel Run Fast with Oracle CBO – New PPS Recommendation - optimizer

Question

Hi All,
I have some good news if you are upgrading to Oracle CBO. This is a big new find that we discovered a few weeks back.
There is a certain class of queries that run very slow with the default Siebel recommended settings. Please keep in mind that in order to properly do explain plans in 10G with Siebel SQL you need to issue the following alter session statements. Also if you are using TOAD you have to uncheck the run queries in parallel since if that option is checked a new session will be launched and your options won’t be set.
ALTER SESSION SET OPTIMIZER_MODE = FIRST_ROWS_10 ;
ALTER SESSION SET "_OPTIMIZER_SORTMERGE_JOIN_ENABLED" = FALSE ;
ALTER SESSION SET "_OPTIMIZER_JOIN_SEL_SANITY_CHECK" = TRUE;
ALTER SESSION SET "_HASH_JOIN_ENABLED" = FALSE;
The key new find is that the Oracle recommendation of setting optimizer_index_cost_adj = 1 is wrong! Our new recommendation is to set this parameter to 10.
Here are some more details. This is not a silver bullet for all your Oracle performance tuning issues. Remember it is best to tune specific things that are slow from an end users perspective. In fact that is how we discovered this issue and its solution.
There is one specific class of queries that this setting will fix. You can issue alter session statements to see the difference in your explain plans. Here is how you will know the query:
•     Where clause on an intersection table and index that exists that would find just one row. This is the index we want Oracle to use.
•     Order by on BC base table and another index exists that would satisfy the order by. We don’t want to use this index since millions of rows would be accessed.
•     Explain plan shows the index for the order by is used instead of the index for the where clause that would have found a single row.
Here is the actual statement we encountered that lead to our discovery.
WHERE
T8.PR_HELD_POSTN_ID = T2.PAR_ROW_ID (+) AND
T2.BU_ID = T5.ROW_ID (+) AND
T7.ROW_ID = T4.PAR_ROW_ID AND
T7.ROW_ID = T8.PAR_ROW_ID AND
T7.ROW_ID = T3.PAR_ROW_ID AND
T7.ROW_ID = T6.PAR_ROW_ID (+) AND
T8.PR_RESP_ID = T1.ROW_ID (+) AND
(T8.EMP_FLG = 'Y') AND
(T3.LOGIN = 'UATUSER')
ORDER BY
T8.LAST_NAME, T8.FST_NAME
In addition at OOW this week we heard that an Oracle RAC expert presented Siebel on RAC and recommended setting this parameter back to its default of 100. We also talked with a very senior DBA colleague who made the same discovery over a year ago and is running with is parameter set to 25.
I can tell you that for us any setting from 1-9 gave the bad access path. 10 fixes the issue.
This find is so important that we wanted to get this out to the Siebel community ASAP.
Robert Ponder
Lead Architect and Director
Ponder Pro Serve
cell: 770.490.2767
fax: [phone]
email: [email protected]
web: www.ponderproserve.com

Answer 1

Hi All,
I know it is bad to reply to your own posts but this one is too good. Here is another example of this that all of us have.
With oica = 1 the m1 index is used and this runs a long time. With oica = 10 m6 is used and that clearly is the index Oracle wants to use since it matches the where clause exactly.
This is from the basic select we all run as part of Server Tables Clean Up. I am even including the alter session statements so you can see the drastic improvement yourself.
ALTER SESSION SET optimizer_mode = FIRST_ROWS_10;
ALTER SESSION SET "_OPTIMIZER_SORTMERGE_JOIN_ENABLED" = FALSE;
ALTER SESSION SET "_OPTIMIZER_JOIN_SEL_SANITY_CHECK" = TRUE;
ALTER SESSION SET HASH_JOIN_ENABLED = FALSE;          -- "_HASH_JOIN_ENABLED" in 10G
ALTER SESSION SET OPTIMIZER_INDEX_COST_ADJ = 1; -- then change this to 10 and run EP again.     
SELECT
T1.CONFLICT_ID,
T1.LAST_UPD,
T1.CREATED,
T1.LAST_UPD_BY,
T1.CREATED_BY,
T1.MODIFICATION_NUM,
T1.ROW_ID,
T1.ACTION_ID
FROM
SIEBEL.S_SRM_REQUEST T1
WHERE
((T1.STATUS IN ( 'SUCCESS' ) OR T1.STATUS IN ( 'EXPIRED' ) OR T1.STATUS IN ( 'COMPLETE' ))
     AND T1.TGT_DELETE_TS <= TO_DATE('11/20/2007 16:26:27','MM/DD/YYYY HH24:MI:SS'))
***** SQL Statement Execute Time for SQL Cursor with ID 10A53620: 48.333 seconds *****