I am going to build some test tables with partitions and play with moving stats around, collecting stats, different sampling hints etc… I will report my findings back here : )

I also have Jonathan Lewis’s CBO book sitting here collecting dust. I bought it and haven’t read much of it. I guess I know what I will be doing this weekend!

As of the hints question - another well known Tom has defined the term “good hints”. Those are “good” to be used because they help the optimizer to do a better choice:

http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:7038986332061#14621915372791

If you’re refering to the BLOCK clause I believe that just changes the mechanism of identifying which data to sample — you are specifying the percentage of blocks to sample instead of the percentage of rows (or the probability of an individual row or block being sampled, depending on your POV), which may be appropriate and more efficient under some circumstances.

I see the dynamic sampling hint differently to many others that you might indeed leave alone in order to let the optimizer make its own choice. By specifying a higher level of sampling than the system default you’re giving permission to the optimizer to spend more time and use more resources specifically in order to make a better decision. That’s not a choice that the optimizer is going to make right otherwise.

Whether it is the high value in the global statistics that cause the incorrect plan or the partition statistics that say “no rows in here” depends on whether the optimizer knows at parse time which single partition the rows are going to be in.

The doco ref is here:

http://download.oracle.com/docs/cd/B19306_01/server.102/b14200/statements_10002.htm#sthref9790

This suggests that the SAMPLE clause can be asked to look at a specific number of blocks, I’m guessing based on the setting of the param to which I referred. The doco also has some notes on the restriction of access paths that might be used ( includes FTS and IFFS as a possibility).

It also describes a mechanism to attempt to allow the DB to use the same sample from one execution to the next ( not clear what this means when the data may have changed, maybe it just accesses the same blocks, if available? )

All of which just adds some background, and the detail may just be academic.

Curious to find out what the behaviour is on your system, and any insights you might uncover as to how this all works.

Cheers.

Mat.

Did you try dynamic sampling for that? I honestly cannot recall a case where it failed to produce a god plan.

According to documented behaviour we’d be sampling 64 blocks for unanalyzed tables at level 4, which ought to take in the order of two tenths of a second. Based on that I’m very willing to go higher, to levels 5 or 6, as the overwhelming majority of ETL queries take multiple tens of seconds to execute. I doubt that it’s multiblock io — in fact i hope it isn’t as that would call the randomness into question on large tabes, particularly date-partitioned ones.

I guess that those defaults are estimates really — the sampling is implemented with a SAMPLE clause, which is not really deterministic I think. I wouldn’t be suprised if in fact the 64 blocks was in some cases 58 and in others 69 — not tested that though.