SQL自动调优

SQL自动调优,是oracle 自带的调优工具,可以提出一些解决方案。

本次我主要介绍下面这些自动SQL调优工具:

  • 自动SQL调优(automatic sql tuning)
  • SQL调优工具集(SQL tuning sets,STS)
  • SQL调优顾问(SQL Tuning Advisor)
  • 自动数据库诊断监视器(addm)

显示SQL自动调优建议最快的方法:

SQL> select dbms_auto_sqltune.report_auto_tuning_task from dual;

GENERAL INFORMATION SECTION

-------------------------------------------------------------------------------

Tuning Task Name                        : SYS_AUTO_SQL_TUNING_TASK

Tuning Task Owner                       : SYS

Workload Type                           : Automatic High-Load SQL Workload

Execution Count                         : 2

Current Execution                       : EXEC_41

Execution Type                          : TUNE SQL

Scope                                   : COMPREHENSIVE

Global Time Limit(seconds)              : 3600

Per-SQL Time Limit(seconds)             : 1200

Completion Status                       : COMPLETED

Started at                              : 09/13/2015 23:19:10

Completed at                            : 09/13/2015 23:20:50

Number of Candidate SQLs                : 2

Cumulative Elapsed Time of SQL (s)      : 56

-------------------------------------------------------------------------------

SUMMARY SECTION

-------------------------------------------------------------------------------

Global SQL Tuning Result Statistics

-------------------------------------------------------------------------------

Number of SQLs Analyzed                      : 2

Number of SQLs in the Report                 : 2

Number of SQLs with Findings                 : 2

Number of SQLs with Statistic Findings       : 2

Number of SQLs with Alternative Plan Findings: 1

Number of SQLs with SQL profiles recommended : 2

-------------------------------------------------------------------------------

SQLs with Findings Ordered by Maximum (Profile/Index) Benefit, Object ID

-------------------------------------------------------------------------------

object ID  SQL ID        statistics profile(benefit) index(benefit) restructure

---------- ------------- ---------- ---------------- -------------- -----------

3 5jvf84zg4c49n          2           94.73%

4 fa16465c7pqmd          1           93.52%

-------------------------------------------------------------------------------

Objects with Missing/Stale Statistics (ordered by schema, object, type)

-------------------------------------------------------------------------------

Schema Name                  Object Name                  Type  State   Cascade

---------------------------- ---------------------------- ----- ------- -------

SYS IND$                         TABLE STALE   NO

USER$                        TABLE STALE   NO

-------------------------------------------------------------------------------

DETAILS SECTION

-------------------------------------------------------------------------------

Statements with Results Ordered by Maximum (Profile/Index) Benefit, Object ID

-------------------------------------------------------------------------------

Object ID  : 3

Schema Name: SYS

SQL ID     : 5jvf84zg4c49n

SQL Text   : select s.synonym_name as object_name, o.object_type

from sys.all_synonyms s, sys.all_objects o

where s.owner in (‘PUBLIC‘, :schema)

and o.owner = s.table_owner

and o.object_name = s.table_name

and o.object_type in (‘TABLE‘, ‘VIEW‘, ‘PACKAGE‘,‘TYPE‘,

‘PROCEDURE‘, ‘FUNCTION‘, ‘SEQUENCE‘)

-------------------------------------------------------------------------------

FINDINGS SECTION (3 findings)

-------------------------------------------------------------------------------

1- Statistics Finding

---------------------

Optimizer statistics for table "SYS"."IND$" and its indices are stale.

Recommendation

--------------

- Consider collecting optimizer statistics for this table.

execute dbms_stats.gather_table_stats(ownname => ‘SYS‘, tabname =>

‘IND$‘, estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,

method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘);

Rationale

---------

The optimizer requires up-to-date statistics for the table in order to

select a good execution plan.

2- Statistics Finding

---------------------

Optimizer statistics for table "SYS"."USER$" and its indices are stale.

Recommendation

--------------

- Consider collecting optimizer statistics for this table.

execute dbms_stats.gather_table_stats(ownname => ‘SYS‘, tabname =>

‘USER$‘, estimate_percent => DBMS_STATS.AUTO_SAMPLE_SIZE,

method_opt => ‘FOR ALL COLUMNS SIZE AUTO‘);

Rationale

---------

The optimizer requires up-to-date statistics for the table in order to

select a good execution plan.

3- SQL Profile Finding (see explain plans section below)

--------------------------------------------------------

A potentially better execution plan was found for this statement.

The SQL profile was not automatically created because its benefit could not

be verified.

Recommendation (estimated benefit: 94.73%)

------------------------------------------

- Consider accepting the recommended SQL profile.

execute dbms_sqltune.accept_sql_profile(task_name =>

‘SYS_AUTO_SQL_TUNING_TASK‘, object_id => 3, replace => TRUE);

-------------------------------------------------------------------------------

EXPLAIN PLANS SECTION

-------------------------------------------------------------------------------

1- Original With Adjusted Cost

------------------------------

-------------------------------------------------------------------------------

Error: cannot fetch explain plan for object: 3

-------------------------------------------------------------------------------

2- Original With Adjusted Cost

------------------------------

Plan hash value: 1687783800

--------------------------------------------------------------------------------

---------------------------------------------

| Id  | Operation                                      | Name               | Ro

ws  | Bytes |TempSpc| Cost (%CPU)| Time     |

--------------------------------------------------------------------------------

---------------------------------------------

|   0 | SELECT STATEMENT                               |                    |

4 |   464 |       |  4999   (1)| 00:01:00 |

|*  1 |  TABLE ACCESS BY INDEX ROWID                   | SUM$               |

1 |     6 |       |     0   (0)| 00:00:01 |

|*  2 |   INDEX UNIQUE SCAN                            | I_SUM$_1           |

1 |       |       |     0   (0)| 00:00:01 |

|*  3 |  HASH JOIN                                     |                    |

4 |   464 |       |  4999   (1)| 00:01:00 |

|   4 |   JOIN FILTER CREATE                           | :BF0000            |  3

时间: 2024-10-19 01:20:37

SQL自动调优的相关文章

如何使用oracle 的DBMS_SQLTUNE package 来运行 Sql Tuning Advisor 进行sql 自动调优

 如何使用oracle 的DBMS_SQLTUNE package 来运行 Sql Tuning Advisor 进行sql 自动调优 1>.这里简单举个例子来说明DBMS_SQLTUNE 的使用 首先现执行下某个想要调优的sql,然后获取sqlid SQL> select * from v$sqltext where sql_text like 'select * from dual%'; ADDRESS          HASH_VALUE SQL_ID        COMMAND

SQL Server调优系列玩转篇二(如何利用汇聚联合提示(Hint)引导语句运行)

原文:SQL Server调优系列玩转篇二(如何利用汇聚联合提示(Hint)引导语句运行) 前言 上一篇我们分析了查询Hint的用法,作为调优系列的最后一个玩转模块的第一篇.有兴趣的可以点击查看:SQL Server调优系列玩转篇(如何利用查询提示(Hint)引导语句运行) 本篇继续玩转模块的内容,同样,还是希望扎实掌握前面一系列的内容,才进入本模块的内容分析. 闲言少叙,进入本篇的内容. 技术准备 数据库版本为SQL Server2012,利用微软的以前的案例库(Northwind)进行分析,

SQL Server调优系列进阶篇(深入剖析统计信息)

前言 经过前几篇的分析,其实大体已经初窥到SQL Server统计信息的重要性了,所以本篇就要祭出这个神器了. 该篇内容会很长,坐好板凳,瓜子零食之类... 不废话,进正题 技术准备 数据库版本为SQL Server2008R2,利用微软的以前的案例库(Northwind)进行分析,部分内容也会应用微软的另一个案例库AdventureWorks 相信了解SQL Server的朋友,对这两个库都不会太陌生. 概念理解 关于SQL Server中的统计信息,在联机丛书中是这样解释的 查询优化的统计信

SQL Server调优系列基础篇

前言 关于SQL Server调优系列是一个庞大的内容体系,非一言两语能够分析清楚,本篇先就在SQL 调优中所最常用的查询计划进行解析,力图做好基础的掌握,夯实基本功!而后再谈谈整体的语句调优. 通过本篇了解如何阅读和理解查询计划.并且列举一系列最常用的查询执行运算符. 技术准备 基于SQL Server2008R2版本,利用微软的一个更简洁的案例库(Northwind)进行解析. 一.区别不同的运算符 在所有T-SQL语句在执行的时候,都会将语句分解为一些基本的结构单元,这些结构单元统称为:运

SQL性能调优

部分转自:http://www.cnblogs.com/luckybird/archive/2012/06/11/2544753.html 及http://www.cnblogs.com/kissdodog/p/3160560.html 着色部分为实际解决问题的过程 最常见的索引问题查找: 1.检查实际执行计划,使用图形化或者在执行语句前增加 set statistics profile on 检查其中操作行数/执行次数/执行时间最多的地方 2.在发现问题的地方,检查表的索引情况,注意其中Row

SQL Server调优系列进阶篇(如何索引调优)

前言 上一篇我们分析了数据库中的统计信息的作用,我们已经了解了数据库如何通过统计信息来掌控数据库中各个表的内容分布.不清楚的童鞋可以点击参考. 作为调优系列的文章,数据库的索引肯定是不能少的了,所以本篇我们就开始分析这块内容,关于索引的基础知识就不打算深入分析了,网上一搜一片片的,本篇更侧重的是一些实战项内容展示,希望通过本篇文章各位看官能在真正的场景中找到合适的解决方法足以. 对于索引的使用,我希望的是遇到问题找到合适的解决方法就可以,切勿乱用!!! 本篇在分析出索引的优越性的同时也将负面影响

SQL Server调优系列基础篇(并行运算总结)

原文:SQL Server调优系列基础篇(并行运算总结) 前言 上三篇文章我们介绍了查看查询计划的方式,以及一些常用的连接运算符.联合运算符的优化技巧. 本篇我们分析SQL Server的并行运算,作为多核计算机盛行的今天,SQL Server也会适时调整自己的查询计划,来适应硬件资源的扩展,充分利用硬件资源,最大限度的提高性能. 闲言少叙,直接进入本篇的正题. 技术准备 同前几篇一样,基于SQL Server2008R2版本,利用微软的一个更简洁的案例库(Northwind)进行解析. 一.并

SQL Server调优系列基础篇(索引运算总结)

原文:SQL Server调优系列基础篇(索引运算总结) 前言 上几篇文章我们介绍了如何查看查询计划.常用运算符的介绍.并行运算的方式,有兴趣的可以点击查看. 本篇将分析在SQL Server中,如何利用先有索引项进行查询性能优化,通过了解这些索引项的应用方式可以指导我们如何建立索引.调整我们的查询语句,达到性能优化的目的. 闲言少叙,进入本篇的正题. 技术准备 基于SQL Server2008R2版本,利用微软的一个更简洁的案例库(Northwind)进行解析. 简介 所谓的索引应用就是在我们

SQL Server调优系列进阶篇(如何维护数据库索引)

原文:SQL Server调优系列进阶篇(如何维护数据库索引) 前言 上一篇我们研究了如何利用索引在数据库里面调优,简要的介绍了索引的原理,更重要的分析了如何选择索引以及索引的利弊项,有兴趣的可以点击查看. 本篇延续上一篇的内容,继续分析索引这块,侧重索引项的日常维护以及一些注意事项等. 闲言少叙,进入本篇的主题. 技术准备 数据库版本为SQL Server2012,前几篇文章用的是SQL Server2008RT,内容区别不大,利用微软的以前的案例库(Northwind)进行分析,部分内容也会