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 hintsIt 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 categoriesHints 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_ROWSOne of the hints that 'invokes' the Cost based optimizer ALL_ROWS is usually used for batch processing or data warehousing systems.

FIRST_ROWSOne of the hints that 'invokes' the Cost based optimizer FIRST_ROWS is usually used for OLTP systems.

CHOOSEOne 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.

RULEThe 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

CLUSTERPerforms a nested loop by the cluster index of one of the tables.

FULLPerforms full table scan.

HASHHashes 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.

ROWIDRetrieves the row by rowid

INDEXSpecifying 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

FACTThe 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_CHECKWorkaraound 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

ThanksThanks to Guy Hengel who helped on this page.

MiscSpecifying a query block in a hint.

Select (SQL)

From Wikipedia, the free encyclopediaJump 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 C21 a

2 b

SELECT * FROM T;

C1 C21 a

2 b

C1 C2 SELECT C1 FROM T; C1

1 a

2 b

1

2

C1 C21 a

2 b

SELECT * FROM T WHERE C1 = 1;C1 C21 a

C1 C21 a

2 b

SELECT * FROM T ORDER BY C1 DESC;

C1 C22 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

MySQL, PostgreSQL (also supports the standard, since version 8.4), SQLite, H2

SELECT * from T WHERE ROWNUM <= 10 Oracle (also supports the standard, since Oracle8i)SELECT FIRST 10 * from T IngresSELECT FIRST 10 * FROM T order by a Informix

SELECT SKIP 20 FIRST 10 * FROM T order by c, d

Informix (row numbers are filtered after order by is evaluated. SKIP clause was introduced in a v10.00.xC4 fixpack)

SELECT * FROM T FETCH FIRST 10 ROWS ONLY

DB2 (also supports the standard, in Linux, Windows, and Unix since DB2 v8, z/OS support added in v9)

SELECT TOP 10 * FROM T MS SQL Server (also supports the standard, since SQL Server 2005), Sybase ASE, MS Access

SELECT TOP 10 START AT 20 * FROM T

Sybase SQL Anywhere (also supports the standard, since version 9.0.1)

SELECT FIRST 10 SKIP 20 * FROM T Interbase, FirebirdSELECT * FROM T ROWS 20 TO 30 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 comments   

Need help?

IntroductionThis 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 salaryWe 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 paginationThis 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 Nee

comments   

d help?

How to use hints in Oracle sql for performanceWith 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 */ namefrom empwhere 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

ALL_ROWS

The ALL_ROWS hint explicitly chooses the cost-based approach to optimize a statement block with a goal of best throughput (that is, minimum total resource consumption).

FIRST_ROWS

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 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.

CHOOSE The CHOOSE hint causes the optimizer to choose between the rule-based approach and the cost-based approach for a SQL statement based

on the presence of statistics for the tables accessed by the statement

RULE

The RULE hint explicitly chooses rule-based optimization for a statement block. This hint also causes the 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

FULL

The FULL hint explicitly chooses a full table scan for the specified table. The syntax of the FULL hint is FULL(table) 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.

ROWID

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 the name or alias of the table on which the table access by ROWID is to be performed. (This hint depricated in Oracle 10g)

CLUSTER

The CLUSTER hint explicitly chooses a cluster scan to access the specified 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.

HASH

The HASH hint explicitly chooses a hash scan to access the specified table. The syntax of the HASH hint is HASH(table) where table specifies the name or alias of the table to be accessed by a hash scan.

HASH_AJ

The HASH_AJ hint transforms a NOT IN subquery into a hash anti-join to access the specified table. The syntax 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)

INDEX 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 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:

NO_INDEX

The NO_INDEX hint explicitly disallows a set of indexes for the specified table. The syntax of the NO_INDEX hint is NO_INDEX(table index)

INDEX_ASC

The INDEX_ASC hint explicitly chooses an index scan for the specified table. If the statement uses an index range scan, Oracle scans the index entries in ascending order of their indexed values.

INDEX_COMBINE

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 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).

INDEX_JOIN

Explicitly instructs the optimizer to use an index join as an access path. For the hint to have a positive effect, a 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.

INDEX_FFS This hint causes a fast full index scan to be performed rather than a full table.

NO_INDEX_FFS Do not use fast full index scan (from Oracle 10g)

INDEX_SS Exclude range scan from query plan (from Oracle 10g)

INDEX_SS_ASC Exclude range scan from query plan (from Oracle 10g)

INDEX_SS_DESC Exclude range scan from query plan (from Oracle 10g)

NO_INDEX_SS

The NO_INDEX_SS hint causes the optimizer to exclude a skip scan of the specified indexes on the specified table. (from Oracle 10g)

Hints for Query Transformations

NO_QUERY_TRANSFORMATION Prevents the optimizer performing query transformations. (from Oracle 10g)

USE_CONCAT

The USE_CONCAT hint forces combined OR conditions in the WHERE clause of a query to be transformed into a compound query 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.

NO_EXPAND

The NO_EXPAND hint prevents the optimizer from considering OR-expansion for queries having OR conditions or IN-lists in the WHERE clause. Usually, the optimizer considers using OR expansion and uses this method if it decides that the cost is lower than not using it.

REWRITE

The REWRITE hint forces the optimizer to rewrite a query in terms of materialized views, when possible, without cost consideration. Use the 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.

NOREWRITE / NO_REWRITE

In Oracle 10g renamed to NO_REWRITE. The NOREWRITE/NO_REWRITE hint disables query rewrite for the query block, overriding the setting of the parameter QUERY_REWRITE_ENABLED.

MERGE The MERGE hint lets you merge views in a query.

NO_MERGE

The NO_MERGE hint causes Oracle not to merge mergeable views. This hint is most often used to reduce the number of possible permutations for a query and make optimization faster.

FACT

The FACT hint indicated that the table should be considered as a fact table. This is used in the context of the star transformation.

NO_FACT

The NO_FACT hint is used in the context of the star transformation to indicate to the transformation that the hinted table should not be considered as a fact table.

STAR_TRANSFORMATION The STAR_TRANSFORMATION hint

makes the optimizer use the best plan in which the transformation has been used. Without the hint, the optimizer could make a query optimization decision to use the best plan generated without the transformation, instead of the best plan for the transformed query.

NO_STAR_TRANSFORMATION Do not use star transformation (from Oracle 10g)

UNNEST The UNNEST hint specifies subquery unnesting.

NO_UNNEST Use of the NO_UNNEST hint turns off unnesting for specific subquery blocks.

Hints for Join Orders

LEADING

Give this hint to indicate the leading table in a join. This will indicate only 1 table. If you want to specify the whole 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

USE_NL

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 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.

NO_USE_NL Do not use nested loop (from Oracle 10g)

USE_NL_WITH_INDEX Specifies a nested loops join. (from

Oracle 10g)

USE_MERGE

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 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)

USE_HASH

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(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.

NOPARALLEL / NO_PARALLEL

The NOPARALLEL hint allows you to disable parallel scanning of a table, even if the table was created with a PARALLEL clause. In Oracle 10g this hint was renamed to NO_PARALLEL.

PQ_DISTRIBUTE The PQ_DISTRIBUTE hint improves the performance of parallel join operations. Do this by specifying how rows of joined tables should be distributed among producer and

consumer query servers. Using this hint overrides decisions the optimizer would normally make.

NO_PARALLEL_INDEX

The NO_PARALLEL_INDEX hint overrides a PARALLEL attribute setting on an index to avoid a parallel index scan operation.

Additional Hints

APPEND

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 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.

CACHE

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 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.

PUSH_PRED The PUSH_PRED hint forces pushing of a join predicate into the view.

NO_PUSH_PRED The NO_PUSH_PRED hint prevents pushing of a join predicate into the view.

PUSH_SUBQ

The PUSH_SUBQ hint causes nonmerged subqueries to be evaluated at the earliest possible place in the execution plan.

NO_PUSH_SUBQ

The NO_PUSH_SUBQ hint causes non-merged subqueries to be evaluated as the last step in the execution plan.

QB_NAME Specifies a name for a query block. (from Oracle 10g)

CURSOR_SHARING_EXACT 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 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.

DRIVING_SITE

The DRIVING_SITE hint forces query execution to be done for the table at a different site than that selected by Oracle

DYNAMIC_SAMPLING

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 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.

SPREAD_MIN_ANALYSIS

This hint omits some of the compile time optimizations of the rules, mainly detailed dependency graph analysis, on spreadsheets. Some optimizations such as creating filters to selectively populate spreadsheet access structures and limited rule pruning are still used. (from Oracle 10g)

Hints with unknown status

MERGE_AJ

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(table) where table specifies the name or alias of the table to be accessed.(depricated in Oracle 10g)

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. The syntax of the AND_EQUAL hint is AND_EQUAL(table index index) where table specifies the name or 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)

STAR

The STAR hint forces the large table to be joined last using a nested loops join on the index. The optimizer will consider different permutations of the small tables. (depricated in Oracle 10g)

BITMAP Usage: BITMAP(table_name index_name) Uses a bitmap index to access the table. (depricated ?)

HASH_SJ

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 sub-query is using a FILTER or NESTED LOOPS join. Try MERGE_AJ if HASH_AJ refuses to work.(depricated in Oracle 10g)

NL_SJ Use a Nested Loop in a sub-query. (depricated in Oracle 10g)

NL_AJ Use an anti-join in a sub-query. (depricated in Oracle 10g)

ORDERED_PREDICATES (depricated in Oracle 10g)EXPAND_GSET_TO_UNION (depricated in Oracle 10g)