ORACLE 11G SPM(SQL PLAN manager)浅析

11g推出的SPM是一种主动的稳定执行计划的手段,能够保证只有被验证过的执行计划才会被启用。SPM既能够主动的稳定执行计划,又保留了继续使用新的执行效率更高的执行计划的机会。

启用SPM后,每一个SQL都会存在对应的SQL PLAN Baseline,存储在DBA_SQL_PLAN_BASELINES视图。

该视图的enable和accept列均为YES的SQL PLAN Baseline所对应的执行计划才会被执行。如果有超过1个以上的均为YES,那么oracle会选择其中cost值最小的为执行计划。

可以有2种方法产生SQL PLAN Baseline

1.自动捕获

2.手动生成/批量导入

下面先介绍自动捕获。参数optimizer_capture_sql_plan_baselines用于控制是否开启自动捕获,默认为false。参数optimizer_use_sql_plan_baselines用于控制是否启用SPM,默认为TRUE,表示默认情况下Oracle在生成执行计划时就会启用SPM,使用已有的SQL PLAN Baseline。

创建一个自动捕获SQL PLAN Baseline,并据此来稳定执行计划。

默认参数

[email protected]:test> show parameter sql_plan

NAME                                 TYPE        VALUE
------------------------------------ ----------- ------------------------------
optimizer_capture_sql_plan_baselines boolean     FALSE
optimizer_use_sql_plan_baselines     boolean     TRUE

在当前session禁用SPM,同时开启自动捕获。

[email protected]:test> alter session set optimizer_capture_sql_plan_baselines=true;

Session altered.

[email protected]:test> alter session set optimizer_use_sql_plan_baselines=false;

Session altered.

创建测试表T2,并创建索引

[email protected]:test> create table t2 as select * from dba_objects;

Table created.

[email protected]:test> create index idx_t2 on t2(object_id);

Index created.

对T2收集统计信息

[email protected]:test> exec dbms_stats.gather_table_stats(ownname => ‘AAA‘,tabname => ‘T2‘,estimate_percent => 100,cascade => true);

PL/SQL procedure successfully completed.

执行SQL

[email protected]:test> 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_ACCESS1

6 rows selected.

执行计划如下

-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  8vtdn0kgytfxr, child number 0
-------------------------------------
select object_id,object_name from t2 where object_id between 103 and 108

Plan hash value: 2008370210

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |     3 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     6 |   180 |     3   (0)| 00:00:01 |
|*  2 |   INDEX RANGE SCAN          | IDX_T2 |     6 |       |     2   (0)| 00:00:01

因为该SQL只执行过一次,所以Oracle不会自动捕获其SQL PLAN Baseline,验证:

[email protected]:test> select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like ‘select object_id%‘;

no rows selected

再执行一次,执行计划没有变化,因为SQL已经重复执行,Oracle会自动捕获其SQL PLAN Baseline

SQL> 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 108

这里修改索引IDX_T2的聚簇因子修改为2400万,改变目标SQL的执行计划为全表。

SQL> exec dbms_stats.set_index_stats(ownname=>‘AAA‘,indname=>‘IDX_T2‘,clstfct=>24000000,no_invalidate => false);
PL/SQL procedure successfully completed

重新执行SQL,执行计划如下,为全表

select object_id,object_name from t2 where object_id between 103 and 108

Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |   290 (100)|          |
|*  1 |  TABLE ACCESS FULL| T2   |     6 |   180 |   290   (1)| 00:00:04 |
--------------------------------------------------------------------------

因为目标SQL已经重复执行且又产生了一个执行计划,所以Oracle会自动捕获并创建这个新的执行计划所对应的SQL PLAN Baseline,查询视图

SQL> 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 108
SYS_SQL_ac526b1e4be74880       SQL_PLAN_asnmb3t5yfk40b860bcf2 AUTO-CAPTURE   YES     NO       select object_id,object_name from t2 where object_id between 103 and 108

然后关闭当前session自动捕获SQL PLAN Baseline,并启用SPM,就是恢复11g默认

[email protected]:test> alter session set optimizer_capture_sql_plan_baselines=false;

Session altered.

[email protected]:test> alter session set optimizer_use_sql_plan_baselines=true;

Session altered.

现在索引IDX_T2的聚簇因子还是2400万

[email protected]:test> select index_name,clustering_factor from user_indexes;

INDEX_NAME                     CLUSTERING_FACTOR
------------------------------ -----------------
IDX_T2                                  24000000

再次执行目标SQL,其执行计划

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  8vtdn0kgytfxr, child number 2
-------------------------------------
select object_id,object_name from t2 where object_id between 103 and 108

Plan hash value: 2008370210

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |  2069 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     6 |   180 |  2069   (0)| 00:00:25 |
|*  2 |   INDEX RANGE SCAN          | IDX_T2 |     6 |       |     2   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
Note
-----
   - SQL plan baseline SQL_PLAN_asnmb3t5yfk4024c6dbb6 used for this statement

上述可以看出,现在目标SQL的执行计划已经从对表的全表扫描,变成了索引范围扫描。并且NOTE下面有“SQL plan baseline SQL_PLAN_asnmb3t5yfk4024c6dbb6 used for this statement”,这表明在启用SPM情况下, 即使目标SQL产生了新执行计划,Oracle依然只会使用enabled和accepted均为YES的SQL PLAN Baseline对应的执行计划。

如果想启用新的执行计划,对于不同版本操作不一样。

11gR1,只需要将目标SQL锁采用的名为SQL_PLAN_asnmb3t5yfk4024c6dbb6的SQL PLAN Baseline的accepted值变为NO即可。

SQL> var temp number;
SQL> exec :temp:=dbms_spm.alter_sql_plan_baseline(sql_handle => ‘SYS_SQL_ac526b1e4be74880‘,plan_name => ‘SQL_PLAN_asnmb3t5yfk4024c6dbb6‘,attribute_name => ‘accepted‘,attribute_value => ‘NO‘);

在11gR2中,执行上述代码或报错

SQL> var temp number;
SQL> 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;
ORA-38136: 指定的属性名 ACCEPTED 无效
ORA-06512: 在 "SYS.DBMS_SPM", line 2469
ORA-06512: 在 line 1
temp
---------

在11gR2中,使用dbms_spm.evolve_sql_plan_baseline和dbms_spm.alter_sql_plan_baseline达到启用新执行计划的目的。

先用dbms_spm.evolve_sql_plan_baseline将新执行计划的accepted置为YES

SQL> var temp varchar2(4000);
SQL> 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
temp
---------

-------------------------------------------------------------------------------
                        Evolve SQL Plan Baseline Report
-------------------------------------------------------------------------------

Inputs:
-------
  SQL_HANDLE = SYS_SQL_ac526b1e4be74880
  PLAN_NAME  = SQL_PLAN_asnmb3t5yfk40b860bcf2
  TIME_LIMIT = DBMS_SPM.AUTO_LIMIT
  VERIFY     = NO
  COMMIT     = YES

Plan: SQL_PLAN_asnmb3t5yfk40b860bcf2
------------------------------------
  It is already an accepted plan.

-------------------------------------------------------------------------------
                                 Report Summary
-------------------------------------------------------------------------------
There were no SQL plan baselines that required processing.

SQL> 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 108
SYS_SQL_ac526b1e4be74880       SQL_PLAN_asnmb3t5yfk40b860bcf2 AUTO-CAPTURE   YES     YES      select object_id,object_name from t2 where ob

再使用dbms_spm.alter_sql_plan_baseline把PLAN_NAME为SQL_PLAN_asnmb3t5yfk4024c6dbb6的SQL PLAN Baseline的enabled置为NO。

SQL> var temp number;
SQL> 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
temp
---------
1

SQL> 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 108
SYS_SQL_ac526b1e4be74880       SQL_PLAN_asnmb3t5yfk40b860bcf2 AUTO-CAPTURE   YES     YES      select object_id,object_name from t2 where object_id between 103 and 108

再次执行目标SQL

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  8vtdn0kgytfxr, child number 0
-------------------------------------
select object_id,object_name from t2 where object_id between 103 and 108

Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |   290 (100)|          |
|*  1 |  TABLE ACCESS FULL| T2   |     6 |   180 |   290   (1)| 00:00:04 |
--------------------------------------------------------------------------
Note
-----
   - SQL plan baseline SQL_PLAN_asnmb3t5yfk40b860bcf2 used for this statement

使用了新的执行计划,注意NOTE中SQL_PLAN_asnmb3t5yfk40b860bcf2即SQL PLAN Baseline中enabled和accepted均为YES的SQL PLAN Baseline对应的执行执行计划名。

从测试结果看出,我们可以在目标SQL的多个执行计划之间切换,所以SPM既能稳定执行计划,又保留了继续使用新的执行计划的机会。

接下来介绍手工生成SQL PLAN Baseline。手工生成很简单,核心是调用dbms_spm.load_plans_from_cursor_cache。

针对目标SQL使用dbms_spm.load_plans_from_cursor_cache手工生成其初始执行计划所对应的SQL PLAN Baseline。

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  85htp4tya3uwm, child number 0
-------------------------------------
select /*+ no_index(t2 idx_t2)*/ object_name,object_id from t2 where
object_id=4

Plan hash value: 1513984157

--------------------------------------------------------------------------
| Id  | Operation         | Name | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------
|   0 | SELECT STATEMENT  |      |       |       |   290 (100)|          |
|*  1 |  TABLE ACCESS FULL| T2   |     1 |    30 |   290   (1)| 00:00:04 |

上述SQL的SQL_ID为85htp4tya3uwm,plan_hash_value为1513984157,现在没有开启自动捕获SQL PLAN Baseline。视图dba_sql_plan_baselines应该没有对应信息。

select sql_handle,plan_name,origin,enabled,accepted,sql_text from dba_sql_plan_baselines where sql_text like ‘select object_name%‘;
SQL_HANDLE                     PLAN_NAME                      ORIGIN         ENABLED ACCEPTED SQL_TEXT
------------------------------ ------------------------------ -------------- ------- -------- -----------------------------------------------------------

使用目标SQL的SQL_ID和PLAN_HASH_VALUE来生成所对应的SQL PLAN Baseline。

SQL> var temp number;
SQL> exec :temp:=dbms_spm.load_plans_from_cursor_cache(sql_id=>‘85htp4tya3uwm‘,plan_hash_value=>1513984157);
PL/SQL procedure successfully completed
temp
---------
1
SQL> 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)*/ object_name%‘;
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

已经生成了SQL_HANDLE为SYS_SQL_75b06ae056223f5f和PLAN_NAME为SQL_PLAN_7bc3aw1b24guzb860bcf2的SQL PLAN Baseline。

改写原目标SQL,加入强制走索引hint

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  0argb4cn0sybz, child number 0
-------------------------------------
select /*+ index(t2 idx_t2)*/ object_name,object_id from t2 where
object_id=4

Plan hash value: 2008370210

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |   332 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     1 |    30 |   332   (0)| 00:00:04 |
|*  2 |   INDEX RANGE SCAN          | IDX_T2 |     1 |       |     1   (0)| 00:00:01 |

改写后走索引,SQL_ID=0argb4cn0sybz,Plan hash value: 2008370210。

再加上原目标SQL的SQL_HANDLE来生成新的SQL PLAN Baseline。

SQL> exec :temp:=dbms_spm.load_plans_from_cursor_cache(sql_id=>‘0argb4cn0sybz‘,plan_hash_value=>2008370210,sql_handle=>‘SYS_SQL_75b06ae056223f5f‘);
PL/SQL procedure successfully completed
temp
---------
1
SQL> 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)*/ object_name%‘;
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
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

上述可以看出原目标SQL生成了新的PLAN,其PLAN_NAME为SQL_PLAN_7bc3aw1b24guz24c6dbb6。注意新生成的SQL PLAN Baseline的enabled和accepted均为YES,这是个自动捕获不同的地方。

现在DROP掉原目标SQL走全表扫描所对应的SQL PLAN Baseline。

SQL> exec :temp:=dbms_spm.drop_sql_plan_baseline(sql_handle =>‘SYS_SQL_75b06ae056223f5f‘,plan_name => ‘SQL_PLAN_7bc3aw1b24guzb860bcf2‘);
PL/SQL procedure successfully completed
temp
---------
1
SQL>  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)*/ object_name%‘;
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

再次执行原SQL,可以看到走了索引

PLAN_TABLE_OUTPUT
-----------------------------------------------------------------------------------------------------------------------------------
SQL_ID  85htp4tya3uwm, child number 2
-------------------------------------
select /*+ no_index(t2 idx_t2)*/ object_name,object_id from t2 where
object_id=4

Plan hash value: 2008370210

--------------------------------------------------------------------------------------
| Id  | Operation                   | Name   | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT            |        |       |       |   332 (100)|          |
|   1 |  TABLE ACCESS BY INDEX ROWID| T2     |     1 |    30 |   332   (0)| 00:00:04 |
|*  2 |   INDEX RANGE SCAN          | IDX_T2 |     1 |       |     1   (0)| 00:00:01 |
--------------------------------------------------------------------------------------
Note
-----
   - SQL plan baseline SQL_PLAN_7bc3aw1b24guz24c6dbb6 used for this statement

最后注意NOTE下面,使用了SQL PLAN Baeline。

时间: 2024-08-12 13:59:27

ORACLE 11G SPM(SQL PLAN manager)浅析的相关文章

Oracle 11g实时SQL监控 v$sql_monitor

Oracle 11g实时SQL监控: 前面提到,在Oracle Database 11g中,v$session视图增加了一些新的字段,这其中包括SQL_EXEC_START和SQL_EXEC_ID, 这两个字段实际上代表了Oracle 11g的一个新特性:实时的SQL监控(Real Time SQL Monitoring). 在Oracle 11g之前的版本,长时间运行的SQL可以通过监控v$session_longops来观察,当某个操作执行时间超过6秒, 就会被记录在v$session_lo

ORACLE 11G 禁用 SQL TUNING ADVISOR

生产上有一套11g数据库alert.log报错ORA-16957: SQL Analyze time limit interrupt. 查询MOS相关文档Troubleshooting: ORA-16957: "SQL Analyze time limit interrupt" Errors (文档 ID 1275248.1) The ORA-16957 error is an internal error code used to indicate that SQL Tuning T

Oracle 11g 禁用 SQL Tuning Advisor 与 auto space advisor

生产上有一套11g数据库alert.log报错ORA-16957: SQL Analyze time limit interrupt.  查询MOS相关文档Troubleshooting: ORA-16957: "SQL Analyze time limit interrupt" Errors (文档 ID 1275248.1)    The ORA-16957 error is an internal error code used to indicate that SQL Tuni

In Oracle 11g, how to change the order of the results of a sql without “order by”?(转)

oracle 11g 当sql语句中不加order by的时候,好像是按rowid的顺序返回结果的.我也看过一些相关的文档,oracle的官方意思就是不加order by,就不保证输出的顺序. 那么,问题来了:如果现在我select XXX,一组结果出来,顺序是.......A....B.....那么接下来我做什么操作,再做同样一句select,怎么才能让结果变成....B...A.....Notice1: 操作中请勿修改表的主键,不要用DDL,只用select * from A;得到结果Not

Oracle 11g Articles

发现一个比较有意思的网站,http://www.oracle-base.com/articles/11g/articles-11g.php Oracle 11g Articles Oracle Database 11g: New Features For Administrators OCP Exam Articles Oracle Database 11g Release 1: Miscellaneous Articles Oracle Database 11g Release 2: Misc

[转]Oracle 11g 新特性 -- SQL Plan Management 说明

一 概述 二 SQL 计划基线Plan BaseLine体系结构三 加载SQL 计划基线四 演化SQL 计划基线五 重要的基线SQL 计划属性六 SQL 计划选择七 可能的SQL 计划可管理性方案八 SQL 性能分析器和SQL 计划基准方案九 自动加载SQL 计划基线方案十 清除SQL 管理库策略 一.概述 SQL 语句的SQL 执行计划发生更改时,可能存在性能风险. SQL 计划发生更改的原因有很多,如优化程序版本.优化程序统计信息.优化程序参数.方案定义.系统设计和SQL 概要文件创建等.

[转]Oracle 11g 新特性 -- SQL Plan Management 示例

目录 一 SPM 说明 相关名词说明 SPM的特点 与profile和outline相比更加灵活的控制手段 SPM使计划真正的稳定 SPM的控制方式 SPM如何捕捉加载执行计划 自动捕捉 批量导入 执行计划的选择过程 执行计划的演化evolution 修改已有的Baseline 相关MOS 文档 二 SPM 示例 自动捕捉 手工捕获执行计划 演化SQL Plan Baselines 完整示例 修改 Plan Baselines 显示SQL Plan Baselines 设置SQL Managem

11g新特性-SQL Plan Management

在11g之前版本,提供了stored outlines(sql概要)特性来保存sql的执行计划. 在11g中,引入了一个新的特性sql计划管理(sql plan management)特性来保存sql性能. 数据库自动控制sql执行计划的演变,借助sql plan baselines. SPM会不时的捕获和评估sql的执行计划,然后建立只包含高效的执行计划的sql plan baselines. sql plan baselines只会包含那些不会引起sql性能下降的执行计划. 当系统遇到以下变

oracle11g中SQL优化(SQL TUNING)新特性之SQL Plan Management(SPM)

1.   简单介绍 Oracle Database11gR1引进了SQL PlanManagement(简称SPM),一套同意DBA捕获和保持随意SQL语句运行计划最优的新工具,这样,限制了刷新优化器统计数据.已有应用改变.甚至数据库版本号升级带来的影响.本文帮助对SPM原理基本了解,并对其性能优化能力进行简要的说明. 2.   SPM原理和机制 Oracle 11g通过一个简单而优雅的方法实施了解决SQL计划意外恶化的一套称为SQL Plan Management(SPM)的新特点.仅仅要用户