Oracle

SQL
hints
/*+ 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 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.

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.

See also the following initialization parameters: optimizer_mode,

optimizer_max_permutations, optimizer_index_cost_adj,
optimizer_index_caching and

Hints for Access Paths

• CLUSTER
Performs a nested loop by the cluster index of one of the
tables.
• FULL
Performs full table scan.
• HASH
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.
• ROWID
Retrieves the row by rowid
• INDEX
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.
• INDEX_ASC
 • INDEX_COMBINE
• INDEX_DESC
• INDEX_FFS
• INDEX_JOIN
• NO_INDEX
• AND_EQUAL
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

• FACT
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.
• MERGE
• NO_EXPAND
• NO_EXPAND_GSET_TO_UNION
• NO_FACT
• NO_MERGE
• NOREWRITE
• REWRITE
• STAR_TRANSFORMATION
• USE_CONCAT

Hints for Join Operations

• DRIVING_SITE
• HASH_AJ
• HASH_SJ
• LEADING
• MERGE_AJ
• MERGE_SJ
• NL_AJ
• NL_SJ
• USE_HASH
• USE_MERGE
• USE_NL

Hints for Parallel Execution

• NOPARALLEL
• PARALLEL
• NOPARALLEL_INDEX
• PARALLEL_INDEX
 • PQ_DISTRIBUTE

Additional Hints

• ANTIJOIN
• APPEND
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.
• BITMAP
• BUFFER
• CACHE
• CARDINALITY
• CPU_COSTING
• DYNAMIC_SAMPLING
• INLINE
• MATERIALIZE
• NO_ACCESS
• NO_BUFFER
• NO_MONITORING
• NO_PUSH_PRED
• NO_PUSH_SUBQ
• NO_QKN_BUFF
• NO_SEMIJOIN
• NOAPPEND
• NOCACHE
• OR_EXPAND
• ORDERED
• ORDERED_PREDICATES
• PUSH_PRED
• PUSH_SUBQ
• QB_NAME
• RESULT_CACHE (Oracle 11g)
• SELECTIVITY
• SEMIJOIN
• SEMIJOIN_DRIVER
• STAR
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.
• SWAP_JOIN_INPUTS
• USE_ANTI
 • USE_SEMI

Undocumented hints:
• BYPASS_RECURSIVE_CHECK
Workaraound for bug 1816154
• BYPASS_UJVC
• CACHE_CB
• CACHE_TEMP_TABLE
• CIV_GB
• COLLECTIONS_GET_REFS
• CUBE_GB
• CURSOR_SHARING_EXACT
• DEREF_NO_REWRITE
• DML_UPDATE
• DOMAIN_INDEX_NO_SORT
• DOMAIN_INDEX_SORT
• DYNAMIC_SAMPLING
• DYNAMIC_SAMPLING_EST_CDN
• EXPAND_GSET_TO_UNION
• FORCE_SAMPLE_BLOCK
• GBY_CONC_ROLLUP
• GLOBAL_TABLE_HINTS
• HWM_BROKERED
• IGNORE_ON_CLAUSE
• IGNORE_WHERE_CLAUSE
• INDEX_RRS
• INDEX_SS
• INDEX_SS_ASC
• INDEX_SS_DESC
• LIKE_EXPAND
• LOCAL_INDEXES
• MV_MERGE
• NESTED_TABLE_GET_REFS
• NESTED_TABLE_SET_REFS
• NESTED_TABLE_SET_SETID
• NO_FILTERING
• NO_ORDER_ROLLUPS
• NO_PRUNE_GSETS
• NO_STATS_GSETS
• NO_UNNEST
• NOCPU_COSTING
• OVERFLOW_NOMOVE
• PIV_GB
• PIV_SSF
• PQ_MAP
 • PQ_NOMAP
• REMOTE_MAPPED
• RESTORE_AS_INTERVALS
• SAVE_AS_INTERVALS
• SCN_ASCENDING
• SKIP_EXT_OPTIMIZER
• SQLLDR
• SYS_DL_CURSOR
• SYS_PARALLEL_TXN
• SYS_RID_ORDER
• TIV_GB
• TIV_SSF
• UNNEST
• USE_TTT_FOR_GSETS

Thanks
Thanks to Guy Hengel who helped on this page.

Misc
Specifying a query block in a hint.

Select (SQL)
From Wikipedia, the free encyclopedia
Jump to: navigation, search

The SQL SELECT statement returns a result set of records from one or more tables.[1][2]

It retrieves zero or more rows from one or more base tables, temporary tables, or views in
a database. In most applications, SELECT is the most commonly used Data Manipulation
Language (DML) command. As SQL is a non-procedural language, SELECT queries
specify a result set, but do not specify how to calculate it: translating the query into an
executable "query plan" is left to the database system, more specifically to the query
optimizer.

The SELECT statement has many optional clauses:

• WHERE specifies which rows to retrieve.

• GROUP BY groups rows sharing a property so that an aggregate function can be
applied to each group.
• HAVING selects among the groups defined by the GROUP BY clause.
 • ORDER BY specifies an order in which to return the rows.

Contents
[hide]

• 1 Examples
• 2 Limiting result rows
o 2.1 ROW_NUMBER() window function
o 2.2 RANK() window function
o 2.3 Non-standard syntax
o 2.4 Result limits
o 2.5 Hierarchical query
• 3 Window function
• 4 References

• 5 External links

[edit] Examples

Table "T" Query Result

C1 C2 C1 C2
1 a SELECT * FROM T; 1 a
2 b 2 b

C1 C2 C1
1 a SELECT C1 FROM T; 1
2 b 2

C1 C2 C1 C2
1 a SELECT * FROM T WHERE C1 = 1; 1 a
2 b

C1 C2 C1 C2
1 a SELECT * FROM T ORDER BY C1 DESC; 2 b
2 b 1 a

Given a table T, the query SELECT * FROM T will result in all the elements of all the
rows of the table being shown.

With the same table, the query SELECT C1 FROM T will result in the elements from the
column C1 of all the rows of the table being shown. This is similar to a projection in
Relational algebra, except that in the general case, the result may contain duplicate rows.
This is also known as a Vertical Partition in some database terms, restricting query output
to view only specified fields or columns.

With the same table, the query SELECT * FROM T WHERE C1 = 1 will result in all the
elements of all the rows where the value of column C1 is '1' being shown — in Relational
algebra terms, a selection will be performed, because of the WHERE clause. This is also
known as a Horizontal Partition, restricting rows output by a query according to specified
conditions.

[edit] Limiting result rows

Often it is convenient to indicate a maximum number of rows that are returned. This can
be used for testing or to prevent consuming excessive resources if the query returns more
information than expected. The approach to do this often varies per vendor.

In ISO SQL:2003, result sets may be limited by using

• cursors, or
• By introducing SQL window function to the SELECT-statement

[edit] ROW_NUMBER() window function

ROW_NUMBER() OVER may be used for a simple limit on the returned rows. E.g., to return
no more than ten rows:

SELECT * FROM --emp

( SELECT

ROW_NUMBER() OVER (ORDER BY sort_key ASC) AS row_number,

COLUMNS

FROM tablename

) foo

WHERE row_number <= 10

ROW_NUMBER can be non-deterministic: if sort_key is not unique, each time you run
the query it is possible to get different row numbers assigned to any rows where sort_key
is the same. When sort_key is unique, each row will always get a unique row number.

[edit] RANK() window function

The RANK() OVER window function acts like ROW_NUMBER, but may return more than
n rows in case of tie conditions. E.g., to return the top-10 youngest persons:
 SELECT * FROM (

SELECT

RANK() OVER (ORDER BY age ASC) AS ranking,

person_id,

person_name,

age

FROM person

) AS foo

WHERE ranking <= 10

The above code could return more than ten rows, e.g. if there are two people of the same
age, it could return eleven rows.

[edit] Non-standard syntax

[edit] Result limits

Not all DBMSes support the mentioned window functions, and non-standard syntax has
to be used. Below, variants of the simple limit query for different DBMSes are listed:

SELECT * FROM T LIMIT 10
OFFSET 20
SELECT * from T WHERE
ROWNUM <= 10
SELECT FIRST 10 * from T
SELECT FIRST 10 * FROM T
order by a
SELECT SKIP 20 FIRST 10
* FROM T order by c, d
SELECT * FROM T FETCH
FIRST 10 ROWS ONLY
SELECT TOP 10 * FROM T
SELECT TOP 10 START AT
20 * FROM T
SELECT FIRST 10 SKIP 20
* FROM T
SELECT * FROM T ROWS 20
TO 30
MySQL, PostgreSQL (also supports the standard, since
version 8.4), SQLite, H2
Oracle (also supports the standard, since Oracle8i)
Ingres
Informix
Informix (row numbers are filtered after order by is
evaluated. SKIP clause was introduced in a v10.00.xC4
fixpack)
DB2 (also supports the standard, in Linux, Windows, and
Unix since DB2 v8, z/OS support added in v9)
MS SQL Server (also supports the standard, since SQL
Server 2005), Sybase ASE, MS Access
Sybase SQL Anywhere (also supports the standard, since
version 9.0.1)
Interbase, Firebird
Firebird (since version 2.1)
 [edit] Hierarchical query

Some databases provide specialised syntax for hierarchical data.

[edit] Window function

A window function in SQL:2003 is an aggregate function applied to a partition of the
result set.

For example,

sum(population) OVER( PARTITION BY city )

calculates the sum of the populations of all rows having the same city value as the current
row.

Partitions are specified using the OVER clause which modifies the aggregate. Syntax:

<OVER_CLAUSE> :: =

OVER ( [ PARTITION BY <expr>, ... ]

[ ORDER BY <expression> ] )

The OVER clause can partition and order the result set. Ordering is used for order-
relative functions such as row_number.

Adding Row
Number to SQL
SELECT result
 Post Need
comments help?

Introduction
This article will explain
how we can add
sequence row number
to a SQL select query
starting from 1
onwards. This can be
achieved by using built
in SQL function ?
ROW_NUMBER()?. This
function simply
generates row number
for each row in the
result. You can specify
the partition and order
by criteria. This is how
it works:

e.g. Suppose we have a

table ?Employees?.

SELECT EmployeeId,
EmployeeName,
Salary

FROM Employees

EmployeeId
EmployeeName
Salary

------------------
------------------
-

1002 Alden
4000

2343
Lawson
4500
 2004
Barbra
4800

1105
Marsden
4500

3116 Mac
5000

Use of ROW_NUMBER()
will assign sequence
number to rows as:

SELECT
ROW_NUMBER()

OVER
(ORDER BY
EmployeeName) AS
Row,

EmployeeId,
EmployeeName,
Salary

FROM Employees

Row EmployeeId
EmployeeName
Salary

------------------
------------------
-------

1 1002
Alden
4000

2 2343
Lawson
4500

3 2004
Barbra
 4800

4 1105
Marsden
4500

5 3116
Mac
5000

Using
ROW_NUMBER()
for calculating
Nth highest
salary
We can utilize this
function for calculating
Nth highest salary of a
employee. Suppose we
want to find employee
with 4th highest salary.
This can be done as:

SELECT * FROM

(SELECT
ROW_NUMBER()

OVER
(ORDER BY Salary)
AS Row,

EmployeeId
, EmployeeName,
Salary

FROM
Employees) AS EMP

WHERE Row = 4

Row EmployeeId
EmployeeName
 Salary

------------------
------------------
-------

4 1105
Marsden
4500

Using
ROW_NUMBER()
in case of
pagination
This can also be used
for getting rows which
belongs to a particular
page only. This is very
common scenario of a
business application
where we have lots of
rows in database and
we want to filter based
on page number.

SELECT * FROM

(SELECT
ROW_NUMBER()

OVER
(ORDER BY
EmployeeName) AS
Row,

EmployeeId
, EmployeeName,
Salary

FROM
Employees) AS EMP

WHERE Row BETWEEN

2 AND 4
 Row EmployeeId
EmployeeName
Salary

------------------
------------------
-------

2 2343
Lawson
4500

3 2004
Barbra
4800

4 1105
Marsden
4500

Post Need
comments help?

How to use hints in Oracle sql for performance

With hints one can influence the optimizer. The usage of hints (with
exception of the RULE-hint) causes Oracle to use the Cost Based
optimizer.

The following syntax is used for hints:

select /*+ HINT */ name

from emp
where id =1;

Where HINT is replaced by the hint text.

When the syntax of the hint text is incorrect, the hint text is ignored and will
not be used.
here you can find undocumented hints.
 Hints for Optimization Approaches and Goals

The ALL_ROWS hint explicitly

chooses the cost-based approach to
ALL_ROWS optimize a statement block with a goal
of best throughput (that is, minimum
total resource consumption).
The FIRST_ROWS hint explicitly
chooses the cost-based approach to
optimize a statement block with a goal
of best response time (minimum
resource usage to return first row). In
FIRST_ROWS newer Oracle version you should give
a parameter with this hint:
FIRST_ROWS(n) means that the
optimizer will determine an
executionplan to give a fast response
for returning the first n rows.
The CHOOSE hint causes the
optimizer to choose between the rule-
based approach and the cost-based
CHOOSE
approach for a SQL statement based
on the presence of statistics for the
tables accessed by the statement
The RULE hint explicitly chooses rule-
based optimization for a statement
block. This hint also causes the
RULE optimizer to ignore any other hints
specified for the statement block. The
RULE hint does not work any more in
Oracle 10g.
Hints for Access Paths

The FULL hint explicitly chooses a full

table scan for the specified table. The
syntax of the FULL hint is FULL(table)
FULL where table specifies the alias of the
table (or table name if alias does not
exist) on which the full table scan is to
be performed.
The ROWID hint explicitly chooses a
table scan by ROWID for the specified
table. The syntax of the ROWID hint
is ROWID(table) where table specifies
ROWID
the name or alias of the table on
which the table access by ROWID is
to be performed. (This hint depricated
in Oracle 10g)
The CLUSTER hint explicitly chooses
a cluster scan to access the specified
CLUSTER table. The syntax of the CLUSTER
hint is CLUSTER(table) where table
specifies the name or alias of the
 table to be accessed by a cluster
scan.
The HASH hint explicitly chooses a
hash scan to access the specified
table. The syntax of the HASH hint is
HASH
HASH(table) where table specifies the
name or alias of the table to be
accessed by a hash scan.
The HASH_AJ hint transforms a NOT
IN subquery into a hash anti-join to
access the specified table. The syntax
HASH_AJ of the HASH_AJ hint is
HASH_AJ(table) where table specifies
the name or alias of the table to be
accessed.(depricated in Oracle 10g)
The INDEX hint explicitly chooses an
index scan for the specified table. The
syntax of the INDEX hint is
INDEX(table index) where:table
specifies the name or alias of the
INDEX
table associated with the index to be
scanned and index specifies an index
on which an index scan is to be
performed. This hint may optionally
specify one or more indexes:
The NO_INDEX hint explicitly
disallows a set of indexes for the
NO_INDEX specified table. The syntax of the
NO_INDEX hint is NO_INDEX(table
index)
The INDEX_ASC hint explicitly
chooses an index scan for the
specified table. If the statement uses
INDEX_ASC
an index range scan, Oracle scans
the index entries in ascending order of
their indexed values.
If no indexes are given as arguments
for the INDEX_COMBINE hint, the
optimizer will use on the table
whatever boolean combination of
bitmap indexes has the best cost
INDEX_COMBINE estimate. If certain indexes are given
as arguments, the optimizer will try to
use some boolean combination of
those particular bitmap indexes. The
syntax of INDEX_COMBINE is
INDEX_COMBINE(table index).
Explicitly instructs the optimizer to use
an index join as an access path. For
the hint to have a positive effect, a
INDEX_JOIN
sufficiently small number of indexes
must exist that contain all the columns
required to resolve the query.
INDEX_DESC The INDEX_DESC hint explicitly
 chooses an index scan for the
specified table. If the statement uses
an index range scan, Oracle scans
the index entries in descending order
of their indexed values.
This hint causes a fast full index scan
INDEX_FFS to be performed rather than a full
table.
Do not use fast full index scan (from
NO_INDEX_FFS
Oracle 10g)
Exclude range scan from query plan
INDEX_SS
(from Oracle 10g)
Exclude range scan from query plan
INDEX_SS_ASC
(from Oracle 10g)
Exclude range scan from query plan
INDEX_SS_DESC
(from Oracle 10g)
The NO_INDEX_SS hint causes the
optimizer to exclude a skip scan of the
NO_INDEX_SS
specified indexes on the specified
table. (from Oracle 10g)
Hints for Query Transformations

Prevents the optimizer performing

NO_QUERY_TRANSFORMATION query transformations. (from Oracle
10g)
The USE_CONCAT hint forces
combined OR conditions in the
WHERE clause of a query to be
transformed into a compound query
USE_CONCAT using the UNION ALL set operator.
Normally, this transformation occurs
only if the cost of the query using the
concatenations is cheaper than the
cost without them.
The NO_EXPAND hint prevents the
optimizer from considering OR-
expansion for queries having OR
conditions or IN-lists in the WHERE
NO_EXPAND
clause. Usually, the optimizer
considers using OR expansion and
uses this method if it decides that the
cost is lower than not using it.
The REWRITE hint forces the
optimizer to rewrite a query in terms
of materialized views, when possible,
without cost consideration. Use the
REWRITE REWRITE hint with or without a view
list. If you use REWRITE with a view
list and the list contains an eligible
materialized view, then Oracle uses
that view regardless of its cost.
In Oracle 10g renamed to
NOREWRITE / NO_REWRITE
NO_REWRITE. The
 NOREWRITE/NO_REWRITE hint
disables query rewrite for the query
block, overriding the setting of the
parameter
QUERY_REWRITE_ENABLED.
The MERGE hint lets you merge
MERGE
views in a query.
The NO_MERGE hint causes Oracle
not to merge mergeable views. This
NO_MERGE hint is most often used to reduce the
number of possible permutations for a
query and make optimization faster.
The FACT hint indicated that the table
should be considered as a fact table.
FACT
This is used in the context of the star
transformation.
The NO_FACT hint is used in the
context of the star transformation to
NO_FACT indicate to the transformation that the
hinted table should not be considered
as a fact table.
The STAR_TRANSFORMATION hint
makes the optimizer use the best plan
in which the transformation has been
used. Without the hint, the optimizer
STAR_TRANSFORMATION could make a query optimization
decision to use the best plan
generated without the transformation,
instead of the best plan for the
transformed query.
Do not use star transformation (from
NO_STAR_TRANSFORMATION
Oracle 10g)
The UNNEST hint specifies subquery
UNNEST
unnesting.
Use of the NO_UNNEST hint turns off
NO_UNNEST unnesting for specific subquery
blocks.
Hints for Join Orders

Give this hint to indicate the leading

table in a join. This will indicate only 1
table. If you want to specify the whole
LEADING
order of tables, you can use the
ORDERED hint. Syntax:
LEADING(table)
ORDERED The ORDERED hint causes Oracle to
join tables in the order in which they
appear in the FROM clause. If you
omit the ORDERED hint from a SQL
statement performing a join , the
optimizer chooses the order in which
to join the tables. You may want to
use the ORDERED hint to specify a
 join order if you know something
about the number of rows selected
from each table that the optimizer
does not. Such information would
allow you to choose an inner and
outer table better than the optimizer
could.
Hints for Join Operations

The USE_NL hint causes Oracle to

join each specified table to another
row source with a nested loops join
using the specified table as the inner
USE_NL table. The syntax of the USE_NL hint
is USE_NL(table table) where table is
the name or alias of a table to be
used as the inner table of a nested
loops join.
Do not use nested loop (from Oracle
NO_USE_NL
10g)
Specifies a nested loops join. (from
USE_NL_WITH_INDEX
Oracle 10g)
The USE_MERGE hint causes Oracle
to join each specified table with
another row source with a sort-merge
join. The syntax of the USE_MERGE
USE_MERGE hint is USE_MERGE(table table)
where table is a table to be joined to
the row source resulting from joining
the previous tables in the join order
using a sort-merge join.
NO_USE_MERGE Do not use merge (from Oracle 10g)
The USE_HASH hint causes Oracle
to join each specified table with
another row source with a hash join.
The syntax of the USE_HASH hint is
USE_HASH USE_HASH(table table) where table
is a table to be joined to the row
source resulting from joining the
previous tables in the join order using
a hash join.
NO_USE_HASH Do not use hash (from Oracle 10g)
Hints for Parallel Execution

PARALLEL The PARALLEL hint allows you to

specify the desired number of
concurrent query servers that can be
used for the query. The syntax is
PARALLEL(table number number).
The PARALLEL hint must use the
table alias if an alias is specified in the
query. The PARALLEL hint can then
take two values separated by
 commas after the table name. The
first value specifies the degree of
parallelism for the given table, the
second value specifies how the table
is to be split among the instances of a
parallel server. Specifying DEFAULT
or no value signifies the query
coordinator should examine the
settings of the initialization
parameters (described in a later
section) to determine the default
degree of parallelism.
The NOPARALLEL hint allows you to
disable parallel scanning of a table,
NOPARALLEL / NO_PARALLEL even if the table was created with a
PARALLEL clause. In Oracle 10g this
hint was renamed to NO_PARALLEL.
The PQ_DISTRIBUTE hint improves
the performance of parallel join
operations. Do this by specifying how
rows of joined tables should be
PQ_DISTRIBUTE
distributed among producer and
consumer query servers. Using this
hint overrides decisions the optimizer
would normally make.
The NO_PARALLEL_INDEX hint
overrides a PARALLEL attribute
NO_PARALLEL_INDEX
setting on an index to avoid a parallel
index scan operation.
Additional Hints

When the APPEND hint is used with

the INSERT statement, data is
appended to the table. Existing free
space in the block is not used. If a
APPEND 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.
NOAPPEND Overrides the append mode.
The CACHE hint specifies that the
blocks retrieved for the table in the
hint are placed at the most recently
used end of the LRU list in the buffer
CACHE cache when a full table scan is
performed. This option is useful for
small lookup tables. In the following
example, the CACHE hint overrides
the table default caching specification.
NOCACHE The NOCACHE hint specifies that the
blocks retrieved for this table are
placed at the least recently used end
of the LRU list in the buffer cache
 when a full table scan is performed.
This is the normal behavior of blocks
in the buffer cache.
The PUSH_PRED hint forces pushing
PUSH_PRED
of a join predicate into the view.
The NO_PUSH_PRED hint prevents
NO_PUSH_PRED pushing of a join predicate into the
view.
The PUSH_SUBQ hint causes
nonmerged subqueries to be
PUSH_SUBQ
evaluated at the earliest possible
place in the execution plan.
The NO_PUSH_SUBQ hint causes
non-merged subqueries to be
NO_PUSH_SUBQ
evaluated as the last step in the
execution plan.
Specifies a name for a query block.
QB_NAME
(from Oracle 10g)
Oracle can replace literals in SQL
statements with bind variables, if it is
safe to do so. This is controlled with
the CURSOR_SHARING startup
parameter. The
CURSOR_SHARING_EXACT CURSOR_SHARING_EXACT hint
causes this behavior to be switched
off. In other words, Oracle executes
the SQL statement without any
attempt to replace literals by bind
variables.
The DRIVING_SITE hint forces query
execution to be done for the table at a
DRIVING_SITE
different site than that selected by
Oracle
The DYNAMIC_SAMPLING hint lets
you control dynamic sampling to
improve server performance by
determining more accurate predicate
selectivity and statistics for tables and
indexes. You can set the value of
DYNAMIC_SAMPLING DYNAMIC_SAMPLING to a value
from 0 to 10. The higher the level, the
more effort the compiler puts into
dynamic sampling and the more
broadly it is applied. Sampling
defaults to cursor level unless you
specify a table.
This hint omits some of the compile
time optimizations of the rules, mainly
detailed dependency graph analysis,
on spreadsheets. Some optimizations
SPREAD_MIN_ANALYSIS
such as creating filters to selectively
populate spreadsheet access
structures and limited rule pruning are
still used. (from Oracle 10g)
Hints with unknown status

The MERGE_AJ hint transforms a

NOT IN subquery into a merge anti-
join to access the specified table. The
syntax of the MERGE_AJ hint is
MERGE_AJ
MERGE_AJ(table) where table
specifies the name or alias of the
table to be accessed.(depricated in
Oracle 10g)
The AND_EQUAL hint explicitly
chooses an execution plan that uses
an access path that merges the scans
on several single-column indexes.
The syntax of the AND_EQUAL hint is
AND_EQUAL(table index index)
where table specifies the name or
AND_EQUAL
alias of the table associated with the
indexes to be merged. and index
specifies an index on which an index
scan is to be performed. You must
specify at least two indexes. You
cannot specify more than five.
(depricated in Oracle 10g)
The STAR hint forces the large table
to be joined last using a nested loops
join on the index. The optimizer will
STAR
consider different permutations of the
small tables. (depricated in Oracle
10g)
Usage: BITMAP(table_name
BITMAP index_name) Uses a bitmap index to
access the table. (depricated ?)
Use a Hash Anti-Join to evaluate a
NOT IN sub-query. Use this hint in the
sub-query, not in the main query. Use
this when your high volume NOT IN
HASH_SJ
sub-query is using a FILTER or
NESTED LOOPS join. Try
MERGE_AJ if HASH_AJ refuses to
work.(depricated in Oracle 10g)
Use a Nested Loop in a sub-query.
NL_SJ
(depricated in Oracle 10g)
Use an anti-join in a sub-query.
NL_AJ
(depricated in Oracle 10g)
ORDERED_PREDICATES (depricated in Oracle 10g)
EXPAND_GSET_TO_UNION (depricated in Oracle 10g)