THE WORLD DISCUSSES #PYTHIAN ON TWITTER. HAVE A QUESTION? USE OUR HASHTAG AND ASK AWAY.

Oracle’s OPT_ESTIMATE hint: Usage Guide

It’s one of those hints that you’ve heard about many times, but all the information is scattered, and finding what you need is really hard.

Many (including myself) have expressed the deepest desire to see it documented, but that never happened. I’ve just troubleshot a problem and used this hint a lot during my “what if” scenario testing, and found this hint to be quite useful. Thus, I decided to document it here on the blog.

I will come back and update this blog as I discover new parameters, and feel free to suggest what you’ve found in the comments. If you can, include an example to illustrate usage.

Note that this usage guide is not official, and is built upon by my best understanding on how this hint operates.

OPT_ESTIMATE

Purpose

To influence costing and cardinality estimates by the optimizer in the hope that a better execution path is selected. This hint supersedes the “CARDINALITY” hint.

Usage

Parameters separate by space (optionally by comma). “[]” means that “query block” is optional.

/*+ OPT_ESTIMATE( [query block] operation_type identifier adjustment ) */

  • query block

    optional and in the format “@QB_NAME”. For example, in the lack of any QB_NAME hints, you could say: OPT_ESTIMATE(@SEL$1 TABLE….)

  • operation_type

    QUERY_BLOCK
    unknown

    TABLE
    refers to table

    Example:

    select /*+OPT_ESTIMATE(TABLE DD ROWS=10)*/
    count(*) from dual DD
    

    INDEX_FILTER
    adjusts index filtering – number of rows produced by the index lookup, does not affect the cost to scan the index

    INDEX_SCAN / INDEX_SKIP_SCAN
    For index range or skip scans – how many rows will be scanned in the index – affects the COST of the index access and the number of rows outputted

    JOIN
    the join result of 2 tables – oracle joins 2 tables at a time. Note that you can adjust join cardinalities between 2 tables in order to make that join not to be used.

  • identifier

    qry_block is always optional

    TABLES: tab_alias@qry_block

    INDEX: tab_alias@qry_block index_name

    JOINS: JOIN(tab1_alias@qry_block tab2_alias@qry_block)

  • adjustment

    ROWS=number

    SCALE_ROWS=number – multiplier to be used. For example 0.1 is 10 times less rows than originally estimated

    MIN=minimum number of rows from step – very useful to prevent ‘insane’ plans

    MAX=maximum number of rows from step

Updated:
Dec 06: Added MIN/MAX description
June 21: Added References

References.

These are sites that gave me syntax details, or usage details. The examples and experiments however are my own.

http://jonathanlewis.wordpress.com/2007/02/11/profiles/

http://dioncho.wordpress.com/2009/12/17/trivial-research-on-the-cardinality-feedback-on-11gr2/

http://www.freelists.org/post/oracle-l/How-are-SQL-Profiles-calculated

4 Responses

  1. Dion Cho says:

    Good. I’ve been waiting for someone to make a list for this hint.

    Thanks for the work.

  2. ??Charlie says:

    Hi,

    Could you give an INDEX_SCAN example?

    I can only figure out the JOIN operation_type,

    select /*+ OPT_ESTIMATE(JOIN(e d) ROWS=700) */
    ename,job
    from scott.emp e, scott.dept d
    where d.deptno > 0
    and e.deptno = d.deptno;

  3. e.g. This doesn’t work on my 11.2 database,

    select /*+ OPT_ESTIMATE(INDEX_SCAN, D4, PK_DEPT, ROWS=555 ) */
    dname
    from scott.dept D4
    where deptno > 0;

    SELECT * FROM table(DBMS_XPLAN.DISPLAY_cursor(format => ‘TYPICAL’ ));

    Thanks,
    Charlie

  4. [...] OPT_ESTIMATE (Undocumented but useful link) [...]

Leave a Reply

Start NowWith Pythian - database design, management and emergency handling capabilities...

Live Updates

pythian: RT @FN_Press2: Schooner Information Technology Teams with Pythian to Deliver Advanced Support and High... http://finanznachrichten.de/20
more



Testimonials

  • Serge Racine

    DBA, Brookfield Energy

    We are very satisfied by the service given to us by Andre and Shakir in support of our recent data quality and reorganization initiative.... more