Explain Hints: Optimizer hints can be used with SQL statements to alter execution plans.

Hints let you make decisions usually made by the optimizer. As an application designer, you might know information about your data that the optimizer does not know. Hints provide a mechanism to instruct the optimizer to choose a certain query execution plan based on the specific criteria. For example, you might know that a certain index is more selective for certain queries. Based on this information, you might be able to choose a more efficient execution plan than the optimizer. In such a case, use hints to instruct the optimizer to use the optimal execution plan. Types of Hints: Hints can be of the following general types:

Single-table Single-table hints are specified on one table or view. INDEX and USE_NL are examples of single-table hints.

Multi-table Multi-table hints are like single-table hints, except that the hint can specify one or more tables or views. LEADING is an example of a multi-table hint. Note that USE_NL(table1 table2) is not considered a multi-table hint because it is actually a shortcut for USE_NL(table1) and USE_NL(table2).

Query block Query block hints operate on single query blocks. STAR_TRANSFORMATION and UNNEST are examples of query block hints.

Statement Statement hints apply to the entire SQL statement. example of a statement hint.
ALL_ROWS

is an

/*+ hint */ /*+ hint(argument) */ /*+ hint(argument-1 argument-2) */

All hints except /*+ rule */ cause the CBO to be used. Therefore, it is good practise to analyze the underlying tables if hints are used (or the query is fully hinted. 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

better:

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 optimizer that promises to optimize aquery'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.

Hint categories
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

Documented Hints
Hints for Optimization Approaches and Goals

ALL_ROWS One of the hints that 'invokes' the Cost based optimizer ALL_ROWS is usually used for batch processing or data warehousing systems. FIRST_ROWS One of the hints that 'invokes' the Cost based optimizer FIRST_ROWS is usually used for OLTP systems. CHOOSE One of the hints that 'invokes' the Cost based optimizer This hint lets the server choose (between ALL_ROWS and FIRST_ROWS, based on statistics gathered.

RULE The RULE hint should be considered deprecated as it is dropped from Oracle9i2.

Example:Below example LEADING hint specifies the exact join order to be used; the join methods to be used on the different tables are also specified.

Example 16-1 Specifying a Full Set of Hints

SELECT /*+ LEADING(e2 e1) USE_NL(e1) INDEX(e1 emp_emp_id_pk) USE_MERGE(j) FULL(j) */ e1.first_name, e1.last_name, j.job_id, sum(e2.salary) total_sal FROM employees e1, employees e2, job_history j WHERE e1.employee_id = e2.manager_id AND e1.employee_id = j.employee_id AND e1.hire_date = j.start_date GROUP BY e1.first_name, e1.last_name, j.job_id ORDER BY total_sal;