Professional Documents
Culture Documents
htm
Previous Next
SQL Profiles
See Also:
Oracle Database 2 Day DBA for information on monitoring and tuning SQL statements
Normal mode
Tuning mode
In normal mode, the optimizer compiles the SQL and generates an execution plan. The normal mode of the optimizer generates a
reasonable execution plan for the vast majority of SQL statements. Under normal mode the optimizer operates with very strict time
constraints, usually a fraction of a second, during which it must find a good execution plan.
In tuning mode, the optimizer performs additional analysis to check whether the execution plan produced under normal mode can be
further improved. The output of the query optimizer is not an execution plan, but a series of actions, along with their rationale and
expected benefit for producing a significantly superior plan. When called under the tuning mode, the optimizer is referred to as the
Automatic Tuning Optimizer. The tuning performed by the Automatic Tuning Optimizer is called Automatic SQL Tuning.
Under tuning mode, the optimizer can take several minutes to tune a single statement. It is both time and resource intensive to
invoke the Automatic Tuning Optimizer every time a query has to be hard-parsed. The Automatic Tuning Optimizer is meant to be
used for complex and high-load SQL statements that have non-trivial impact on the entire system. The Automatic Database
Diagnostic Monitor (ADDM) proactively identifies high-load SQL statements which are good candidates for Automatic SQL Tuning. See
Chapter 6, "Automatic Performance Diagnostics".
Statistics Analysis
SQL Profiling
1 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
The query optimizer relies on object statistics to generate execution plans. If these statistics are stale or missing, the optimizer does
not have the necessary information it needs and can generate poor execution plans. The Automatic Tuning Optimizer checks each
query object for missing or stale statistics, and produces two types of output:
Because optimizer statistics are automatically collected and refreshed, this problem may be encountered only when automatic
optimizer statistics collection has been turned off. See "Automatic Statistics Gathering".
Auxiliary information in the form of statistics for objects with no statistics, and statistic adjustment factor for objects with stale
statistics.
The query optimizer can sometimes produce inaccurate estimates about an attribute of a statement due to lack of information,
leading to poor execution plans. Traditionally, users have corrected this problem by manually adding hints to the application code to
guide the optimizer into making correct decisions. For packaged applications, changing application code is not an option and the only
alternative available is to log a bug with the application vendor and wait for a fix.
Automatic SQL Tuning deals with this problem with its SQL Profiling capability. The Automatic Tuning Optimizer creates a profile of
the SQL statement called a SQL Profile, consisting of auxiliary statistics specific to that statement. The query optimizer under normal
mode makes estimates about cardinality, selectivity, and cost that can sometimes be off by a significant amount resulting in poor
execution plans. SQL Profile addresses this problem by collecting additional information using sampling and partial execution
techniques to verify and, if necessary, adjust these estimates.
During SQL Profiling, the Automatic Tuning Optimizer also uses execution history information of the SQL statement to appropriately
set optimizer parameter settings, such as changing the OPTIMIZER_MODE initialization parameter setting from ALL_ROWS to
FIRST_ROWS for that SQL statement.
The output of this type of analysis is a recommendation to accept the SQL Profile. A SQL Profile, once accepted, is stored persistently
in the data dictionary. Note that the SQL Profile is specific to a particular query. If accepted, the optimizer under normal mode uses
the information in the SQL Profile in conjunction with regular database statistics when generating an execution plan. The availability
of the additional information makes it possible to produce well-tuned plans for corresponding SQL statement without requiring any
change to the application code.
The scope of a SQL Profile can be controlled by the CATEGORY profile attribute. This attribute determines which user sessions can
apply the profile. You can view the CATEGORY attribute for a SQL Profile in CATEGORY column of the DBA_SQL_PROFILES view. By
default, all profiles are created in the DEFAULT category. This means that all user sessions where the SQLTUNE_CATEGORY
initialization parameter is set to DEFAULT can use the profile.
By altering the category of a SQL profile, you can determine which sessions are affected by the creation of a profile. For example, by
setting the category of a SQL Profile to DEV, only those users sessions where the SQLTUNE_CATEGORY initialization parameter is set to
DEV can use the profile. All other sessions do not have access to the SQL Profile and execution plans for SQL statements are not
impacted by the SQL profile. This technique enables you to test a SQL Profile in a restricted environment before making it available
to other user sessions.
See Also:
Oracle Database Reference for information on the SQLTUNE_CATEGORY initialization parameter
It is important to note that the SQL Profile does not freeze the execution plan of a SQL statement, as done by stored outlines. As
tables grow or indexes are created or dropped, the execution plan can change with the same SQL Profile. The information stored in it
continues to be relevant even as the data distribution or access path of the corresponding statement change. However, over a long
period of time, its content can become outdated and would have to be regenerated. This can be done by running Automatic SQL
Tuning again on the same statement to regenerate the SQL Profile.
SELECT statements
UPDATE statements
DELETE statements
2 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
A complete set of functions are provided for management of SQL Profiles. See "SQL Profiles".
Indexes can tremendously enhance performance of a SQL statement by reducing the need for full table scans on large tables.
Effective indexing is a common tuning technique. The Automatic Tuning Optimizer also explores whether a new index can significantly
enhance the performance of a query. If such an index is identified, it recommends its creation.
Because the Automatic Tuning Optimizer does not analyze how its index recommendation can affect the entire SQL workload, it also
recommends running a the SQLAccess Advisor utility on the SQL statement along with a representative SQL workload. The
SQLAccess Advisor looks at the impact of creating an index on the entire SQL workload before making any recommendations. See
"Automatic SQL Tuning Features".
The Automatic Tuning Optimizer identifies common problems with structure of SQL statements than can lead to poor performance.
These could be syntactic, semantic, or design problems with the statement. In each of these cases the Automatic Tuning Optimizer
makes relevant suggestions to restructure the SQL statements. The alternative suggested is similar, but not equivalent, to the original
statement.
For example, the optimizer may suggest to replace UNION operator with UNION ALL or to replace NOT IN with NOT EXISTS. An
application developer can then determine if the advice is applicable to their situation or not. For instance, if the schema design is
such that there is no possibility of producing duplicates, then the UNION ALL operator is much more efficient than the UNION operator.
These changes require a good understanding of the data properties and should be implemented only after careful consideration.
The SQL Tuning Advisor input can be a single SQL statement or a set of statements. For tuning multiple statements, a SQL Tuning
Set (STS) has to be first created. An STS is a database object that stores SQL statements along with their execution context. An STS
can be created manually using command line APIs or automatically using Oracle Enterprise Manager. See "SQL Tuning Sets".
This section cover the following topics related to the SQL Tuning Advisor:
Input Sources
Tuning Options
Advisor Output
The primary input source is the Automatic Database Diagnostic Monitor (ADDM). By default, ADDM runs proactively once every
hour and analyzes key statistics gathered by the Automatic Workload Repository (AWR) over the last hour to identify any
performance problems including high-load SQL statements. If a high-load SQL is identified, ADDM recommends running SQL
Tuning Advisor on the SQL. See "Automatic Database Diagnostic Monitor".
The second most important input source is the high-load SQL statements captured in Automatic Workload Repository (AWR).
The AWR takes regular snapshots of the system activity including high-load SQL statements ranked by relevant statistics, such
as CPU consumption and wait time. A user can view the AWR and identify the high-load SQL of interest and run SQL Tuning
Advisor on them. By default, the AWR retains data for the last seven days. This means that any high-load SQL that ran within
the retention period of the AWR can be located and tuned using this feature. See "Overview of the Automatic Workload
Repository".
Cursor cache
3 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
The third likely source of input is the cursor cache. This source is used for tuning recent SQL statements that are yet to be
captured in the AWR. The cursor cache and AWR together provide the capability to identify and tune high-load SQL statements
from the current time going as far back as the AWR retention allows, which by default is at least 7 days.
Another possible input source for the SQL Tuning Advisor is the SQL Tuning Set. A SQL Tuning Set (STS) is a database object
that stores SQL statements along with their execution context. An STS can include SQL statements that are yet to be deployed,
with the goal of measuring their individual performance, or identifying the ones whose performance falls short of expectation.
When a set of SQL statements are used as input, a SQL Tuning Set (STS) has to be first constructed and stored. See "SQL
Tuning Sets".
If the limited option is chosen, the SQL Tuning Advisor produces recommendations based on statistics checks, access path
analysis, and SQL structure analysis. SQL Profile recommendations are not generated.
If the comprehensive option is selected, the SQL Tuning Advisor carries out all the analysis it performs under limited scope plus
SQL Profiling. With the comprehensive option you can also specify a time limit for the tuning task, which by default is 30
minutes.
See Also:
Oracle Database PL/SQL Packages and Types Reference for information on the security model for the
DBMS_SQLTUNE package
A SQL tuning task can be created for a single SQL statement. For tuning multiple statements, a SQL Tuning Set (STS) has to be first
created. An STS is a database object that stores SQL statements along with their execution context. An STS can be created manually
using command line APIs or automatically using Oracle Enterprise Manager. See "SQL Tuning Sets".
Figure 12-1 shows the steps involved when running the SQL Tuning Advisor using the DBMS_SQLTUNE package.
4 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
See Also:
Oracle Database PL/SQL Packages and Types Reference for detailed information on the DBMS_SQLTUNE
package
You can create tuning tasks from the text of a single SQL statement, a SQL Tuning Set containing multiple statements, a SQL
statement selected by SQL identifier from the cursor cache, or a SQL statement selected by SQL identifier from the Automatic
Workload Repository.
For example, to use the SQL Tuning Advisor to optimize a specified SQL statement text, you need to create a tuning task with the
SQL statement passed as a CLOB argument. For the following PL/SQL code, the user HR has been granted the ADVISOR privilege and
the function is run as user HR on the employees table in the HR schema.
DECLARE
my_task_name VARCHAR2(30);
my_sqltext CLOB;
BEGIN
my_sqltext := 'SELECT /*+ ORDERED */ * ' ||
'FROM employees e, locations l, departments d ' ||
'WHERE e.department_id = d.department_id AND ' ||
'l.location_id = d.location_id AND ' ||
'e.employee_id < :bnd';
my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
sql_text => my_sqltext,
bind_list => sql_binds(anydata.ConvertNumber(100)),
user_name => 'HR',
scope => 'COMPREHENSIVE',
time_limit => 60,
task_name => 'my_sql_tuning_task',
description => 'Task to tune a query on a specified employee');
END;
/
In this example, 100 is the value for bind variable :bnd passed as function argument of type SQL_BINDS, HR is the user under which
the CREATE_TUNING_TASK function analyzes the SQL statement, the scope is set to COMPREHENSIVE which means that the advisor
also performs SQL Profiling analysis, and 60 is the maximum time in seconds that the function can run. In addition, values for task
name and description are provided.
5 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
The CREATE_TUNING_TASK function returns the task name that you have provided or generates a unique task name. You can use the
task name to specify this task when using other APIs. To view the task names associated with a specific owner, you can run the
following:
After you have created a tuning task, you need to execute the task and start the tuning process. For example:
BEGIN
DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'my_sql_tuning_task' );
END;
/
You can check the status of the task by reviewing the information in the USER_ADVISOR_TASKS view or check execution progress of
the task in the V$SESSION_LONGOPS view. For example:
You can check the execution progress of the SQL Tuning Advisor in the V$ADVISOR_PROGRESS view. For example:
SELECT sofar, totalwork FROM V$ADVISOR_PROGRESS WHERE user_name = 'HR' AND task_name = 'my_sql_tuning_task';
See Also:
Oracle Database Reference for information on the V$ADVISOR_PROGRESS view
After a task has been executed, you display a report of the results with the REPORT_TUNING_TASK function. For example:
The report contains all the findings and recommendations of Automatic SQL Tuning. For each proposed recommendation, the
rationale and benefit is provided along with the SQL commands needed to implement the recommendation.
Additional information about tuning tasks and results can be found in DBA views. See "SQL Tuning Information Views".
You can use the following APIs for managing SQL tuning tasks:
INTERRUPT_TUNING_TASK to interrupt a task while executing, causing a normal exit with intermediate results
CANCEL_TUNING_TASK to cancel a task while executing, removing all results from the task
RESET_TUNING_TASK to reset a task while executing, removing all results from the task and returning the task to its initial state
DROP_TUNING_TASK to drop a task, removing all results associated with the task
Associated execution context, such as user schema, application module name and action, list of bind values, and the cursor
compilation environment
6 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
Associated basic execution statistics, such as elapsed time, CPU time, buffer gets, disk reads, rows processed, cursor fetches,
the number of executions, the number of complete executions, optimizer cost, and the command type
Associated execution plans and row source statistics for each SQL statement (optional)
SQL statements can be filtered using the application module name and action, or any of the execution statistics. In addition, the SQL
statements can be ranked based on any combination of execution statistics.
A SQL Tuning Set can be used as input to the SQL Tuning Advisor, which performs automatic tuning of the SQL statements based on
other input parameters specified by the user. SQL Tuning Sets are transportable across databases and can be exported from one
system to another, allowing for the transfer of SQL workloads between databases for remote performance diagnostics and tuning.
When poorly performing SQL statements are encountered on a production system, it may not be desirable for developers to perform
their investigation and tuning activities on the production system directly. This feature allows the DBA to transport the offending SQL
statements to a test system where the developers can safely analyze and tune them. To transport SQL Tuning Sets, use the
DBMS_SQLTUNE package procedures.
The recommended interface for managing SQL tuning sets is the Oracle Enterprise Manager. Whenever possible, you should manage
SQL tuning sets using Oracle Enterprise Manager, as described in the Oracle Database 2 Day + Performance Tuning Guide. If Oracle
Enterprise Manager is unavailable, you can manage SQL tuning sets using the DBMS_SQLTUNE package procedures. Typically you
would use the STS operations in the following sequence:
To use the APIs, you need the ADMINISTER SQL TUNING SET system privilege to manage SQL Tuning Sets that you own, or the
ADMINISTER ANY SQL TUNING SET system privilege to manage any SQL Tuning Sets.
Figure 12-2 shows the steps involved when using SQL Tuning Sets APIs.
See Also:
7 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
Oracle Database PL/SQL Packages and Types Reference for detailed information on the DBMS_SQLTUNE
package
BEGIN
DBMS_SQLTUNE.CREATE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
description => 'I/O intensive workload');
END;
/
where my_sql_tuning_set is the name of the STS in the database and 'I/O intensive workload' is the description assigned to
the STS.
In the following example, procedure calls are used to load my_sql_tuning_set from an AWR baseline called peak baseline. The
data has been filtered to select only the top 30 SQL statements ordered by elapsed time. First a ref cursor is opened to select from
the specified baseline. Next the statements and their statistics are loaded from the baseline into the STS.
DECLARE
baseline_cursor DBMS_SQLTUNE.SQLSET_CURSOR;
BEGIN
OPEN baseline_cursor FOR
SELECT VALUE(p)
FROM TABLE (DBMS_SQLTUNE.SELECT_WORKLOAD_REPOSITORY(
'peak baseline',
NULL, NULL,
'elapsed_time',
NULL, NULL, NULL,
30)) p;
DBMS_SQLTUNE.LOAD_SQLSET(
sqlset_name => 'my_sql_tuning_set',
populate_cursor => baseline_cursor);
END;
/
The SELECT_SQLSET table function reads the contents of the STS. After an STS has been created and populated, you can browse the
SQL in the STS using different filtering criteria. The SELECT_SQLSET procedure is provided for this purpose.
In the following example, the SQL statements in the STS are displayed for statements with a disk-reads to buffer-gets ratio greater
than or equal to 75%.
Additional details of the SQL Tuning Sets that have been created and loaded can also be displayed with DBA views, such as
DBA_SQLSET, DBA_SQLSET_STATEMENTS, and DBA_SQLSET_BINDS.
BEGIN
DBMS_SQLTUNE.DELETE_SQLSET(
sqlset_name => 'my_sql_tuning_set',
basic_filter => 'executions < 50');
END;
/
8 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
1. Use the CREATE_STGTAB_SQLSET procedure to create a staging table where the SQL Tuning Sets will be exported.
The following example shows how to create a staging table named staging_table.
BEGIN
DBMS_SQLTUNE.CREATE_STGTAB_SQLSET( table_name => 'staging_table' );
END;
/
2. Use the PACK_STGTAB_SQLSET procedure to export SQL Tuning Sets into the staging table.
The following example shows how to export a SQL Tuning Set named my_sts to the staging table.
BEGIN
DBMS_SQLTUNE.PACK_STGTAB_SQLSET(
sqlset_name => 'my_sts',
staging_table_name => 'staging_table');
END;
/
3. Move the staging table to the system where the SQL Tuning Sets will be imported using the mechanism of choice (such as
datapump or database link).
4. On the system where the SQL Tuning Sets will be imported, use the UNPACK_STGTAB_SQLSET procedure to import SQL Tuning
Sets from the staging table.
The following example shows how to import SQL Tuning Sets contained in the staging table.
BEGIN
DBMS_SQLTUNE.UNPACK_STGTAB_SQLSET(
sqlset_name => '%',
replace => TRUE,
staging_table_name => 'staging_table');
END;
/
BEGIN
DBMS_SQLTUNE.DROP_SQLSET( sqlset_name => 'my_sql_tuning_set' );
END;
/
The UPDATE_SQLSET procedure updates the attributes of SQL statements (such as PRIORITY or OTHER) in an existing STS
identified by STS name and SQL identifier.
The CAPTURE_CURSOR_CACHE_SQLSET function enables the capture of the full system workload by repeatedly polling the cursor
cache over a specified interval. This function is a lot more efficient than repeatedly using the SELECT_CURSOR_CACHE and
LOAD_SQLSET procedures to capture the cursor cache over an extended period of time. This function effectively captures the
entire workload, as opposed to the AWR—which only captures the workload of high-load SQL statements—or the LOAD_SQLSET
procedure, which accesses the data source only once.
The ADD_SQLSET_REFERENCE function adds a new reference to an existing STS to indicate its use by a client. The function
returns the identifier of the added reference. The REMOVE_SQLSET_REFERENCE procedure is used to deactivate an STS to
indicate it is no longer used by the client.
9 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
Figure 12-3 shows the steps involved when using SQL Profiles APIs.
See Also:
Oracle Database PL/SQL Packages and Types Reference for detailed information on the DBMS_SQLTUNE
package
DECLARE
my_sqlprofile_name VARCHAR2(30);
BEGIN
my_sqlprofile_name := DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
task_name => 'my_sql_tuning_task',
name => 'my_sql_profile',)
force_match => TRUE);
END;
In this example, my_sql_tuning_task is the name of the SQL tuning task and my_sql_profile is the name of the SQL Profile that
you want to accept.
Typically, an accepted SQL Profile is associated with the SQL statement through a special SQL signature that is generated using a
hash function. This hash function normalizes the SQL statement for case (changes the entire SQL statement to upper case) and white
spaces (removes all extra whites spaces) before generating the signature. The same SQL Profile thus will work for all SQL
statements that are essentially the same, where the only difference is in case usage and white spaces. However, by setting
force_match to true, the SQL Profile will additionally target all SQL statements that have the same text after normalizing literal
values to bind variables. This may be useful for applications that use literal values rather than bind variables, since this will allow SQL
with text differing only in its literal values to share a SQL Profile. If both literal values and bind variables are used in the SQL text, or
if this parameter is set to false (the default value), literal values will not be normalized.
You can view information about a SQL Profile in the DBA_SQL_PROFILES view.
You can alter the STATUS, NAME, DESCRIPTION, CATEGORY and FORCE_MATCH attributes of an existing SQL Profile with the
ALTER_SQL_PROFILE procedure. For example:
BEGIN
DBMS_SQLTUNE.ALTER_SQL_PROFILE(
name => 'my_sql_profile',
attribute_name => 'STATUS',
value => 'DISABLED');
END;
/
10 of 11 5/22/2013 9:08 PM
Automatic SQL Tuning http://docs.oracle.com/cd/B19306_01/server.102/b14211/sql_tune.htm
In this example, my_sql_profile is the name of the SQL Profile that you want to alter. The status attribute is changed to disabled
which means the SQL Profile is not used during SQL compilation.
BEGIN
DBMS_SQLTUNE.DROP_SQL_PROFILE(name => 'my_sql_profile');
END;
/
In this example, my_sql_profile is the name of the SQL Profile you want to drop. You can also specify whether to ignore errors
raised if the name does not exist. For this example, the default value of FALSE is accepted.
SQL tuning information views, such as DBA_SQLTUNE_STATISTICS, DBA_SQLTUNE_BINDS, and DBA_SQLTUNE_PLANS views.
SQL Tuning Set views, such as DBA_SQLSET, DBA_SQLSET_BINDS, DBA_SQLSET_STATEMENTS, and DBA_SQLSET_REFERENCES
views.
Information on captured execution plans for statements in SQL Tuning Sets are displayed in the DBA_SQLSET_PLANS and
USER_SQLSET_PLANS views.
Dynamic views containing information relevant to the SQL tuning, such as V$SQL, V$SQLAREA, V$SQLSTATS, and V$SQL_BINDS
views.
See Also:
Oracle Database Reference for information on static data dictionary and dynamic views
Copyright © 2000,
Previous Next Home Book Contents Index Master Contact
2008, Oracle. All rights reserved.
Legal Notices List Index Us
11 of 11 5/22/2013 9:08 PM