19 Influencing the Optimizer

Optimizer defaults are adequate for most operations, but not all.

In some cases you may have information unknown to the optimizer, or need to tune the optimizer for a specific type of statement or workload. In such cases, influencing the optimizer may provide better performance.

This chapter contains the following topics:

19.1 Techniques for Influencing the Optimizer

You can influence the optimizer using several techniques, including SQL profiles, SQL Plan Management, initialization parameters, and hints.

The following figure shows the principal techniques for influencing the optimizer.

Figure 19-1 Techniques for Influencing the Optimizer

Description of Figure 19-1 follows
Description of "Figure 19-1 Techniques for Influencing the Optimizer"

The overlapping squares in the preceding diagram show that SQL plan management uses both initialization parameters and hints. SQL profiles also technically include hints.


A stored outline is a legacy technique that serve a similar purpose to SQL plan baselines.

You can use the following techniques to influence the optimizer:

Table 19-1 Optimizer Techniques

Technique Description To Learn More

Initialization parameters

Parameters influence many types of optimizer behavior at the database instance and session level.

"Influencing the Optimizer with Initialization Parameters"


A hint is a commented instruction in a SQL statement. Hints control a wide range of behavior.

"Influencing the Optimizer with Hints"


This package updates and manages optimizer statistics. The more accurate the statistics, the better the optimizer estimates. This chapter does not cover DBMS_STATS.

"Gathering Optimizer Statistics"

SQL profiles

A SQL profile is a database object that contains auxiliary statistics specific to a SQL statement. Conceptually, a SQL profile is to a SQL statement what a set of object-level statistics is to a table or index. A SQL profile can correct suboptimal optimizer estimates discovered during SQL tuning.

"Managing SQL Profiles"

SQL plan management and stored outlines

SQL plan management is a preventative mechanism that enables the optimizer to automatically manage execution plans, ensuring that the database uses only known or verified plans. This chapter does not cover SQL plan management.

"Managing SQL Plan Baselines"

In some cases, multiple techniques optimize the same behavior. For example, you can set optimizer goals using both initialization parameters and hints.

See Also:

"Migrating Stored Outlines to SQL Plan Baselines" to learn how to migrate stored outlines to SQL plan baselines

19.2 Influencing the Optimizer with Initialization Parameters

This chapter explains which initialization parameters affect optimization, and how to set them.

This section contains the following topics:

19.2.1 About Optimizer Initialization Parameters

Oracle Database provides initialization parameters to influence various aspects of optimizer behavior, including cursor sharing, adaptive optimization, and the optimizer mode.

The following table lists some of the most important optimizer parameters. Note that this table does not include the approximate query initialization parameters, which are described in "Approximate Query Initialization Parameters".

Table 19-2 Initialization Parameters That Control Optimizer Behavior

Initialization Parameter Description
CURSOR_INVALIDATION Provides the default cursor invalidation level for DDL statements.

IMMEDIATE sets the same cursor invalidation behavior for DDL as in releases before Oracle Database 12c Release 2 (12.2). This is the default.

DEFERRED allows an application to take advantage of the reduced cursor invalidation for DDL without making any application changes. Deferred invalidation reduces the number of cursor invalidations and spreads the recompilation workload over time. For this reason, a cursor may run with a suboptimal plan until it is recompiled, and may incur small execution-time overhead.

You can set this parameter at the SYSTEM or SESSION level. See "About the Life Cycle of Shared Cursors".


Converts literal values in SQL statements to bind variables. Converting the values improves cursor sharing and can affect the execution plans of SQL statements. The optimizer generates the execution plan based on the presence of the bind variables and not the actual literal values.

Set to FORCE to enable the creation of a new cursor when sharing an existing cursor, or when the cursor plan is not optimal. Set to EXACT to allow only statements with identical text to share the same cursor.


Specifies the number of blocks that are read in a single I/O during a full table scan or index fast full scan. The optimizer uses the value of this parameter to calculate the cost of full table scans and index fast full scans. Larger values result in a lower cost for full table scans, which may result in the optimizer choosing a full table scan over an index scan.

The default value of this parameter corresponds to the maximum I/O size that the database can perform efficiently. This value is platform-dependent and is 1 MB for most platforms. Because the parameter is expressed in blocks, it is set to a value equal to the maximum I/O size that can be performed efficiently divided by the standard block size. If the number of sessions is extremely large, then the multiblock read count value decreases to avoid the buffer cache getting flooded with too many table scan buffers.


Controls adaptive plans. An adaptive plan has alternative choices. The optimizer decides on a plan at run time based on statistics collected as the query executes.

By default, this parameter is true, which means adaptive plans are enabled. Setting to this parameter to false disables the following features:

  • Nested loops and hash join selection

  • Star transformation bitmap pruning

  • Adaptive parallel distribution method

See "About Adaptive Query Plans".


Controls the reporting mode for automatic reoptimization and adaptive plans (see "Adaptive Query Plans"). By default, reporting mode is off (false), which means that adaptive optimizations are enabled.

If set to true, then adaptive optimizations run in reporting-only mode. In this case, the database gathers information required for an adaptive optimization, but takes no action to change the plan. For example, an adaptive plan always choose the default plan, but the database collects information about which plan the database would use if the parameter were set to false. You can view the report by using DBMS_XPLAN.DISPLAY_CURSOR.


Controls adaptive statistics. The optimizer can use adaptive statistics when query predicates are too complex to rely on base table statistics alone.

By default, OPTIMIZER_ADAPTIVE_STATISTICS is false, which means that the following features are disabled:

  • SQL plan directives

  • Statistics feedback

  • Adaptive dynamic sampling

See "Adaptive Statistics".


Sets the optimizer mode at database instance startup. Possible values are ALL_ROWS, FIRST_ROWS_n, and FIRST_ROWS.


Controls the cost analysis of an index probe with a nested loop. The range of values 0 to 100 indicates percentage of index blocks in the buffer cache, which modifies optimizer assumptions about index caching for nested loops and IN-list iterators. A value of 100 infers that 100% of the index blocks are likely to be found in the buffer cache, so the optimizer adjusts the cost of an index probe or nested loop accordingly. Use caution when setting this parameter because execution plans can change in favor of index caching.


Adjusts the cost of index probes. The range of values is 1 to 10000. The default value is 100, which means that the optimizer evaluates indexes as an access path based on the normal cost model. A value of 10 means that the cost of an index access path is one-tenth the normal cost of an index access path.


This parameter enables (TRUE) or disables (FALSE) all Oracle Database In-Memory (Database In-Memory) optimizer features, including the cost model for the IM column store, table expansion, Bloom filters, and so on. Setting the parameter to FALSE causes the optimizer to ignore the INMEMORY property of tables during the optimization of SQL statements.


Enables or disables the use of invisible indexes.


Enables or disables the query rewrite feature of the optimizer.

TRUE, which is the default, enables the optimizer to utilize materialized views to enhance performance. FALSE disables the query rewrite feature of the optimizer and directs the optimizer not to rewrite queries using materialized views even when the estimated query cost of the unoptimized query is lower. FORCE enables the query rewrite feature of the optimizer and directs the optimizer to rewrite queries using materialized views even when the estimated query cost of the unoptimized query is lower.


Determines the degree to which query rewrite is enforced.

By default, the integrity level is set to ENFORCED. In this mode, all constraints must be validated. The database does not use query rewrite transformations that rely on unenforced constraints. Therefore, if you use ENABLE NOVALIDATE RELY, some types of query rewrite might not work.

To enable query rewrite when constraints are in NOVALIDATE mode, the integrity level must be TRUSTED or STALE_TOLERATED. In TRUSTED mode, the optimizer trusts that the relationships declared in dimensions and RELY constraints are correct. In STALE_TOLERATED mode, the optimizer uses materialized views that are valid but contain stale data as well as those that contain fresh data. This mode offers the maximum rewrite capability but creates the risk of generating inaccurate results.


Controls whether the database uses the SQL query result cache for all queries, or only for the queries that are annotated with the result cache hint. When set to MANUAL (the default), you must use the RESULT_CACHE hint to specify that a specific result is to be stored in the cache. When set to FORCE, the database stores all results in the cache.

When setting this parameter, consider how the result cache handles PL/SQL functions. The database invalidates query results in the result cache using the same mechanism that tracks data dependencies for PL/SQL functions, but otherwise permits caching of queries that contain PL/SQL functions. Because PL/SQL function result cache invalidation does not track all kinds of dependencies (such as on sequences, SYSDATE, SYS_CONTEXT, and package variables), indiscriminate use of the query result cache on queries calling such functions can result in changes to results, that is, incorrect results. Thus, consider correctness and performance when choosing to enable the result cache, especially when setting RESULT_CACHE_MODE to FORCE.


Changes the memory allocated to the result cache. If you set this parameter to 0, then the result cache is disabled. The value of this parameter is rounded to the largest multiple of 32 KB that is not greater than the specified value. If the rounded value is 0, then the feature is disabled.


Specifies the maximum amount of cache memory that any single result can use. The default value is 5%, but you can specify any percentage value between 1 and 100.


Specifies the number of minutes for which a result that depends on remote database objects remains valid. The default is 0, which implies that the database should not cache results using remote objects. Setting this parameter to a nonzero value can produce stale answers, such as if a remote database modifies a table that is referenced in a result.


Enables the optimizer to cost a star transformation for star queries (if true). The star transformation combines the bitmap indexes on the various fact table columns.

See Also:

19.2.2 Enabling Optimizer Features

The OPTIMIZER_FEATURES_ENABLE initialization parameter (or hint) controls a set of optimizer-related features, depending on the database release.

The parameter accepts one of a list of valid string values corresponding to the release numbers, such as or You can use this parameter to preserve the old behavior of the optimizer after a database upgrade. For example, if you upgrade Oracle Database 12c Release 1 ( to Oracle Database 12c Release 2 (, then the default value of the OPTIMIZER_FEATURES_ENABLE parameter changes from to

For backward compatibility, you may not want the execution plans to change because of new optimizer features in a new release. In such cases, you can set OPTIMIZER_FEATURES_ENABLE to an earlier version. If you upgrade to a new release, and if you want to enable the features in the new release, then you do not need to explicitly set the OPTIMIZER_FEATURES_ENABLE initialization parameter.


Oracle does not recommend explicitly setting the OPTIMIZER_FEATURES_ENABLE initialization parameter to an earlier release. To avoid SQL performance regression that may result from execution plan changes, consider using SQL plan management instead.


This tutorial assumes the following:

  • You recently upgraded the database from Oracle Database 12c Release 1 (12 1.0.2) to Oracle Database 12c Release 2 (

  • You want to preserve the optimizer behavior from the earlier release.

To enable query optimizer features for a specific release:

  1. Log in to the database with the appropriate privileges, and then query the current optimizer features settings.

    For example, run the following SQL*Plus command:

    SQL> SHOW PARAMETER optimizer_features_enable
    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- --------
    optimizer_features_enable            string
  2. Set the optimizer features setting at the instance or session level.

    For example, run the following SQL statement to set the optimizer version to


    The preceding statement restores the optimizer functionality that existed in Oracle Database 12c Release 1 (

See Also:

19.2.3 Choosing an Optimizer Goal

The optimizer goal is the prioritization of resource usage by the optimizer.

Using the OPTIMIZER_MODE initialization parameter, you can set the following optimizer goals:

  • Best throughput (default)

    When you set the OPTIMIZER_MODE value to ALL_ROWS, the database uses the least amount of resources necessary to process all rows that the statement accessed.

    For batch applications such as Oracle Reports, optimize for best throughput. Usually, throughput is more important in batch applications because the user is only concerned with the time necessary for the application to complete. Response time is less important because the user does not examine the results of individual statements while the application is running.

  • Best response time

    When you set the OPTIMIZER_MODE value to FIRST_ROWS_n, the database optimizes with a goal of best response time to return the first n rows, where n equals 1, 10, 100, or 1000.

    For interactive applications in Oracle Forms or SQL*Plus, optimize for response time. Usually, response time is important because the interactive user is waiting to see the first row or rows that the statement accessed.


This tutorial assumes the following:

  • The primary application is interactive, so you want to set the optimizer goal for the database instance to minimize response time.

  • For the current session only, you want to run a report and optimize for throughput.

To enable query optimizer features for a specific release:

  1. Connect SQL*Plus to the database with the appropriate privileges, and then query the current optimizer mode.

    For example, run the following SQL*Plus command:

    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- --------
    optimizer_mode                       string      ALL_ROWS
  2. At the instance level, optimize for response time.

    For example, run the following SQL statement to configure the system to retrieve the first 10 rows as quickly as possible:

  3. At the session level only, optimize for throughput before running a report.

    For example, run the following SQL statement to configure only this session to optimize for throughput:


See Also:

Oracle Database Reference to learn about the OPTIMIZER_MODE initialization parameter

19.2.4 Controlling Adaptive Optimization

In Oracle Database, adaptive query optimization is the process by which the optimizer adapts an execution plan based on statistics collected at run time.

Adaptive plans are enabled when the following initialization parameters are set:




If OPTIMIZER_ADAPTIVE_REPORTING_ONLY is set to true, then adaptive optimization runs in reporting-only mode. In this case, the database gathers information required for adaptive optimization, but does not change the plans. An adaptive plan always chooses the default plan, but the database collects information about the execution as if the parameter were set to false.

Adaptive statistics are enabled when the following initialization parameters are set:




This tutorial assumes the following:

  • The OPTIMIZER_FEATURES_ENABLE initialization parameter is set to or later.

  • The OPTIMIZER_ADAPTIVE_REPORTING_ONLY initialization parameter is set to false (default).

  • You want to disable adaptive plans for testing purposes so that the database generates only reports.

To disable adaptive plans:

  1. Connect SQL*Plus to the database as SYSTEM, and then query the current settings.

    For example, run the following SQL*Plus command:

    NAME                                 TYPE        VALUE
    ------------------------------------ ----------- -----
    optimizer_adaptive_reporting_only    boolean     FALSE
  2. At the session level, set the OPTIMIZER_ADAPTIVE_REPORTING_ONLY initialization parameter to true.

    For example, in SQL*Plus run the following SQL statement:

  3. Run a query.

  4. Run DBMS_XPLAN.DISPLAY_CURSOR with the +REPORT parameter.

    When the +REPORT parameter is set, the report shows the plan the optimizer would have picked if automatic reoptimization had been enabled.

See Also:

19.3 Influencing the Optimizer with Hints

Optimizer hints are special comments in a SQL statement that pass instructions to the optimizer.

The optimizer uses hints to choose an execution plan for the statement unless prevented by some condition.

This section contains the following topics:


Oracle Database SQL Language Reference contains a complete reference for all SQL hints

19.3.1 About Optimizer Hints

Use hints to influence the optimizer mode, query transformation, access path, join order, and join methods.

For example, The following figure shows how you can use a hint to tell the optimizer to use a specific index for a specific statement.

The advantage of hints is that they enable you to make decisions normally made by the optimizer. In a test environment, hints are useful for testing the performance of a specific access path. For example, you may know that an index is more selective for certain queries, as in Figure 19-2. In this case, the hint may cause the optimizer to generate a better plan.

The disadvantage of hints is the extra code that you must manage, check, and control. Hints were introduced in Oracle7, when users had little recourse if the optimizer generated suboptimal plans. Because changes in the database and host environment can make hints obsolete or have negative consequences, a good practice is to test using hints, but use other techniques to manage execution plans.

Oracle provides several tools, including SQL Tuning Advisor, SQL plan management, and SQL Performance Analyzer, to address performance problems not solved by the optimizer. Oracle strongly recommends that you use these tools instead of hints because they provide fresh solutions as the data and database environment change.

This section contains the following topics:

See Also:

Oracle Database SQL Language Reference for the most common hints by functional category. Types of Hints

You can use hints for tables, query blocks, and statements.

Hints fall into the following types:

  • Single-table

    Single-table hints are specified on one table or view. INDEX and USE_NL are examples of single-table hints. The following statement uses a single-table hint:

    SELECT /*+ INDEX (employees emp_department_ix)*/ employee_id, department_id
    FROM   employees 
    WHERE  department_id > 50;
  • Multitable

    Multitable hints are like single-table hints except that the hint can specify multiple tables or views. LEADING is an example of a multitable hint. The following statement uses a multitable hint:

    SELECT /*+ LEADING(e j) */ *
    FROM   employees e, departments d, job_history j
    WHERE  e.department_id = d.department_id
    AND    e.hire_date = j.start_date;


    USE_NL(table1 table2) is not considered a multitable hint because it is 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. The following statement uses a query block hint to specify that the FULL hint applies only to the query block that references employees:

    SELECT /*+ INDEX(t1) FULL(@sel$2 t1) */ COUNT(*)
    FROM   jobs t1
    WHERE t1.job_id IN (SELECT job_id FROM employees t1);
  • Statement

    Statement hints apply to the entire SQL statement. ALL_ROWS is an example of a statement hint. The following statement uses a statement hint:

    SELECT /*+ ALL_ROWS */ * FROM sales;

See Also:

Oracle Database SQL Language Reference for the most common hints by functional category. Scope of Hints

When you specify a hint in a statement block, the hint applies to the appropriate query block, table, or entire statement in the statement block. The hint overrides any instance-level or session-level parameters.

A statement block is one of the following:

  • A simple MERGE, SELECT, INSERT, UPDATE, or DELETE statement

  • A parent statement or a subquery of a complex statement

  • A part of a query using set operators (UNION, MINUS, INTERSECT)

Example 19-1 Query Using a Set Operator

The following query consists of two component queries and the UNION operator:

SELECT /*+ FIRST_ROWS(10) */ prod_id, time_id FROM 2010_sales
SELECT /*+ ALL_ROWS */ prod_id, time_id FROM current_year_sales;

The preceding statement has two blocks, one for each component query. Hints in the first component query apply only to its optimization, not to the optimization of the second component query. For example, in the first week of 2015 you query current year and last year sales. You apply FIRST_ROWS(10) to the query of last year's (2014) sales and the ALL_ROWS hint to the query of this year's (2015) sales.

See Also:

Oracle Database SQL Language Reference for an overview of hints Guidelines for Hints

You must enclose hints within a SQL comment.

The hint comment must immediately follow the first keyword of a SQL statement block. You can use either style of comment: a slash-star (/*) or pair of dashes (--). The plus-sign (+) hint delimiter must come immediately after the comment delimiter, as in the following fragment:

SELECT /*+ hint_text */ ...

The database ignores incorrectly specified hints. The database also ignores combinations of conflicting hints, even if these hints are correctly specified. If one hint is incorrectly specified, but a hint in the same comment is correctly specified, then the database considers the correct hint.


The database does not issue error messages for hints that it ignores.

A statement block can have only one comment containing hints, but it can contain many space-separated hints. For example, a complex query may include multiple table joins. If you specify only the INDEX hint for a specified table, then the optimizer must determine the remaining access paths and corresponding join methods. The optimizer may not use the INDEX hint because the join methods and access paths prevent it. Example 19-2 uses multiple hints to specify the exact join order.

Example 19-2 Multiple 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;

See Also:

Oracle Database SQL Language Reference to learn about the syntax rules for comments and hints

19.3.2 Guidelines for Join Order Hints

In some cases, you can specify join order hints in a SQL statement so that it does not access rows that have no effect on the result.

The driving table in a join is the table to which other tables are joined. In general, the driving table contains the filter condition that eliminates the highest percentage of rows in the table. The join order can have a significant effect on the performance of a SQL statement.

Consider the following guidelines:

  • Avoid a full table scan when an index retrieves the requested rows more efficiently.

  • Avoid using an index that fetches many rows from the driving table when you can use a different index that fetches a small number of rows.

  • Choose the join order so that you join fewer rows to tables later in the join order.

The following example shows how to tune join order effectively:

FROM   taba a, 
       tabb b, 
       tabc c
WHERE  a.acol BETWEEN   100 AND   200
AND    b.bcol BETWEEN 10000 AND 20000
AND    c.ccol BETWEEN 10000 AND 20000
AND    a.key1 = b.key1
AND    a.key2 = c.key2;
  1. Choose the driving table and the driving index (if any).

    Each of the first three conditions in the previous example is a filter condition that applies to a single table. The last two conditions are join conditions.

    Filter conditions dominate the choice of driving table and index. In general, the driving table contains the filter condition that eliminates the highest percentage of rows. Because the range of 100 to 200 is narrow compared with the range of acol, but the ranges of 10000 and 20000 are relatively large, taba is the driving table, all else being equal.

    With nested loops joins, the joins occur through the join indexes, which are the indexes on the primary or foreign keys used to connect that table to an earlier table in the join tree. Rarely do you use the indexes on the non-join conditions, except for the driving table. Thus, after taba is chosen as the driving table, use the indexes on b.key1 and c.key2 to drive into tabb and tabc, respectively.

  2. Choose the best join order, driving to the best unused filters earliest.

    You can reduce the work of the following join by first joining to the table with the best still-unused filter. Therefore, if bcol BETWEEN is more restrictive (rejects a higher percentage of the rows) than ccol BETWEEN, then the last join becomes easier (with fewer rows) if tabb is joined before tabc.

  3. You can use the ORDERED or STAR hint to force the join order.

See Also:

Oracle Database Reference to learn about OPTIMIZER_MODE