/*+ hint */
/*+ hint(argument) */
/*+ hint(argument-1 argument-2) */
All hints except
/*+ rule */
to be used. Therefore, it is good practise to
analyze the underlying tables if hints are used (or the query is fully
There should be no schema names in hints. Hints must use aliases if alias names are used for table names.
So the following is wrong:
select /*+ index(scott.emp ix_emp) */ from scott.emp emp_alias
select /*+ index(emp_alias ix_emp) */ ... from scott.emp emp_alias
Why using hints
It is a perfect valid question to ask why hints should be used. Oracle comes with an
that promises to optimize a
query's execution plan
. When this optimizer is really doing
a good job, no hints should be required at all.
Sometimes, however, the characteristics of the data in the database are changing rapidly, so that the optimizer
(or more accuratly, its statistics) are out of date. In this case, a hint could help.
It must also be noted, that Oracle allows to lock the statistics when they look ideal which should make
the hints meaningless again.
Hints can be categorized as follows:
- Hints for Optimization Approaches and Goals,
- Hints for Access Paths, Hints for Query Transformations,
- Hints for Join Orders,
- Hints for Join Operations,
- Hints for Parallel Execution,
- Additional Hints
Hints for Optimization Approaches and Goals
Hints for Access Paths
Performs a nested loop by the cluster index of one of the tables.
Performs full table scan.
Hashes one table (full scan) and creates a hash index for that table. Then hashes other table and uses hash index to find corresponding records.
Therefore not suitable for < or > join conditions.
Retrieves the row by rowid
Specifying that index index_name should be used on table tab_name:
/*+ index (tab_name index_name) */
Specifying that the index should be used the the CBO thinks
is most suitable. (Not always a good choice).
Starting with Oracle 10g, the index hint can be described:
/*+ index(my_tab my_tab(col_1, col_2)) */. Using the index on my_tab that starts with the columns col_1 and col_2.
The AND_EQUAL hint explicitly chooses an execution plan
that uses an access path
that merges the scans on several single-column indexes
Hints for Query Transformations
The FACT hint is used in the context of the star transformation to indicate to
the transformation that the hinted table should be considered as a fact table.
Hints for Join Operations
Hints for Parallel Execution
If a table or an index is specified with nologging, this hint applied with an insert
statement produces a direct path insert which reduces generation of redo.
- RESULT_CACHE (Oracle 11g)
The STAR hint forces a star query plan to be used, if
possible. A star plan has the largest table in the query last in
the join order and joins it with a nested loops join on a concatenated
index. The STAR hint applies when there are at least three
tables, the large table's concatenated index has at least three
columns, and there are no conflicting access or join method
hints. The optimizer also considers different permutations of
the small tables.
Workaraound for bug 1816154
Thanks to Guy Hengel who helped on this page.