Comments on: Optimizer Costing 2 – What is Wrong with this Quote?

By: Charles Hooper

Charles Hooper — Wed, 08 Dec 2010 13:02:25 +0000

I tried to be very careful when quoting the book. One of the problems with the quoted section is the English syntax used in the quoted section of the book. It almost seems that the author is suggesting to only modify the OPTIMIZER_INDEX_CACHING parameter when the DBA has failed to affect the execution plans by implementing multiple block sizes in the database – but I am not sure exactly what is intended by the first sentence.

Another potential problem is the author’s apparent suggestion that ALL index blocks should be fully cached in memory, and located in a 32KB block size tablespace. Sure, just throw 60GB of memory to cache 50GB worth of indexes. While we are at it, let’s thrown another 200GB at the buffer cache that will be used by the table blocks and the indexes in the SYS schema (or were we supposed to move those also?). If we scale this up to a much larger database, should we do the same if we have 2TB of space occupied by the indexes?

By: Magnus Fagertun

Magnus Fagertun — Mon, 06 Dec 2010 13:26:22 +0000

From the documentation: OPTIMIZER_INDEX_CACHING lets you adjust the behavior of cost-based optimization to favor nested loops joins and IN-list iterators.
I see two main problems with this:

I see two main problems with this

1) Yes, the indexes will be cached, but if you are doing index-lookup and then table access on disk the nested loops will probably go slow
2) If there ever was, now there are no true OLTP systems left. You are either doing reporting based on live data, or you are moving the data into a data warehouse. For this you need large efficient scans of tables/indexes, you will not get this by nested loop joins.

I also wonder what this setting will do if combined with system statistics… Why not leave it at default? And why do you want to fragment the buffer cache by setting several block sizes?

Magnus

By: Charles Hooper

Charles Hooper — Mon, 06 Dec 2010 10:13:22 +0000

Martin,

A very thorough answer, and you included a couple of items that I had not considered (or had not worked out in the same level of detail).

I believe that there are still a few remaining problems with the quote.

By: Martin Berger

Martin Berger — Mon, 06 Dec 2010 08:40:19 +0000

Well, where to start?
* First it’s really hard to say for sure the CBO is unaware of buffer details. Even I’m quite sure this is the true (all my observations reflected this) I have never read the corresponding code or got a statement by an Oracle representative who is aware of CBO internals.
If we consider the CBO IS unaware of buffer details, it is ALLWAYS unaware, regardless the setting of optimizer_index_caching.
* data does not use the cpu_cost metric (my data does not do anything it is passive all the time). But even if the CPU cost model is used (which is default in 10g+) the CBO does not search for the lowest estimated CPU cost. The CPU cost model takes the performance of the IO subsystem into acount also. [1]
* (afaik) there is NO way to tell the optimizer anything about RAM or the cache! Even excessive use of db_32k_cache_size will only make the index blocks be in the cache more likely (no word about the initial ‘load_it_into_the_cache’ run?) and optimizer_index_caching tells the optimizer to calculate the index extremely cheap. No bit of info about RAM or cache.
* in the first sentence it was claimed the CBO does not know anything about buffers, so how should the CBO know anything about the difference of physical and logical I/O as clamed in the last sentence?
I hope I did not introduce to many errors here.

[1] Troubleshooting Oracle Performance – p111