Shulou(Shulou.com)06/01 Report--

I wrote a blog about using SQL Profile to adjust and stabilize the execution plan of the target SQL, even if the SQL text of the target SQL cannot be modified. But in fact, SQL Profile is only a kind of passive technical means, which is applied to those SQL whose implementation plans have been changed badly, that is, when we find that there is something wrong with the implementation plans of these SQL, we create SQL Profile to correct and stabilize the implementation plans of these SQL. Even if the problem of the target SQL execution plan change is solved by creating the SQL Profile, there is still no guarantee that the subsequent execution plan of the SQL will not have a bad change. This uncertainty can cause a series of problems for large version upgrades of Oracle databases (such as upgrading from Oracle 10g to Oracle 11g) because it is not clear which SQL in the original system will have a bad implementation plan after the upgrade.

To solve the above problems, Oracle introduced SPM (SQL Plan Management) in 11g. SPM is an active and stable execution plan, which can guarantee that only the verified execution plan will be enabled. When a new execution plan is generated by the target SQL due to various reasons (such as changes in statistics), the new execution plan will not be enabled immediately, until it has been verified that its execution efficiency will be higher than the original execution plan.

With the continuous development of the version of Oracle database, the algorithms and functions of CBO are constantly evolving and increasing, so the same SQL may be more efficient in the new version of Oralce database. If we use SQL Profile (especially the SQL Profile of Manual type) to stabilize the execution plan of the target SQL, it means that we may lose the opportunity to continue to optimize the execution efficiency of the above SQL. The launch of SPM can be said to completely solve the problem of the stability of the implementation plan, it can not only take the initiative to stabilize the implementation plan, but also retain the opportunity to continue to use the new execution plan which may be more efficient.

When SPM is enabled, there is a corresponding SQL Plan Baseline for each SQL. What is stored in this SQL Plan Baseline is the execution plan of the SQL. If a SQL has multiple execution plans, then the SQL may have multiple SQL Plan Baseline. You can view all the SQL Plan Baseline of the target SQL from the DBA_SQL_PLAN_BASELINES.

The columns ENABLED and ACCEPTED in DBA_SQL_PLAN_BASELINES are used to describe whether the execution plan corresponding to a SQL Plan Baseline can be enabled by Oracle. Only the execution plan corresponding to SQL Plan Baseline with the value of "YES" of both ENABLED and ACCEPTED will be enabled by Oracle. If a SQL has more than one SQL Plan Baseline with ENABLED and ACCEPTED values of YES, then Oracle will select the execution plan corresponding to the one with the lowest cost as the execution plan of the SQL.

In Oracle 11g and above, there are two ways to generate the SQL Plan Baseline of the target SQL.

Automatic capture

Manual generation / batch import (batch import is especially suitable for upgrading large versions of Oracle databases, which ensures that the execution plan of Hu SQL in the original system will not change after the upgrade)

The following describes how to automatically capture and manually generate SQL Plan Baseline.

1 automatically capture SQL Plan Baseline

The parameter OPTIMIZER_CAPTURE_SQL_PLAN_BASELINES is used to control whether automatic capture of SQL Plan Baseline is enabled. Its default value is FALSE, which means that Oracle does not automatically capture SQL Plan Baseline by default. This parameter can be dynamically modified at the session or system level. When modified to TRUE, Oracle automatically captures its SQL Plan Baseline for all repeated SQL within the scope of the above parameters, and the values of ENABLED and ACCEPTED of the SQL Plan Baseline captured for the first time for the target SQL are both "YES". Subsequently, if the execution plan of the SQL is changed, the value of the ENABLED of the SQL Plan Baseline captured again is still YES, but the value of the ACCEPTED becomes NO, which means that although the execution plan of the subsequent change is captured, the Oracle will not execute it as the execution plan of the SQL, that is, the Oracle will always use the execution plan corresponding to the SQL Plan Baseline that the SQL was captured for the first time (unless manually adjusted later).

The parameter OPTIMIZER_USE_SQL_PLAN_BASELINES is used to control whether SQL Plan Baseline is enabled, and its default value is TRUE, which means that by default, Oracle will enable SPM when generating the execution plan, using the existing SQL Plan Baseline, and this parameter can also be dynamically modified at the session or system level.

Take a look at an example:

View the default values of the above two parameters

Zx@MYDB > show parameter sql_planNAME TYPE VALUE -optimizer_capture_sql_plan_baselines boolean FALSEoptimizer_use_sql_plan_baselines boolean TRUE

Disable SPM in the current session and enable automatic capture of SQL Plan Baseline:

Zx@MYDB > alter session set optimizer_use_sql_plan_baselines=FALSE;Session altered.zx@MYDB > alter session set optimizer_capture_sql_plan_baselines=TRUE;Session altered.

Create test table T2

Zx@MYDB > create table T2 as select * from dba_objects;Table created.zx@MYDB > create index idx_t2 on T2 (object_id); Index created.zx@MYDB > exec dbms_stats.gather_table_stats (ownname= > USER,tabname= >'T2 parallel PL/SQL procedure successfully completed.zx@MYDB and 108); PL/SQL procedure successfully completed.zx@MYDB > select object_id,object_name from T2 where object_id between 103 and 108 OBJECT_ID OBJECT_NAME--103MIGRATE$ 104DEPENDENCY$ 105ACCESS$ 106I_DEPENDENCY1 107I_DEPENDENCY2 108I_ACCESS16 rows selected.

From the point of view of the execution plan, the index range scan on the index IDX_T2 is taken, and because SQL is only executed once, Oracle does not automatically capture the absence of records in SQL Plan Baseline,DBA_SQL_PLAN_BASELINES

Zx@MYDB > col sql_handle for a30zx@MYDB > col plan_name for a30zx@MYDB > col origin for a20zx@MYDB > col sql_text for a70zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines;no rows selected

Execute the above SQL again, because repeated execution of the SQL,Oracle automatically captures the SQL Plan Baseline of this SQL

Zx@MYDB > select object_id,object_name from T2 where object_id between 103 and 108 OBJECT_ID OBJECT_NAME--103 MIGRATE$ 104 DEPENDENCY$ 105ACCESS$ 106I_DEPENDENCY1 107I_DEPENDENCY2 108I_ACCESS16 rows selected.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_ac526b1e4be74880 SQL_PLAN_asnmb3t5yfk4024c6dbb6 AUTO-CAPTURE YES YES select object_id Object_name from t2 where object_id between 103 and 108

Now change the clustering factor of index IDX_T2 to 24 million so that the execution plan of SQL can be changed into a full table scan of table T2. (for why you modify the clustering factor, refer to http://hbxztc.blog.51cto.com/1587495/1901258). Execute the above SQL after modification, and view the execution plan:

Zx@MYDB > exec dbms_stats.set_index_stats (ownname= > USER,indname= > 'IDX_T2',clstfct= > 2400000 authoring noisy invalidates = > false); PL/SQL procedure successfully completed.zx@MYDB > select index_name,clustering_factor from dba_indexes where index_name='IDX_T2' INDEX_NAME CLUSTERING_FACTOR -- IDX_T2 24000000zx@MYDB > select object_id Object_name from t2 where object_id between 103 and 108 OBJECT_ID OBJECT_NAME--103MIGRATE$ 104DEPENDENCY$ 105ACCESS$ 106I_DEPENDENCY1 107I_DEPENDENCY2 108I_ACCESS16 rows selected.

From the execution plan, you can see that the execution plan of the SQL has been changed to a full table scan. Because the target SQL has been executed repeatedly and a new execution plan is generated at the same time, Oracle now automatically captures and creates the SQL Plan Baseline corresponding to this new execution plan. From the following query, you can see that Oracle has generated a new SQL Plan Baseline for the new execution plan, whose ENABLED value is still YES, but the value of ACCEPTED has changed to NO:

Now that we turn off automatic capture of SQL Plan Baseline for the current Session and enable SPM at the same time, now that the clustering factor of index IDX_T2 is still 24 million, execute the target SQL again and view the execution plan:

Zx@MYDB > alter session set optimizer_use_sql_plan_baselines=TRUE;Session altered.zx@MYDB > alter session set optimizer_capture_sql_plan_baselines=FALSE;Session altered.zx@MYDB > select index_name,clustering_factor from dba_indexes where index_name='IDX_T2' INDEX_NAME CLUSTERING_FACTOR -- IDX_T2 24000000zx@MYDB > select object_id Object_name from t2 where object_id between 103 and 108 OBJECT_ID OBJECT_NAME--103MIGRATE$ 104DEPENDENCY$ 105ACCESS$ 106I_DEPENDENCY1 107I_DEPENDENCY2 108I_ACCESS16 rows selected.

As can be seen from the above display, the execution of the target SQL is now restored from the full table scan to the index range scan, and there is a "SQL plan baseline SQL_PLAN_asnmb3t5yfk4024c6dbb6 used for this statement" content in the Note part of the execution plan, indicating that when SPM is turned on, even if the target SQL generates a new execution plan, Oracle will only apply SQL Plan Baselline with the values of both ENABLED and ACCEPTED of the SQL.

What should I do if I want to enable the target SQL's new execution plan (that is, a full table scan)?

There are different ways to deal with different versions of Oracle. For example, if you want to enable the new execution plan of the target SQL, if it is a 11gR1 environment, you only need to set the value of the ACCEPTED of the SQL Plan Baseline named SQL_PLAN_asnmb3t5yfk4024c6dbb6 (index range scan) used by the target SQL to NO. However, for 11gR2 environments, the above method will report an error, because in 11gR2, the value of ACCEPTED for all SQL Plan Baseline that has been ACCEPTED can no longer be set to NO:

Zx@MYDB > var temp varchar2 (1000); zx@MYDB > exec: temp: = dbms_spm.alter_sql_plan_baseline (sql_handle= > 'SYS_SQL_ac526b1e4be74880',plan_name= >' SQL_PLAN_asnmb3t5yfk4024c6dbb6',attribute_name= > 'accepted',attribute_value= >' NO'); BEGIN: temp: = dbms_spm.alter_sql_plan_baseline (sql_handle= > 'SYS_SQL_ac526b1e4be74880',plan_name= >' SQL_PLAN_asnmb3t5yfk4024c6dbb6',attribute_name= > 'accepted',attribute_value= >' NO'); END * ERROR at line 1:ORA-38136: invalid attribute name ACCEPTED specifiedORA-06512: at "SYS.DBMS_SPM", line 2469ORA-06512: at line 1

In 11gR2, we can use DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE and DBMS_SPM.ALTER_SQL_PLAN_BASELINE together to achieve the goal of enabling the target SQL's new execution plan.

First use DBMS_SPM.EVOLVE_SQL_PLAN_BASELINE to set the accepted value of the SQL Plan Baseline corresponding to the new execution plan (full table scan) to "YES":

Zx@MYDB > exec: temp: = dbms_spm.evolve_sql_plan_baseline (sql_handle= > 'SYS_SQL_ac526b1e4be74880',plan_name= >' SQL_PLAN_asnmb3t5yfk40b860bcf2',verify= > 'NO',commit= > YES'); PL/SQL procedure successfully completed.

From the content shown above, you can see the following message: "Plan: SQL_PLAN_asnmb3t5yfk40b860bcf2----Plan was changed to an accepted plan.", which indicates that the accepted value of the SQL Plan Baseline corresponding to the new execution plan (full table scan) has been set to YES

This can also be proved by the query results below:

Zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like 'select object_id%' SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_ac526b1e4be74880 SQL_PLAN_asnmb3t5yfk4024c6dbb6 AUTO-CAPTURE YES YES select object_id Object_name from t2 where object_id between 103 and 108SYS_SQL_ac526b1e4be74880 SQL_PLAN_asnmb3t5yfk40b860bcf2 AUTO-CAPTURE YES YES select object_id,object_name from t2 where object_id between 103 and 108

Then use DBMS_SPM.ALTER_SQL_PLAN_BASELINE to set the ENABLED value of the SQL Plan Baseline corresponding to the original execution plan (index range scan) to NO:

Zx@MYDB > exec: temp: = dbms_spm.alter_sql_plan_baseline (sql_handle= > 'SYS_SQL_ac526b1e4be74880',plan_name= >' SQL_PLAN_asnmb3t5yfk4024c6dbb6',attribute_name= > 'enabled',attribute_value= >' NO'); PL/SQL procedure successfully completed.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like 'select object_id%' SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_ac526b1e4be74880 SQL_PLAN_asnmb3t5yfk4024c6dbb6 AUTO-CAPTURE NO YES select object_id Object_name from t2 where object_id between 103 and 108SYS_SQL_ac526b1e4be74880 SQL_PLAN_asnmb3t5yfk40b860bcf2 AUTO-CAPTURE YES YES select object_id,object_name from t2 where object_id between 103 and 108

Execute the target SQL again

Zx@MYDB > select object_id,object_name from T2 where object_id between 103 and 108; OBJECT_ID OBJECT_NAME--103 MIGRATE$ 104 DEPENDENCY$ 105 ACCESS$ 106 I_DEPENDENCY1 107 I_DEPENDENCY2 108 I_ACCESS16 rows selected.

As can be seen from the above display, now that the execution plan of SQL has become a full table scan, our goal of enabling a new execution plan (full table scan) has been achieved, and there is a hint in the Note section.

As can be seen from the above test results, we can actually easily switch between multiple execution plans of the target SQL, so SPM can not only actively stabilize the execution plan, but also reserve the opportunity to continue to use the new execution plan, and we can easily enable the new execution plan.

The manual generation of SQL Plan Baseline is described below:

Generating the SQL Plan Baseline of the target SQL by hand is actually very simple, and its core is to call DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE. Only manual generation of SQL Plan Baseline for a single SQL is discussed here.

It was previously introduced that SQL Profile of type Manual can adjust its execution plan without changing the SQL text of the target SQL. In fact, you can achieve the same goal by generating SQL Plan Baseline by hand, even more succinctly than using SQL Profile of type Manual.

The specific steps for manually generating the SQL Plan Baseline of the target SQL are as follows:

1) use DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE to manually generate the SQL Plan Baseline corresponding to its initial execution plan for the target SQL. At this point, the parameters passed in using DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE are as follows:

Dbms_spm.load_plans_from_cursor_cache (sql_id= > 'SQL_ID',plan_hash_value= of original target SQL > PLAN HASH VALUE of original target SQL)

2) rewrite the SQL text of the original target SQL and add the appropriate Hint to it until the rewritten SQL after joining the Hint can walk out of the desired execution plan, and then use DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE to manually generate the new execution plan corresponding to the rewritten SQL. The parameters passed in at this time are as follows:

Dbms_spm.load_plans_from_cursor_cache (sql_id= > 'SQL_ID',plan_hash_value= of rewriting SQL after adding appropriate Hint > PLAN HASH VALUE,sql_handle= of rewriting SQL after adding appropriate Hint >' sql_handle' of SQL Plan Baseline generated by the original target SQL in step (1))

3) use DBMS_SPM.LOAD_PLANS_FROM_CURSOR_CACHE to delete the SQL Plan Baseline corresponding to the initial execution plan of the original target SQL manually generated in step (1). The parameters passed in at this time are as follows:

Dbms_spm.drop_sql_plan_baseline (sql_handle= > 'sql_handle',plan_name= of SQL Plan Baseline generated by original target SQL in step (1) >' plan_name' of SQL Plan Baseline generated by original target SQL in step (1))

Here is an example to demonstrate:

Zx@MYDB > select / * + no_index (T2 idx_t2) * / object_name,object_id from T2 where object_id=4;OBJECT_NAME OBJECT_ID---TAB$ 4zx@MYDB > select * from table (dbms_xplan.display_cursor (null,null,'advanced')) PLAN_TABLE_OUTPUT- -SQL_ID 0n5z3wmf8qpgn Child number 0--select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 whereobject_id=4Plan hash value: 1513984157UV-| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |- -| 0 | SELECT STATEMENT | | 287 | * 1 | TABLE ACCESS FULL | T2 | 1 | 30 | 287 (1) | 00:00:04 |- -Query Block Name / Object Alias (identified by operation id):- -1-SEL$1 / T2@SEL$1Outline Data- / * + BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE ('11.2.0.1') DB_VERSION ('11.2.0.1') ALL_ROWS OUTLINE_LEAF (@ "SEL$1") FULL (@ "SEL$1"T2" @ "SEL$1") END_OUTLINE_DATA * / Predicate Information (identified by operation id):-1-filter ("OBJECT_ID" = 4) Column Projection Information (identified by operation id):- -1-"OBJECT_NAME" [VARCHAR2128] "OBJECT_ID" [NUMBER,22] 43 rows selected.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like 'select / * + no_index (T2 idx_t2)%' No rows selectedzx@MYDB > var temp numberzx@MYDB > exec: temp: = dbms_spm.load_plans_from_cursor_cache (sql_id= > '0n5z3wmf8qpgnom1 planetary hashworthy value= > 1513984157); PL/SQL procedure successfully completed.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like' select / * + no_index (T2 idx_t2)%' SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_75b06ae056223f5f SQL_PLAN_7bc3aw1b24guzb860bcf2 MANUAL-LOAD YES YES Select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 where object_id = 4

From the above show that the initial execution plan of the target SQL is a full table scan, sql_id and plan hash value can be found in the execution plan. Since automatic capture of SQL Plan Baseline is not enabled, the corresponding SQL Plan Baseline of the target SQL is not found at the beginning. After manual generation, the corresponding SQL Plan Baseline of the full table scan can be found.

Rewrite the original target SQL and re-execute it after joining the Hint:

Zx@MYDB > select / * + index (T2 idx_t2) * / object_name,object_id from T2 where object_id=4;OBJECT_NAME OBJECT_ID---TAB$ 4zx@MYDB > select * from table (dbms_xplan.display_cursor (null,null,'advanced')) PLAN_TABLE_OUTPUT- -SQL_ID 60txg87j30pvw Child number 0--select / * + index (T2 idx_t2) * / object_name Object_id from T2 whereobject_id=4Plan hash value: 2008370210-| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |-| 0 | SELECT STATEMENT | 335,100 | | | 1 | TABLE ACCESS BY INDEX ROWID | T2 | 1 | 30 | 335 (0) | 00:00:05 | | * 2 | INDEX RANGE SCAN | IDX_T2 | 1 | | 1 (0) | 00:00:01 |- -Query Block Name / Object Alias (identified by operation id):-1 -SEL$1 / T2@SEL$1 2-SEL$1 / T2@SEL$1Outline Data- / * + BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE ('11.2.0.1') DB_VERSION ('11.2.0.1') ALL_ROWS OUTLINE_LEAF (@ "SEL$1") INDEX_RS_ASC (@ "SEL$1"T2" @ "SEL$1 "(" T2 "." OBJECT_ID ") END_OUTLINE_DATA * / Predicate Information (identified by operation id):-2-access (" OBJECT_ID "= 4) Column Projection Information (identified by operation id):- -1-"OBJECT_NAME" [VARCHAR2128] "OBJECT_ID" [NUMBER,22] 2-"T2" .ROWID [ROWID,10], "OBJECT_ID" [NUMBER,22] 46 rows selected.zx@MYDB > exec: temp: = dbms_spm.load_plans_from_cursor_cache (sql_id= > '60txg87j30pvwqlgift handle = > 2008370210 SYS_SQL_75b06ae056223f5f') PL/SQL procedure successfully completed.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like 'select / * + no_index (T2 idx_t2)' SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_75b06ae056223f5f SQL_PLAN_7bc3aw1b24guz24c6dbb6 MANUAL-LOAD YES YES Select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 where object_id = 4SYS_SQL_75b06ae056223f5f SQL_PLAN_7bc3aw1b24guzb860bcf2 MANUAL-LOAD YES YES select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 where object_id = 4

From the above output, we can see that the SQL Plan Baseline corresponding to the new execution plan of the rewritten SQL has been successfully generated, and the values of ENABLED and ACCEPTED of all manually generated SQL Plan Baseline are YES, which is different from the automatically captured SQL Plan Baseline.

Drop drops the SQL Plan Baseline corresponding to the original execution plan (full table scan):

Zx@MYDB > exec: temp: = dbms_spm.drop_sql_plan_baseline (sql_handle= > 'SYS_SQL_75b06ae056223f5f',plan_name= >' SQL_PLAN_7bc3aw1b24guzb860bcf2'); PL/SQL procedure successfully completed.zx@MYDB > select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like 'select / * + no_index (T2 idx_t2)%' SQL_HANDLE PLAN_NAME ORIGIN ENABLED ACCEPTED SQL_TEXT -SYS_SQL_75b06ae056223f5f SQL_PLAN_7bc3aw1b24guz24c6dbb6 MANUAL-LOAD YES YES Select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 where object_id = 4

Execute the original target SQL again and view the execution plan

Zx@MYDB > select / * + no_index (T2 idx_t2) * / object_name,object_id from T2 where object_id=4;OBJECT_NAME OBJECT_ID---TAB$ 4zx@MYDB > select * from table (dbms_xplan.display_cursor (null,null,'advanced')) PLAN_TABLE_OUTPUT- -SQL_ID 0n5z3wmf8qpgn Child number 2--select / * + no_index (T2 idx_t2) * / object_name Object_id from T2 whereobject_id=4Plan hash value: 2008370210-| Id | Operation | Name | Rows | Bytes | Cost (% CPU) | Time |-| 0 | SELECT STATEMENT | 335,100 | | | 1 | TABLE ACCESS BY INDEX ROWID | T2 | 1 | 30 | 335 (0) | 00:00:05 | | * 2 | INDEX RANGE SCAN | IDX_T2 | 1 | | 1 (0) | 00:00:01 |- -Query Block Name / Object Alias (identified by operation id):-1 -SEL$1 / T2@SEL$1 2-SEL$1 / T2@SEL$1Outline Data- / * + BEGIN_OUTLINE_DATA IGNORE_OPTIM_EMBEDDED_HINTS OPTIMIZER_FEATURES_ENABLE ('11.2.0.1') DB_VERSION ('11.2.0.1') ALL_ROWS OUTLINE_LEAF (@ "SEL$1") INDEX_RS_ASC (@ "SEL$1"T2" @ "SEL$1 "(" T2 "." OBJECT_ID ") END_OUTLINE_DATA * / Predicate Information (identified by operation id):-2-access (" OBJECT_ID "= 4) Column Projection Information (identified by operation id):- -1-"OBJECT_NAME" [VARCHAR2128] "OBJECT_ID" [NUMBER,22] 2-"T2" .ROWID [ROWID,10], "OBJECT_ID" [NUMBER,22] Note--SQL plan baseline SQL_PLAN_7bc3aw1b24guz24c6dbb6 used for this statement50 rows selected.

As can be seen from the above output, the original target SQL has taken a new execution plan (index range scan), and the Note section also has a hint of "SQL plan baseline SQL_PLAN_7bc3aw1b24guz24c6dbb6 used for this statement" indicating that SPM is gone.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.