Comments on: Adaptive Optimisation ?

By: Jonathan Lewis

Jonathan Lewis — Thu, 02 Jun 2011 20:15:32 +0000

Ahmed,

Thanks for the link – it’s a nicely written article.

By: Ahmed AANGOUR

Ahmed AANGOUR — Fri, 27 May 2011 11:09:02 +0000

An article was written recently on this topic on the Optimizer dev team's blog: http://blogs.oracle.com/optimizer/entry/cardinality_feedback

By: Impact of the TRUNC Function on an Indexed Date Column « Charles Hooper's Oracle Notes

Mon, 08 Mar 2010 06:05:41 +0000

[...] cardinality feedback (apparently not documented) is a new feature in Oracle Database 11.2.0.1 (see here for a related blog article). The first execution required 2 minutes and 33 seconds, but a [...]

By: Blogroll Report 11/12/2009-18/12/2009 « Coskan’s Approach to Oracle

Blogroll Report 11/12/2009-18/12/2009 « Coskan’s Approach to Oracle — Sat, 02 Jan 2010 17:50:44 +0000

[...] 19-How does auto cardinality feedback works in 11GR2? –read the comments Jonathan Lewis-Adaptive Optimisation ? [...]

By: Jonathan Lewis

Jonathan Lewis — Tue, 22 Dec 2009 09:38:58 +0000

It's obvious, with hind-sight, where the information is coming from. The VLDB paper that Greg linked to supplies the clue - and Iggy even quoted the relevant phrase in his extract: monitoring is enabled for the cursor. This is 11g - with SQL monitoring. You don't look in v$sql_plan_statistics(_all), you look in v$sql_monitor and v$sql_plan_monitor.

By: Jonathan Lewis

Jonathan Lewis — Tue, 22 Dec 2009 09:35:30 +0000

Randolf,
That seems perfectly plausible. Anything to do with multi-column selectivity (without a helpful index) could turn into a threat.

In fact, thinking about the possibilities, you have to start wondering more about why the feature WON’T switch on automatically.

By: Randolf Geist

Randolf Geist — Mon, 21 Dec 2009 10:22:23 +0000

By the way, thinking about it a bit further, this might be the first time that having suboptimal statistics in Oracle eventually leads to superior execution plans – depending on the thresholds defined when the difference between actual and estimated cardinalities is significant.

I think there was some time ago a thread on CDOS http://groups.google.com/group/comp.databases.oracle.server/browse_thread/thread/6aac0570974c9d62/ where this might have been the case – depending on how the SQL was using multi-column joins the “cardinality feedback” correction kicked in or not.

Randolf

By: Randolf Geist

Randolf Geist — Fri, 18 Dec 2009 21:23:28 +0000

I’ve already came across this “cardinality feedback” keyword that made me wonder when examining some 10046 traces of the DBMS_XPLAN.DISPLAY function – so at least that function was already prepared for that in some earlier releases – off the top of my head I’m not sure if it was 10.2 or 11.1 where I saw this in the query executed by DBMS_XPLAN.DISPLAY – I guess it was 11.1.

Randolf

By: Jonathan Lewis

Jonathan Lewis — Fri, 18 Dec 2009 10:00:59 +0000

Iggy,

So all we need to know now is what types of predicate(s) cause this behaviour to appear. It would also be nice to know how close is “relatively” close.

In this case, the query has a predicate:

    and t.time_id=trunc(t.time_id,'W')

This type of expresssion typically makes the optimizer use a selectivity guess of 1% – so it may be this that prompted it to gather run-time stats on the first pass.

By: joel garry

joel garry — Fri, 18 Dec 2009 01:24:14 +0000

ORACLE6>
ORACLE7> ALTER SYSTEM SET OPTIMIZER_MODE=CHOOSE — CBO has bugs, don’t collect stats, but might use it when bugs are fixed
ORACLE73> ALTER SYSTEM SET OPTIMIZER_MODE=RULE — CBO still has bugs
ORACLE8> ALTER SYSTEM SET OPTIMIZER_MODE=RULE — CBO still has bugs – Tim who?
ORACLE81> ALTER SYSTEM SET OPTIMIZER_MODE=RULE — CBO still has bugs, app not certified
(9,10,11… spend lots of time following Jonathan et al)
ORACLE14R3> ALTER SYSTEM SET OPTIMIZER_MODE=USER_RULE;