This post highlights the differences between SQL profile and baselines in Oracle® and explains how it works when tuning a query.
At a high level, these three elements work together as follows:
The query optimizer uses information like system statistics, bind variables, and compilations to get the best plan for query execution. However, sometimes input defects lead to a sub-optimal plan.
SQL profiles contain auxiliary information that mitigates this issue. They minimize these mistakes and help the optimizer select the best plan.
SQL plan baselines for SQL statements consist of a set of accepted plans. After parsing the statement, the optimizer selects the best plan from the set of accepted plans. If the cost optimizer finds another good plan, it adds the new plan to the plan history. However, the optimizer doesn’t use the new plan until it verifies that it will perform better than the currently accepted plan.
Think of it this way: SQL profiles give information to the optimizer to help select the best plan but don’t force the optimizer to select any specific plan. SQL plan baselines limit the optimizer plan selection to a set of accepted plans. If you want to consider cost-based plans, include them in the accepted baseline set of plans.
Use SQL profiles if you want the optimizer to use a least-cost plan and need to use the latest statistics. Use baselines when you want to use one of a specific set of plans. If SQL plan baselines can’t get the best plan from the accepted set, use the SQL profile instead.
SQL Plan Management (SPM) has the following components:
When you execute any statement, the system hard parses it and generates a cost plan according to the available SQL profile. After it selects a cost-based plan, it compares the plans available in the SQL plan baselines. If a cost-based generated plan matches one of the accepted plans, then you can use that plan. If the plan does not match, the system adds it to the plan baselines as an unaccepted plan.
When you execute the SQL statement with a baseline plan, it opts for the best plan for that SQL. The optimizer uses the same process. The available SQL profile also affects the estimated cost for each plan and selects a plan accordingly.
The last component of SPM is the evolution of unaccepted plans, which tests the unaccepted plans against the accepted plans. This process assesses the best plan considering time taken by a query and the CPU resources required. It accepts the best plan according to the cost of the query. If an SQL profile is available, then it affects the estimated cost.
The following table, from https://www.cnblogs.com/princessd8251/articles/3637461.html, compares SQL profiles and SQL plan baselines:
The following image shows SQL plan baseline architecture:
The following image shows two ways to load SQL plan baselines:
With the first method, you can set the OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES
initialization parameter to
TRUE to use automatic plan capture. This
initialization parameter is
FALSE by default, so set it to
TRUE as shown in
the following example:
With the second method, you can use the DBMS_SPM package to enable manually manage SQL plan baselines. Load the plans from an SQL tuning set as shown in the following example:
Use the following command to load the plan baseline manually:
After loading the SQL plan baseline, you need to execute SQL to see if the optimizer is using the SQL plan baseline. You can query the SQL plan baselines by using SQL_TEXT and the plan name as follows:
Run the following query to display SQL plan baselines:
To drop the SQL plan baseline, run the following query to check which SQL plan the optimizer is using:
Then, after you get the plan in use, run the following command to drop the baseline:
The SQL tunning advisor, which you trigger through Oracle Enterprise Manager (OEM) or by using a command-line query, can generate the SQL profile for an SQL statement. This profile includes additional information about the statement.
In this example, you first run SQL tuning advisor against the sql_id and then perform operations on the SQL profile:
Run the following SQL tuning advisor code for sql_id,
Run the following DBMS_SQLTUNE.report_tuning_task for recommendations:
Run the following code to accept the sql_profile:
Use the following query to check the sql_profile name:
Run the following code to disable the sql_profile:
To enable it, change the value from
Run the following code to drop the sql_profile:
When you execute any SQL statement, the optimizer creates an execution plan to parse the query, retrieve the data from the hard disk, and place it in memory. The SQL profile and baselines guide the optimizer to choose the least costly plan in terms of time and CPU cost. A good SQL plan efficiently runs a query and provides the desired results faster.
Use the Feedback tab to make any comments or ask questions. You can also start a conversation with us.