Before 10G we can capture a SQL statement’s execution plan and save it
into a stored outline.
Thus we can change the execution plan without any SQL modification.
In 10G it is called SQL Profiles
.
In 11G it is called SQL Plan Management.
They take same fuctions although the ways of implementation are different.
See the example like below:
SQL> create table t (id number,name varchar2(100));
表已创建。
SQL> insert into t select rownum,object_name from dba_objects;
已创建72993行。
SQL> commit;
提交完成。
SQL> set autotrace traceonly exp stat;
SQL>
SQL> select * from t where id=3;
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
----------------------------------
| Id | Operation | Name |
----------------------------------
| 0 | SELECT STATEMENT | |
|* 1 | TABLE ACCESS FULL| T |
----------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"=3)
Note
-----
- rule based optimizer used (consider using cbo)
统计信息
----------------------------------------------------------
2 recursive calls
1 db block gets
382 consistent gets
0 physical reads
176 redo size
480 bytes sent via SQL*Net to client
416 bytes received via SQL*Net from client
2 SQL*Net roundtrips to/from client
0 sorts (memory)
0 sorts (disk)
1 rows processed
SQL> select sql_text,signature,sql_handle,plan_name,origin,enabled,accepted, autopurge
from dba_sql_plan_baselines where sql_text like '%select * from t where id=3%'
SQL> /
未选定行
SQL> alter session set optimizer_capture_sql_plan_baselines=true;
会话已更改。
SQL> select * from t where id=3;
ID
----------
NAME
--------------------------------------------------------------------------------
3
CON$
SQL> select sql_text,signature,sql_handle,plan_name,origin,enabled,accepted, autopurge
2 from dba_sql_plan_baselines where sql_text like '%select * from t where id=3%';
SQL_TEXT
--------------------------------------------------------------------------------
SIGNATURE SQL_HANDLE PLAN_NAME
---------- ------------------------------ ------------------------------
ORIGIN ENA ACC AUT
-------------- --- --- ---
select * from t where id=3
9.9679E+18 SYS_SQL_8a54f32d904f9eda SQL_PLAN_8np7m5q84z7qu94ecae5c
AUTO-CAPTURE YES YES YES
Add the index.
SQL> create index idx_t on t(id);
索引已创建。
SQL> exec dbms_stats.gather_table_stats(user,'t',cascade=>true)
PL/SQL 过程已成功完成。
SQL> select * from t where id=3;
ID
----------
NAME
--------------------------------------------------------------------------------
3
CON$
SQL> select sql_text,signature,sql_handle,plan_name,origin,enabled,accepted, autopurge
2 from dba_sql_plan_baselines where sql_text like '%select * from t where id=3%';
SQL_TEXT
--------------------------------------------------------------------------------
SIGNATURE SQL_HANDLE PLAN_NAME
---------- ------------------------------ ------------------------------
ORIGIN ENA ACC AUT
-------------- --- --- ---
select sql_text,signature,sql_handle,plan_name,origin,enabled,accepted, autopurg
8.0612E+18 SYS_SQL_6fdf0504e8efd004 SQL_PLAN_6zrs50mnfzn04391601ca
AUTO-CAPTURE YES YES YES
select * from t where id=3
9.9679E+18 SYS_SQL_8a54f32d904f9eda SQL_PLAN_8np7m5q84z7qu880b6daf
AUTO-CAPTURE YES NO YES
SQL_TEXT
--------------------------------------------------------------------------------
SIGNATURE SQL_HANDLE PLAN_NAME
---------- ------------------------------ ------------------------------
ORIGIN ENA ACC AUT
-------------- --- --- ---
select * from t where id=3
9.9679E+18 SYS_SQL_8a54f32d904f9eda SQL_PLAN_8np7m5q84z7qu94ecae5c
AUTO-CAPTURE YES YES YES
the changed plan(using index) was captured automatically but can not be used by itself becaue the first one is default.
SQL> select * from t where id=3;
ID
----------
NAME
--------------------------------------------------------------------------------
3
CON$
执行计划
----------------------------------------------------------
Plan hash value: 1601196873
--------------------------------------------------------------------------
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time |
--------------------------------------------------------------------------
| 0 | SELECT STATEMENT | | 1 | 29 | 96 (2)| 00:00:02 |
|* 1 | TABLE ACCESS FULL| T | 1 | 29 | 96 (2)| 00:00:02 |
--------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
1 - filter("ID"=3)
Note
-----
- SQL plan baseline "SQL_PLAN_8np7m5q84z7qu94ecae5c" used for this statement
See the accept column is NO for the second SQL PLAN.
Let us disable the first one .Then the second is not accepted either.
SQL> /
ID
----------
NAME
--------------------------------------------------------------------------------
3
CON$
执行计划
----------------------------------------------------------
Plan hash value: 1594971208
--------------------------------------------------------------------------------
-----
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
-----
| 0 | SELECT STATEMENT | | 1 | 29 | 1 (0)| 00:00
:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 29 | 1 (0)| 00:00
:01 |
|* 2 | INDEX RANGE SCAN | IDX_T | 1 | | 1 (0)| 00:00
:01 |
--------------------------------------------------------------------------------
-----
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=3)
Let us enable the second one.
Make it accepted.
SQL> /
ID
----------
NAME
--------------------------------------------------------------------------------
3
CON$
执行计划
----------------------------------------------------------
Plan hash value: 1594971208
--------------------------------------------------------------------------------
-----
| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time
|
--------------------------------------------------------------------------------
-----
| 0 | SELECT STATEMENT | | 1 | 29 | 1 (0)| 00:00
:01 |
| 1 | TABLE ACCESS BY INDEX ROWID| T | 1 | 29 | 1 (0)| 00:00
:01 |
|* 2 | INDEX RANGE SCAN | IDX_T | 1 | | 1 (0)| 00:00
:01 |
--------------------------------------------------------------------------------
-----
Predicate Information (identified by operation id):
---------------------------------------------------
2 - access("ID"=3)
Note
-----
- SQL plan baseline "SQL_PLAN_8np7m5q84z7qu880b6daf" used for this statement
分享到:
相关推荐
以下是对提供的文件内容中关于Oracle SQL计划管理(SQL Plan Management, SPM)的知识点的总结: 1. SQL执行计划的重要性: - 数据库应用程序的性能在很大程度上依赖于查询执行的一致性。 - Oracle优化器通常能够...
其中一项重要的增强功能便是SQL计划管理(SQL Plan Management, SPM),这一功能旨在帮助DBA更好地控制SQL执行计划的变化,从而提高系统的整体性能稳定性。本文将深入探讨SQL计划管理的相关知识点,包括其背景、原理、...
在优化过程中,DBA还可以结合使用其他Oracle提供的工具和功能,如SQL Tuning Advisor、SQL Plan Management等,以获得更深入的分析和更精准的优化建议。通过持续的监控和调优,DBA能够确保系统运行在最佳状态,及时...
在Oracle Database中,SQL计划管理(SQL Plan Management,简称SPM)是一项重要的功能,旨在确保SQL语句的执行计划稳定性,同时允许在不影响性能的前提下,适应数据库环境的变化。SPM的主要目标是提供一个框架,使得...
8. SQL Profile和SQL Plan Management:这些是Oracle 11g中提供的高级SQL调优特性,可以存储特定SQL语句的性能信息,并且在执行计划发生变化时进行干预。 9. 分区表和索引:对大型表和索引进行分区可以提高查询性能...
执行计划管理(SQL Plan Management, SPM)是Oracle 11g引入的一个新特性,用于管理和固定SQL语句的执行计划,防止由于执行计划的改变导致性能下降。在11g之前,管理员可以通过存储大纲(Stored Outlines)或SQL ...
Oracle 11g R2作为一个成熟的数据库管理系统,提供了许多高级特性,比如数据泵(Data Pump)导入导出、自动工作负载仓库(AWR)、和SQL Plan Management等。这些功能在文档中都有详细描述,并提供了如何在实际环境中应用...
利用SQL Plan Management(SPM)特性来管理执行计划版本。 #### 十、总结 以上内容涵盖了SQL优化公开课1中的核心知识点,包括如何定位Top-SQL、会话跟踪、解读执行计划、统计信息分析、全表扫描优化、索引优化、...
本文档介绍了在Oracle中固定执行计划的三种方法,分别是outline、SQLProfile和SPM(SQL Plan Management),并且着重讲解了SQLProfile和SPM的使用。 1. Outline方法 Outline是一种较老的技术,在Oracle的9i版本中就...
Oracle SQL计划管理(SQL Plan Management,简称SPM)技术是一种用于自动管理和维护SQL执行计划的数据库优化工具。在油田信息化管理中,如辽河油田油气生产数据库的应用,SPM技术发挥着关键作用,帮助解决性能瓶颈...
Oracle SPM(SQL Plan Management)是Oracle数据库的一种特性,它允许管理员管理并控制SQL语句的执行计划,以确保性能的稳定性和可预测性。在实际工作中,有时我们需要手动绑定特定的执行计划来解决性能问题或者避免...
在Oracle自动化索引中,还有许多其他的特征,例如Automatic SQL tuning sets、SQL Performance Analyzer、Index Visibility、SQL Plan Management等。这些特征可以帮助数据库管理员更方便地管理索引,提高数据库的...
### 如何充分利用Oracle的成本基础...此外,了解和利用Oracle提供的工具和功能,如SQL Plan Management和自动基数反馈调整,也是至关重要的。通过这些方法,可以显著提高查询性能,从而提升整体系统的效率和响应能力。
SQL Plan Management允许DBA管理和控制SQL语句的执行计划版本。这有助于防止因为优化器参数改变而导致的性能倒退。SPM支持存储和检索执行计划,并可以在不同版本之间切换。 #### 二、SQL计划管理(SPM)详解 SPM是...
### SQL计划管理(SQL Plan Management) - **SQL计划基线架构(SQL Plan Baseline Architecture):** 让考生理解什么是SQL计划基线,以及它们是如何被存储和管理的。 - **设置SQL计划基线(Setup SQL Plan ...
**解析**:此题考查了 SQL Plan Management (SPM) 的一个关键功能——`EVOLVE_SQL_PLAN_BASELINE` 过程。该过程用于处理 SQL 计划基线中的非接受计划。当执行此 PL/SQL 块时,`EVOLVE_SQL_PLAN_BASELINE` 方法会检查...
### 三、SQL计划管理(SQL Plan Management) SQL计划管理提供了一种机制来存储和复用执行计划,从而避免了重复创建计划所带来的性能开销。此外,它还允许管理员控制和优化特定SQL语句的执行方式,以适应不断变化的...
- SQL Plan Management 的策略。 13. **第十三章:配置优化器** - **主要内容**:该章将讲解如何根据实际需求调整优化器的参数设置。 - **知识点**: - Optimizer Parameters 的理解和调整。 - Optimizer ...
Oracle 12c引入了许多新特性,如Multitenant架构、Automatic Memory Management优化、SQL Plan Management改进等,这些在Instant Client中都能得到体现。 在描述中提到“oracle网站总崩”,这可能是指下载Oracle...
* Automatic SQL Plan Management * Automatic Capture of SQL Monitor * Automatic Data Optimization Oracle 自治数据库的部署选择包括: * 公有云(Severless) * 私有云(Exadata Cloud@Customer) Oracle ...