automatic sql tuning in oracle 11g.pdf

Oracle Database 11g: New Features for Administrators 12 - 1


SQL Tuning in Oracle Database 10gOracle Database 10g introduced SQL Tuning Advisor to help DBAs and application developers improve the performance of SQL statements. The advisor targets the problem of poorly written SQL, in which SQL statements have not been designed in the most efficient fashion. It also targets the (more common) problem in which a SQL statement is performing poorly because the optimizer generated a poor execution plan due to a lack of accurate and relevant data statistics. In all cases, the advisor makes specific suggestions for speeding up SQL performance, but it leaves the responsibility of implementing the recommendations to the user.In addition to SQL Tuning Advisor, Oracle Database 10g has an automated process to identify high-load SQL statements in your system. This is done by the Automatic Database Diagnostic Monitor (ADDM), which automatically identifies high-load SQL statements that are good candidates for tuning.However, major issues still remain: Although it is true that ADDM identifies some SQL that should be tuned, users must manually look at ADDM reports and run SQL Tuning Advisor on those reports for tuning.


Automatic SQL Tuning in Oracle Database 11gOracle Database 11g further automates the SQL Tuning process by identifying problematic SQL statements, running SQL Tuning Advisor on them, and implementing the resulting SQL profile recommendations to tune the statement without requiring user intervention. Automatic SQL Tuning uses the AUTOTASK framework through a new task called “Automatic SQL Tuning” that runs every night by default. Here is a brief description of the automated SQL tuning process in Oracle Database 11g:

• Step 1: Based on the AWR Top SQL identification (SQLs that were top in four different time periods: the past week, any day in the past week, any hour in the past week, or single response time), Automatic SQL Tuning targets statements for automatic tuning.

• Steps 2 and 3: While the Automatic SQL Tuning task is executing during the maintenance window, the previously identified SQL statements are automatically tuned by invoking SQL Tuning Advisor. As a result, SQL profiles will be created for them if needed. However, before making any decision, the new profile is carefully tested.

• Step 4: At any point in time, you can request a report about these automatic tuning activities. You then have the option of checking the tuned SQL statements to validate or remove the automatic SQL profiles that were generated.

The Oracle Tuning Pack includes the Automatic SQL Tuning feature.


Summary of Automation in Oracle Database 11gMore information is provided on these points in the lesson.


Selecting Potential SQL Statements for TuningOracle Database 11g analyzes the statistics in the AWR and generates a list of potential SQL statements that are eligible for tuning. These statements include repeating high-load statements that have a significant impact on the system. Only SQL statements that have an execution plan with a high potential for improvement will be tuned. Recursive SQL and statements that have been tuned recently (in the last month) are ignored, as are parallel queries, DMLs, DDLs, and SQL statements with performance problems that are caused by concurrency issues. The SQL statements that are selected as candidates are then ordered based on their performance impact. The performance impact of a SQL statement is calculated by summing the CPU time and the I/O times captured in the AWR for that SQL statement in the past week.


Maintenance Window TimelineThe Automatic SQL Tuning process takes place during the maintenance window. Furthermore, it runs as part of a single AUTOTASK job on a single instance to avoid concurrency issues. This is portrayed in the slide for one scenario.In this scenario, at some time after the beginning of the maintenance window, AUTOTASK starts the Automatic SQL Tuning job (SYS_AUTO_SQL_TUNING_TASK). The first thing that the job does is to generate a list of candidate SQL for tuning, according to the AWR source. When the list is complete, the job tunes each statement in order of importance, one after another, considering only one statement at a time. In this scenario, it first tunes S1, which has a SQL profile recommendation (P1) generated for it by SQL Tuning Advisor. After P1 has been successfully tested, it is accepted and the job moves on to the next statement, S2.By default, Automatic SQL Tuning runs for at most one hour during a maintenance window. You can change this setting by using a call similar to the following: DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER('SYS_AUTO_SQL_TUNING_TASK', 'TIME_LIMIT', 7200);

Note: The widths of boxes in the slide do not indicate relative execution times. Tuning and test execution should be the most expensive processes by far, with all the others completing relatively quickly.


Automatic Tuning ProcessWith the list of candidate SQL statements already built and ordered, the statements are then tuned using SQL Tuning Advisor. During the tuning process, all the recommendation types are considered and reported, but only SQL profiles can be implemented automatically (when the ACCEPT_SQL_PROFILES task parameter is set to TRUE). Otherwise, only the recommendation to create a SQL profile will be reported in the automatic SQL tuning reports. In Oracle Database 11g, the performance improvement factor has to be at least three before a SQL profile is implemented. As we have already mentioned, the Automatic SQL Tuning process implements only SQL profile recommendations automatically. Other recommendations (to create new indexes, refresh stale statistics, or restructure SQL statements) are generated as part of the SQL tuning process but are not implemented. These are left for the DBA to review and implement manually, as appropriate. Here is a short description of the general tuning process:Tuning is performed on a per-statement basis. Because only SQL profiles can be implemented, there is no need to consider the effect of such recommendations on the workload as a whole. For each statement (in order of importance), the tuning process carries out each of the following steps:

1. Tune the statement by using SQL Tuning Advisor. Look for a SQL profile and, if it is found, verify that the base optimizer statistics are current for it.


Automatic Tuning Process (continued)2. If a SQL profile is recommended, perform the following:

- Test the new SQL profile by executing the statement with and without it.- When a SQL profile is generated and it causes the optimizer to pick a different execution

plan for the statement, the advisor must decide whether to implement the SQL profile. It makes its decision as described on the flowchart in the slide. Although the benefit thresholds here apply to the sum of CPU and I/O time, SQL profiles are not accepted when there is degradation in either statistic. So the requirement is that there is a three-times improvement in the sum of CPU and I/O time, with neither statistic becoming worse. In this way, the statement runs faster than it would without the profile, even with contention in CPU or I/O.

3. If stale or missing statistics are found, make this information available to GATHER_STATS_JOB.

Automatic implementation of tuning recommendations is limited to SQL profiles because they have fewer risks. It is easy for a DBA to revert the implementation.Note: All SQL profiles are created in the standard EXACT mode. They are matched and tracked according to the current value of the CURSOR_SHARING parameter. DBAs are responsible for setting CURSOR_SHARING appropriately for their workload.


Controlling the Automatic SQL Tuning TaskYou can set parameters for the Automatic SQL Tuning task by using the DBMS_SQLTUNE.SET_TUNING_TASK_PARAMETER procedure. An example is presented on the next page.


Example: Controlling the Automatic SQL Tuning TaskHere is a PL/SQL control example for the Automatic SQL Tuning task:BEGINdbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'LOCAL_TIME_LIMIT', 1400);dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'ACCEPT_SQL_PROFILES', 'TRUE');dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_SQL_PROFILES_PER_EXEC', 50);dbms_sqltune.set_tuning_task_parameter('SYS_AUTO_SQL_TUNING_TASK', 'MAX_AUTO_SQL_PROFILES', 10002);END;The last three parameters in this example are supported only for the Automatic SQL Tuning task. You can also use parameters such as LOCAL_TIME_LIMIT, or TIME_LIMIT, which are valid parameters for the traditional SQL tuning tasks. One important example is to disable test-execute mode (to save time) and to use only execution plan costs to decide about the performance by using the TEST_EXECUTE parameter.In addition, you can control when the Automatic SQL Tuning task runs and the CPU resources that it is allowed to use.You can view the parameter values by querying DBA_ADVISOR_PARAMETERS.


Automatic SQL Tuning TaskAs has already been mentioned, Automatic SQL Tuning is implemented as an automated maintenance task that is itself called Automatic SQL Tuning. You can see some high-level information about the last runs of the Automatic SQL Tuning task by going to the Automated Maintenance Tasks page: On your Database Control home page, click the Server tab and, when you are on the Server page, click the Automated Maintenance Tasks link in the Tasks section.On the Automated Maintenance Tasks page, you see the predefined tasks. You then access each task by clicking the corresponding link to get more information about the task itself (illustrated in the slide). When you click either the Automatic SQL Tuning link or the latest execution icon (the green area on the timeline), you go to the Automatic SQL Tuning Result Summary page.


Configuring Automatic SQL TuningYou can configure various Automatic SQL Tuning parameters by using the Automatic SQL Tuning Settings page.To get to that page, click the Configure button on the Automated Maintenance Tasks page. This takes you to the Automated Maintenance Tasks Configuration page, where you can see the various maintenance windows that are delivered with Oracle Database 11g.By default, Automatic SQL Tuning executes on all predefined maintenance windows in the MAINTENANCE_WINDOW_GROUP. You can disable it for specific days in the week. On this page, you can also edit each Window to change its characteristics. You can do so by clicking Edit Window Group.To get to the Automatic SQL Tuning Settings page, click the Configure button on the line corresponding to Automatic SQL Tuning in the Task Settings section.On the Automatic SQL Tuning Settings page, you can specify the parameters shown in the slide. By default, “Automatic Implementation of SQL Profiles” is deactivated.Note: If you set STATISTICS_LEVEL to BASIC, turn off the AWR snapshots by using DBMS_WORKLOAD_REPOSITORY, or if AWR retention is less than seven days, you also stop Automatic SQL Tuning.


Automatic SQL Tuning Result SummaryIn addition, the Automatic SQL Tuning Result Summary page contains various summary graphs so that you can control the Automatic SQL Tuning task. An example is given in the slide. The first chart in the Overall Task Statistics section shows you the breakdown by finding types for the designated period of time. You can control the period of time for which you want the report to be generated by selecting a value from the Time Period list. In the example, Customized is used; it shows you the latest run. You can choose All to cover all executions of the task so far. Users can request it for any time period over the past month, since that is the amount of time for which the advisor persists its tuning history. You then generate the report by clicking View Report.On the “Breakdown by Finding Type” chart, you can clearly see that only SQL profiles can be implemented. Although many more profiles were recommended, not all of them were automatically implemented for the reasons that we already explained. Similarly, recommendations for index creation and other types are not implemented. However, the advisor keeps historical information about all the recommendations if you want to implement them later.In the Profile Effect Statistics section, you can see the Tuned SQL DB Time Benefit chart, which shows you the before-and-after DB Time for implemented profiles and other recommendations.


Answers: 1, 2, and 3


Automatic SQL Tuning: Fine TuneYou can use the DBMS_SQLTUNE PL/SQL package to control various aspects of SYS_AUTO_SQL_TUNING_TASK.

• SET_TUNING_TASK_PARAMETERS: The following parameters are supported for the automatic tuning task only:– ACCEPT_SQL_PROFILES: TRUE/FALSE whether the system should accept SQL profiles

automatically– REPLACE_USER_SQL_PROFILES: TRUE/FALSE whether the task should replace SQL

profiles created by the user– MAX_SQL_PROFILES_PER_EXEC: Maximum number of SQL profiles to create for each

run– MAX_AUTO_SQL_PROFILES: Maximum number of automatic SQL profiles allowed on

the system in total– EXECUTION_DAYS_TO_EXPIRE: Specifies the number of days to save the task history

in the advisor framework schema. By default, the task history is saved for 30 days before it expires.

• EXECUTE_TUNING_TASK function: Used to manually run a new execution of the task in the foreground (behaves in the same way that it runs in the background)

• REPORT_AUTO_TUNING_TASK: Get a text report covering a range of task executions


Automatic SQL Tuning: Fine Tune (continued)You can enable and disable SYS_AUTO_SQL_TUNING_TASK by using the DBMS_AUTO_TASK_ADMIN PL/SQL package.You can also access Automatic SQL Tuning information through the dictionary views listed in the slide:• DBA_ADVISOR_EXECUTIONS: Get data about each execution of the task• DBA_ADVISOR_SQLSTATS: See the test-execute statistics generated while testing the SQL

profiles• DBA_ADVISOR_SQLPLANS: See the plans encountered during test-execute


Using the PL/SQL Interface to Generate ReportsThe example in the slide shows how to generate a text report to display all SQL statements that were analyzed in the most recent execution, including recommendations that were not implemented. All sections of the report are included.Depending on the sections that were included in the report, you can view information about the automatic SQL tuning task in the following sections of the report:

• The general information section provides a high-level description of the automatic SQL tuning task, including information about the inputs given for the report, the number of SQL statements tuned during the maintenance, and the number of SQL profiles that were created.

• The summary section lists the SQL statements (by their SQL identifiers) that were tuned during the maintenance window and the estimated benefit of each SQL profile, or their actual execution statistics after test-executing the SQL statement with the SQL profile.

• The Tuning findings section gives you all findings and statistics that are associated with each SQL statement, as well as whether profiles were accepted (and why).

• The Explain plans section shows the old and new explain plans used by each SQL statement analyzed by SQL Tuning Advisor.

• The Errors section lists all errors encountered by the Automatic SQL Tuning task.Note: Obtain the execution list by using the following command:

select execution_name,status,execution_start,execution_endfrom dba_advisor_executionswhere task_name='SYS_AUTO_SQL_TUNING_TASK';


Automatic SQL Tuning ConsiderationsAutomatic SQL Tuning does not seek to solve every SQL performance issue occurring on a system. It does not consider the following types of SQL.

• Ad hoc or rarely repeated SQL: If a SQL is not executed multiple times in the same form, the advisor ignores it. SQL that do not repeat within a week are also not considered.

• Parallel queries.• Long-running queries (post-profile): If a query takes too long to run after being SQL profiled, it

is not practical to test-execute and, therefore, it is ignored by the advisor. Note that this does not mean that the advisor ignores all long-running queries. If the advisor can find a SQL profile that causes a query that once took hours to run in minutes, it could be accepted because test-execution is still possible. The advisor would execute the old plan just long enough to determine that it is worse than the new one, and then would terminate test-execution without waiting for the old plan to finish, thereby switching the order of execution.

• Recursive SQL statements. (Additional statements issued by the Oracle server which are needed to execute a SQL statement issued by a user.)

• DMLs such as INSERT SELECT or CREATE TABLE AS SELECTWith the exception of truly ad hoc SQL, these limitations apply to Automatic SQL Tuning only. Such statements can still be tuned by manually running SQL Tuning Advisor.

automatic sql tuning in oracle 11g.pdf

Documents

sql tuning advisor

sql performance

written sql

automatic sql tuning

automatic sql tuning

tuned sql statements

performance of sql statements

automatic sql profiles