Thank you for the links – those will be very helpful for the sections of the book that offer advice about index rebuilds. It might be interesting to read Richard Foote’s review of the book, if he bought a copy.

http://richardfoote.wordpress.com/2009/02/18/larger-block-tablespace-for-indexes-revisited-part-i-the-tourist/
http://richardfoote.wordpress.com/2009/02/23/larger-block-tablespace-for-indexes-revisted-part-ii-money/
http://richardfoote.wordpress.com/2009/03/02/larger-block-tablespace-for-indexes-revisited-part-iii-prove-yourself/

Thank you for the extensive explanation, it is very helpful. This quote from th book might be just one example that shows why it is a bad idea to recycle material that was published in 2001 – the errors and problems caused by the missing details are amplified nine years later due to the new features added to Oracle Database over that time.

In your comment, you stated ” There is no direct relationship between cost and db_block_size, there are only side effects, and it is far from trivial to understand these side effects.” And ” I believe a strong proponent of putting indexes into tablespaces with the largest possible block size.” The book is also a strong proponent of replacing most full table scans with some sort of index access path. There is an interesting tie-in with Randolf Geist’s System Statistics presentation, which includes a section (starting at slide 59) that discusses the effects of non-uniform block sizes on the Oracle optimizer’s costing of access paths. Randolf’s test case seems to show a significant drop in the optimizer’s costing calculations for the objects in the larger block size – dropping the cost number without improving the execution time. Randolf’s test case used a 10,000 block example with 1 row per block in a locally managed tablespace using manual segment space management and a default 8KB block size (DB_BLOCK_SIZE). His test demonstrated what happens to the execution plan costs when the cost model changes between the various cost models:
Traditional I/O Costing:
2KB block tablespace: 2441
8KB block tablespace: 1517
16KB block tablespace: 1199

NOWORKLOAD System Statistics:
2KB block tablespace: 7708
8KB block tablespace: 2708
16KB block tablespace: 1875

WORKLOAD System Statistics:
2KB block tablespace: 10833
8KB block tablespace: 2708
16KB block tablespace: 1354

Quite clearly from the above, if someone is convinced to tune by cost (I do not recall the book suggesting that), one would create a database with a 2KB default tablespace, create a 32KB tablespace, and then create all objects in the 32KB tablespace. It might be worth experimentation to see what happens to the costing of index access paths when the indexes are recreated in a 32KB or 16KB tablespace with the table data still residing in the 8KB (or 2KB) default tablespace – would this change automatically tune the whole database to use indexes rather than full tablescans? I see the start of a silver bullet.

Lewis Carroll – The hunting of the Snark

The first thought that springs to mind is that when listing 4 points you don’t usually start at number 7.

Second is that the clustering_factor doesn’t make it to the list (although it is mentioned immediately afterwards – which also makes me wonder whether the author read the list before inserting it).

If the author thinks the “db_block_size” is one of “the four factors”, you have to wonder why the db_file_multiblock_read_count is not, why the values for the MBRC, mreadtim, sreadtim system statistics are not, and why the author does not believe that the block sizes of the tablespaces holding the table and its indexes are not factors (the author is, I believe a strong proponent of putting indexes into tablespaces with the largest possible block size).

I hope the author includes a detailed discussion of why the db_block_size affects the optimizer’s choice. There is no direct relationship between cost and db_block_size, there are only side effects, and it is far from trivial to understand these side effects.

Like db_block_size, the avg_row_len is not a factor that the optimizer uses when making the choice between a tablescan and an indexed access path. There are, of course, (subtle) side effects (again) – e.g. longer rows means fewer rows per block which affects the probability of two adjacent key values pointing to two different blocks (hence an increase in the clustering_factor, hence the cost of using the index); then again, longer rows means fewer rows per block, which means more table blocks which increases the cost of the tablescan ! (We might also note that the average index key length affects the choice – which also means the level of prefix compression affects the choice, since both will affect the number of leaf blocks in the index, and the leaf block count really IS a factor influencing the cost of using the index.)

The “selectivity of a column” – what about multi-column indexes ?

The “cardinality” is derived from the selectivity as an estimate of the number of output rows – it isn’t an input to the cost, so doesn’t affect the choice of tablescan or index. If you wanted an explanation for a novice you might couch it in terms of cardinality – but that’s like talking about “the Sun rising” rather than “the Earth rotating”.

“High” selectivity – I think we could do with the author’s definition of selectivity here. For the purposes of the optimizer, “selectivity” is a number between 0 and 1 and, all other things being equal, the high the selectivity for an indexed access patt the less likely the optimizer is to choose it.

The text switches from the cost to the run time without making the point that the cost is an estimate of the run time and the run time could be completely different. It is (for example) easy to have a very high clustering_factor and still have a very fast run time because of the way that Oracle generates the clustering_factor.

The trouble with getting things right is that it takes so much longer, and so much more effort than just putting a few vaguely relevant words in roughly the right order.