Thank you for the insight into tuning this parameter- I agree and Metalink is not always 100% correct.
Like you said in your new book never believe everything that you read. Alas many folks take a so called Oracle expert as gospel without testing things out.

Right now, I am testing out values with this and a few other settings for test and development systems first to see if any side effects occur. By the way, I am enjoying your Oracle Cost Optimizer book- very mathematical but interesting insights. I can tell that you have a solid math background :-)

And yes- the SQL queries have a lot of poorly written subqueries with IN and OR lists as well as poorly designed join conditions.

By the way, I am writing a book as well but on database migrations to Oracle. Even though I am more a DBA than a developer, I enjoy learning the ins and outs on database design and how the optimizer really works.

I can appreciate the time and effort required to write a quality technology book.

Cheers,
Ben Prusinski

I’ve just read the note – and didn’t really like it. What it demonstrates isn’t really “tuning” a parameter, it’s fiddlnig with it until one particulary query does what you want.

Admittedly, it’s quite simple in their example to calculate a suitable value – but as the final comment states, they’re just demonstrating the impact of fixing one query using one particular index.

I think the note is more about demonstrating the impact of the parameter, rather than trying to tell you how to pick a value.

If you’re not using system statistics (CPU costing) then the numbers you need should be designed to help the optimizer understand the speed at which Oracle can get data off disk.

Ideally you need to use something like Orion (the Oracle tool) or iozone to find out the relative speeds of (the equivalent of) your single block and multiblock I/O read sizes, then set optimizer_index_cost_adj to 100 * “single block read time” / “multiblock read time”.

For a typical OLTP setup, a value in the region of 30 is likely to be fairly reasonable – though a full regression test is needed to discover if you’re going to get any catastrophic side effects.

In your case the problem is much more likely to relate to bad cardinality estimates, particularly caused by correlated subqueries and IN list. See for example this note on the “5%” effect of certain types of subquery. Another source of problems is mixing subqueries with ORs.

So if I have a lot of SQL queries that are using correlated subqueries with many table joins that also have IN conditions, would it benefit me to tune this parameter to optimize my SQL query performance? I read about tuning this parameter per Metalink Note 243269.1 and was wondering how high of a value I would want to set this to with these type of poorly tuned complex queries.

Thanks
Ben Prusinski

Thanks!

Correct – optimizer_index_caching indicates the percentage of index blocks that WILL be cached; optimizer_index_cost_adj indicates the percentage of table blocks that will NOT be cached.

Of course, optimizer_index_caching applies only to branch blocks and only for nested loop joins and in list iterators and, at the end of the day, it’s just a number for which we invent a meaning.