Thanks – yes i agree with you about FIRST_ROWS_10, however, when the CBO calculates cost to get back the first 10 rows of the statement as fast as it can, it can grossly underestimate the # of rows for some key steps. Example, for the 1st predicate it uses an index range scan for that step, the CBO estimates only 10 records need to be scanned. But when running the query it goes through thousands of records as that is what it ends up taking get 10 rows which satisfy the 2nd predicate as well. I did find a potential solution for this though – even though i am mostly working at the query and database level, i discovered that in the siebel application, you can set something at the business-component level which will hint queries in that BC with an ALL_ROWS hint. That can fix some queries with this sort issue. I’m trying to get my siebel developers to look into this, as we are experiencing this issue all over the place.

sorry, I have seen your comment only today, probably I have an issue with email notifications …

The main issue with Siebel is that some “supported settings” are just there to kill the CBO. For example, setting OPTIMIZER_INDEX_COST_ADJ to 1 makes the cost of index access so tiny, that it really makes them so unrealistically cheap that the CBO basically miscalculates the cost completely … if memory serves right you have, in recent version, the opportunity to set it to the default (100) hence allowing the CBO to make its work much better. You could try it and see whether that makes any difference.

The second is that very often, if the predicates on the N tables are not selective enough, there’s no way that a nested loop could get them back efficiently – whatever table you choose as the driving table(s), it makes for a lot of index accesses on the inner tables(s). An hash join (or sort merge) would be optimal, but Siebel blocks them …

Of course to remedy the situation, you might be forced to drop the index on the ordered-by columns … possibly killing other queries. At the end, in Siebel, poor database performance has to be accepted as a fact of life almost always :(

PS: FIRST_ROWS_10 means asking the CBO to get back the first 10 rows of the statement as fast as it can, not the first 10 rows of each step.

Nice post – i just saw this the first time. However i think there are issues in my environment which are related to your post somewhat, but different. The vanilla queries coming out of siebel are as you mentioned, from what i can see. However the customizations that are often done to them are causing issues, I believe. Many screens in our environment seem to have multiple base tables, not just one. For example, a query on accounts may select for the business unit from S_ORG_BU (of which there are only 1 or 2, so this will match alot of records), but then the developers cater this query for a team, to search by a national account number, using a custom column from the accounts table. But the ORDER BY stayed on the business unit, so oracle really loves that index on the S_ORG_BU table, so it can fetch the first 10 rows quickly as you said. But the problem is, as it is fetching the 10 rows they then are matched against the other predicate on the other ACCOUNTS table S_ORG_EXT. If the row doesn’t satisfy that 2nd predicate, it must scan the next row on S_ORG_BU and try again. This can keep happening until it may end up scanning hundreds of thousands of rows until it finds 10 which match the 2nd predicate, and return them to the user. Response time can be horrible because of this. See below for an example. Even though an index exists on the X_NATIONAL_ACCOUNT_NUMBER table, the CBO doesn’t pick it up as the column is not very selective. Each national account matches a few hundred rows in that table, but this is FAR better than using the S_ORG_BU index, which matches hundreds of thousands of rows. But the CBO likes the latter, because it is thinking FIRST_ROWS_10, that it only will fetch 10 rows from each step. Seems the CBO doesn’t realize that it will scan many more rows than 10, to satisfy the 2nd predicate on S_ORG_EXT table…

SELECT …
FROM SIEBEL.S_ORG_BU T1,
…
SIEBEL.S_ORG_EXT T27
WHERE ….
AND T1.BU_ID = :1
AND T27.ROW_ID = T1.ORG_ID
AND T1.BU_ID = T8.ROW_ID
AND T1.BU_ID = T6.PAR_ROW_ID (+)
AND (T1.ORG_NAME >= :2)
AND (T27.X_NATIONAL_ACCOUNT_NUMBER = :3)
ORDER BY T1.BU_ID,
T1.ORG_NAME,
T1.ORG_LOC

Thank you for your contribution – that is definitely something that must be always remembered when “tuning” Siebel. Actually in our case, the database schema is so heavily customized (manually partitioned tables, a lot of indexes using options such as “compress” etc) that everything is pretty much done by hand … Siebel is synchronized somehow, but I do not know exactly how since I’m not the one in charge of this :)

great post and very concise!

However, I just want to throw in that it is a very common practice of the DBA to create “ad hoc” indexes in the Siebel database.

When the Siebel schema is upgraded (say to version 8.1), the upgrade process drops all indexes and recreates only those which are registered in the Siebel Repository (using Siebel Tools).

I strongly encourage that the people creating ad-hoc indexes talk to the Siebel developers so that they can add the index definition to the Siebel Repository. Or even create the definition first and then use the Siebel ddlsync utility to “apply” the metadata-resident definitions to the physical schema.

For indexes where this is not possible, you should at least document the index definition (create statement) in a way that it is present during the upgrade process.

have a nice day

@lex

The indexes are created manually, following the usual procedures – they are “ad hoc” because they are usually useful for one query only, or a bunch of strongly related queries. But they are just regular indexes, and you must make good use of your indexing skills to define them – this post is just an head start, as it summarizes the main information about the peculiarities of the Siebel environment.

If the indexes are ad hoc, will they be created (and afterwards dropped) for each query? Is this manual or automated? If automated, how?

Or will you create a standard set for your most common queries?

Thanks