STA(SQL Tuning Advisor) SQL调优顾问简介

原文转自:http://blog.csdn.net/tianlesoftware/article/details/5630888

在Oracle10g之前,优化SQL是个比较费力的技术活,不停的分析执行计划,加hint,分析统计信息等等。在10g中,Oracle推出了自己的SQL优化辅助工具: SQL优化器(SQL Tuning Advisor :STA),它是新的DBMS_SQLTUNE包。使用STA一定要保证优化器是CBO模式下。

执行DBMS_SQLTUNE包进行sql优化需要有advisor的权限:

SQL> create user dave identified by dave;

用户已创建。

SQL> grant connect,resource to dave;

授权成功。

SQL> grant advisor to dave;

授权成功。

下面简单介绍一下如何优化一条找到的问题语句。

create table bigtab as select rownum as "id",a.* from sys.all_objects a;

create table smalltab as select rownum as "id", a.* FROM sys.all_tables a;

然后多运行几次下面的脚本,增加表里的数据:

insert into bigtab select rownum as "id",a.* from sys.all_objects a;

insert into smalltab  select rownum as "id", a.* FROM sys.all_tables a;

这里创建一张大表和一张小表,并且都没有索引,下面执行一个查询:

SQL> set timing on

SQL> set autot on

SQL> select count(*) from bigtab a, smalltab b where a.object_name=b.table_name;

  COUNT(*)

----------

   2141537

已用时间:  00: 00: 20.05

执行计划

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

Plan hash value: 3089226980

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

| Id  | Operation           | Name     | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT    |          |     1 |    45 |  3146   (1)| 00:00:38 |

|   1 |  SORT AGGREGATE     |          |     1 |    45 |            |          |

|*  2 |   HASH JOIN         |          |   447K|    19M|  3146   (1)| 00:00:38 |

|   3 |    TABLE ACCESS FULL| SMALLTAB | 27327 |   533K|   264   (1)| 00:00:04 |

|   4 |    TABLE ACCESS FULL| BIGTAB   |   712K|    16M|  2878   (1)| 00:00:35 |

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

Predicate Information (identified by operation id):

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

   2 - access("A"."OBJECT_NAME"="B"."TABLE_NAME")

统计信息

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

          0  recursive calls

          0  db block gets

      31149  consistent gets

      21058  physical reads

          0  redo size

        426  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

第一步:创建优化任务

通过调用函数CREATE_TUNING_TASK来创建优化任务,调用存储过程EXECUTE_TUNING_TASK执行该任务:

SQL> set autot off

SQL> set timing off

SQL> DECLARE

  2    my_task_name VARCHAR2(30);

  3    my_sqltext   CLOB;

  4  BEGIN

  5    my_sqltext := 'select count(*) from bigtab a, smalltab b where a.object_name=b.table_name';

  6    my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(

  7            sql_text    => my_sqltext,

  8            user_name   => 'DAVE',   -- 注意是大写,不然会报错,用户无效

  9            scope       => 'COMPREHENSIVE',

10            time_limit  => 60,

11            task_name   => 'tuning_sql_test',

12            description => 'Task to tune a query on a specified table');

13

14    DBMS_SQLTUNE.EXECUTE_TUNING_TASK( task_name => 'tuning_sql_test');

15  END;

16  /

 

PL/SQL procedure successfully completed.

在函数CREATE_TUNING_TASK,sql_text是需要优化的语句,user_name是该语句通过哪个用户执行,scope是优化范围(limited或comprehensive),time_limit优化过程的时间限制,task_name优化任务名称,description优化任务描述。

第二步: 执行优化任务

通过调用dbms_sqltune.execute_tuning_task过程来执行前面创建好的优化任务。

SQL> exec dbms_sqltune.execute_tuning_task('tuning_sql_test');

PL/SQL 过程已成功完成。

第三步:检查优化任务的状态

通过查看user_advisor_tasks/dba_advisor_tasks视图可以查看优化任务的当前状态。

SQL> SELECT task_name,status FROM USER_ADVISOR_TASKS WHERE task_name ='tuning_sql_test';

TASK_NAME         STATUS

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

tuning_sql_test         COMPLETED

步:查看优化结果

通过dbms_sqltune.report_tning_task函数可以获得优化任务的结果。

SQL> SET LONG 999999

SQL> set serveroutput on size 999999

SQL> SET LINESIZE 100

SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK( 'tuning_sql_test') from DUAL;
 

DBMS_SQLTUNE.REPORT_TUNING_TASK('TUNING_SQL_TEST')

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

GENERAL INFORMATION SECTION

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

Tuning Task Name                  : tuning_sql_test

Tuning Task Owner                 : DEMO

Scope                             : COMPREHENSIVE

Time Limit(seconds)               : 60

Completion Status                 : COMPLETED

Started at                        : 5/28/2010 13:16:43

Completed at                      : 5/28/2010 13:16:44

Number of Index Findings          : 1

 

Schema Name: DEMO

SQL ID     : 6p64dnnsqf9pm

SQL Text   : select count(*) from bigtab a, smalltab b where

             a.object_name=b.table_name

 

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

FINDINGS SECTION (1 finding)

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

 

1- Index Finding (see explain plans section below)

 

  The execution plan of this statement can be improved by creating one or more

  indices.

 

  Recommendation (estimated benefit: 100%)

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

  - Consider running the Access Advisor to improve the physical schema design

    or creating the recommended index.

    create index DEMO.IDX$$_06C50001 on SYS.SMALLTAB('TABLE_NAME');

 

  - Consider running the Access Advisor to improve the physical schema design

    or creating the recommended index.

    create index DEMO.IDX$$_06C50002 on SYS.BIGTAB('OBJECT_NAME');

 

  Rationale

  ---------

    Creating the recommended indices significantly improves the execution plan

    of this statement. However, it might be preferable to run "Access Advisor"

    using a representative SQL workload as opposed to a single statement. This

    will allow to get comprehensive index recommendations which takes into

    account index maintenance overhead and additional space consumption.

 

 

EXPLAIN PLANS SECTION

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

1- Original

-----------

Plan hash value: 3089226980

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

| Id  | Operation           | Name     | Rows  | Bytes | Cost (%CPU)| Time     |

 

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

|   0 | SELECT STATEMENT    |          |     1 |    36 |  3550   (2)| 00:00:43 |

|   1 |  SORT AGGREGATE     |          |     1 |    36 |            |          |

|*  2 |   HASH JOIN         |          |   155K|  5462K|  3550   (2)| 00:00:43 |

|   3 |    TABLE ACCESS FULL| SMALLTAB |  1223 | 22014 |    11   (0)| 00:00:01 |

|   4 |    TABLE ACCESS FULL| BIGTAB   |  1205K|    20M|  3526   (1)| 00:00:43 |

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

Predicate Information (identified by operation id):

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

   2 - access("A"."OBJECT_NAME"="B"."TABLE_NAME")

2- Using New Indices

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

Plan hash value: 494801882

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

| Id  | Operation              | Name           | Rows  | Bytes | Cost (%CPU)| Time     |

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

|   0 | SELECT STATEMENT       |                |     1 |    36 |  1108   (3)| 00:00:14 |

|   1 |  SORT AGGREGATE        |                |     1 |    36 |            |        |

|*  2 |   HASH JOIN            |                |   155K|  5462K|  1108   (3)| 00:00:14 |

|   3 |    INDEX FAST FULL SCAN| IDX$$_06C50001 |  1223 | 22014 |     3   (0)| 00:00:01 |

|   4 |    INDEX FAST FULL SCAN| IDX$$_06C50002 |  1205K|    20M|  1093   (2)| 00:00:14 |

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

Predicate Information (identified by operation id):

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

   2 - access("A"."OBJECT_NAME"="B"."TABLE_NAME")

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

看一下这个优化建议报告:

第一部分是关于这次优化任务的基本信息:如任务名称、执行时间、范围、涉及到的语句等等。

第二部分是关于这次优化任务的所找到的问题以及给出的优化建议。前面先给出了问题描述:可以通过建立更多的所引来提高性能;然后是建议的具体内容:在表smalltab的字段table_name上创建索引,在表bigtab的字段object_name上创建索引;最后是相关注意事项:此次优化虽然给出了创建索引的建议,但是最好通过SQL访问建议器(SQL Access Advisor SAA)结合整个数据库的工作量来深入分析,那样就能给出考虑了索引维护和空间消耗等因素的更加合理的建议。

最后,报告还给出了原有的查询计划,以及采用优化建议以后的查询计划的对比。可以看出COST值大大下降。

五、删除优化任务

通过调用dbms_sqltuen.drop_tuning_task可以删除已经存在的优化任务

SQL>exec dbms_sqltune.drop_tuning_task('tuning_sql_test');
PL/SQL procedure successfully completed.

时间: 2024-09-17 04:10:01

STA(SQL Tuning Advisor) SQL调优顾问简介的相关文章

深入了解SQL Tuning Advisor

1.前言:一直以来SQL调优都是DBA比较费力的技术活,而且很多DBA如果没有从事过开发的工作,那么调优更是一项头疼的工作,即使是SQL调优很厉害的高手,在SQL调优的过程中也要不停的分析执行计划.加HINT.分析统计信息等等.从ORACLE 10G开始,数据库采取了很多智能化的管理工作,其中SQL优化器(SQL Tuning Advisor:STA),大大的提高了DBA进行SQL优化的效率:   2.原理介绍: When SQL statements are executed by the O

使用SQL tuning advisor(STA)自动优化SQL

      Oracle 10g之后的优化器支持两种模式,一个是normal模式,一个是tuning模式.在大多数情况下,优化器处于normal模式.基于CBO的normal模式只考虑很小部分的执行计划集合用于选择哪个执行计划,因为它需要在尽可能短的时间,通常是几秒或毫秒级来对当前的SQL语句进行解析并生成执行计划.因此并不能保证SQL语句每次都是使用最佳的执行计划.而tuning模式则将高负载的SQL语句直接扔给优化器,优化器来自动对其进行详细的分析,调试并给出建议,这就是Oracle 提供的

Oracle中SQL Tuning Advisor的使用实例

在oracle10g之前,想要优化一个sql语句是比较麻烦,但是在oracle10g这个版本推出的SQL Tuning Advisor这个工具,能大大减少sql调优的工作量,不过要想使用SQL Tuning Advisor,一定要保证你的 优化器是CBO模式. 1.首先需要创建一个用于调优的用户bamboo,并授予advisor给创建的用户 SQL> create user bamboo identified by bamboo; User created. SQL> grant connec

Oracle智能之SQL诊断:SQL Tuning Advisor推荐执行计划

编辑手记:在前一段,一篇智能数据库优化的论文引起广泛的关注,其实在 Oracle 数据库中,已经引入了大量自动化和智能化的方法去进行自动调节,包括在 SQL 层面的智能诊断分析和建议. 张大朋(Lunar)Oracle 资深技术专家 Lunar 拥有超过十年的 ORACLE SUPPORT 从业经验,曾经服务于ORACLE ACS部门,现就职于 ORACLE Sales Consultant 部门,负责的产品主要是 Exadata,Golden Gate,Database 等. 本文的测试目的,

Begin automatic SQL Tuning Advisor run for special tuning task "SYS_AUTO_SQL_TUNING_TASK"

hu May 29 22:00:00 2014 Setting Resource Manager plan SCHEDULER[0x310A]:DEFAULT_MAINTENANCE_PLAN via scheduler window Setting Resource Manager plan DEFAULT_MAINTENANCE_PLAN via parameter Thu May 29 22:00:00 2014 Starting background process VKRM Thu M

[20130626]11GR2 SQL Tuning Advisor.txt

[20130626]11GR2 SQL Tuning Advisor.txt 11GR2加入了sql tuning advisor,缺省是打开的,我发现一些dba建议安装11G后,直接关闭它,好像因为消耗资源. SQL> @verBANNER--------------------------------------------------------------------------------Oracle Database 11g Enterprise Edition Release 11

快速定位隐蔽的sql性能问题及调优

在前几天,有个开发同事问我一个问题,其实也算是技术救援,他说在有个job数据处理的频率比较高,在测试环境中很难定位出在哪有问题,而且速度也还能接受,但是在生产环境中总是会慢一些,希望我能在测试环境中协助他们,看看是不是sql语句出什么问题了还是其它相关的问题. 这种类似实时监控的语句,从第一印象来说,很可能通过awr捕获不到,如果通过ash来捕获,因为测试环境中有几十套测试环境在运行,就算得到某个时间点的一些sql语句,直接在报告中映射到语句对应的schema信息还是有一些困难的.因为测试时间确

一条sql语句的建议调优分析

前几天开发的同事问我一个sql的问题,目前在测试环境中发现这条sql语句执行时间很长,希望我们能够给一些建议,能够尽快做一些改进.sql语句类似下面的形式.SELECT /*+ INDEX(ACCOUNT,ACCOUNT_PK)INDEX(ACCOUNT_EXT ACCOUNT_EXT_PK) */ ACCOUNT.ACCOUNT_ID, ACCOUNT.BE, ACCOUNT.CUSTOMER_NO, ACCOUNT.AR_BALANCE, ACCOUNT_EXT.CYCLE_CODE, AC

Hive Tuning(五) 标准调优清单

Hive的标准调优清单,我们可以对照着来做我们的查询优化!