Oracle 11g系统调优之dbms_sqltune包的使用

前沿：随着数据库版本的提升，Oracle也提供了越来越多的性能诊断工具，针对SQL的调优，DBMS_SQLTUNE就是其中一个比较优秀的包。
DBMS_SQLTUNE最开始是在10G里面出现，11G里面则对其进行了加强，使得其更加符合实际需求。

1.查找系统可能存在问题的SQL

一般什么样的SQL可能会存在性能问题呢？
我们第一时间能想到的肯定是执行时间很长的SQL、其次是IO很高的SQL，这里就针对执行时间很长的SQL来做测试。
获取类似的SQL有多种方法，AWR、ADDR、动态视图等，这里我们就通过动态视图v$session_longops来获取，因为这个视图里面的语句是最近执行的，有比较强的及时性。

以下语句可查询最近数据库中执行时间比较长的SQL，包括执行时间。

点击(此处)折叠或打开

 select tt1.sql_text,tt1.sql_fulltext,tt2.sql_id,tt2.sums
 from v$sqlarea tt1,
 (select sql_id,sum(elapsed_seconds) as sums
 from v$session_longops where opname=\'Table Scan\'
 group by sql_id
 ) tt2
 where tt1.sql_id=tt2.sql_id
 order by tt2.sums desc;

执行结果如下：


其中SUMS列为此SQL执行的总时间，上面我主要选取了‘Table Scan’这个类型的操作作为主要的时间损耗，从实际上来看也是如此，表扫描的方式直接关系SQL执行的效率，
表扫描占整个SQL执行时间的比重最大。

从上面，我们选取一条SQL，ID为“3c3ch9a4xdwn1”作为需要优化的SQL。


2.DBMS_SQLTUNE包
DBMS_SQLTUNE包提供了很多的子程序来对SQL进行诊断和对执行计划进行处理，这里我们只是简单的测试一下DBMS_SQLTUNE的调优功能，主要涉及到3个子过程。

DBMS_SQLTUNE.CREATE_TUNING_TASK    #创建一个SQL调优任务

DBMS_SQLTUNE.CREATE_TUNING_TASK(
  sql_id           IN VARCHAR2,                                             ---------->SQL ID，必填项
  plan_hash_value  IN NUMBER    := NULL,                           ----------->执行计划的HASN值(选填)
  scope            IN VARCHAR2  := SCOPE_COMPREHENSIVE,  ----------->任务类型，有limited和comprehensive两种
  time_limit       IN NUMBER    := TIME_LIMIT_DEFAULT,       ----------->此任务最长的执行时间
  task_name        IN VARCHAR2  := NULL,                           ----------->任务名
  description      IN VARCHAR2  := NULL)                             ----------->任务描述
RETURN VARCHAR2;

EXECUTE_TUNING_TASK                              #执行一个SQL调优任务

DBMS_SQLTUNE.EXECUTE_TUNING_TASK(
   task_name         IN VARCHAR2,                                      ------------>任务名
   execution_name    IN VARCHAR2               := NULL,         ------------>执行时的名称，可为空
   execution_params  IN dbms_advisor.argList   := NULL,        ------------>执行参数，默认可为空
   execution_desc    IN VARCHAR2               := NULL);         ------------>执行描述

DROP_TUNING_TASK                                   #删除一个SQL调优任务

DBMS_SQLTUNE.DROP_TUNING_TASK(
 task_name         IN VARCHAR2);                                      ------------->任务名


ACCEPT_SQL_PROFILE                               #接受及应用一个SQL_PROFILE执行计划给某条SQL

DBMS_SQLTUNE.ACCEPT_SQL_PROFILE (
   task_name    IN  VARCHAR2,                                         -------------->执行优化的任务名
   object_id    IN  NUMBER   := NULL,                                -------------->对象编号，一般不填
   name         IN  VARCHAR2 := NULL,                               -------------->制定的sql_profile名称，如果不填则由系统指派
   description  IN  VARCHAR2 := NULL,                               -------------->该执行计划的描述信息
   category     IN  VARCHAR2 := NULL);                              ------------->需要与该SESSION的sqltune_category参数相匹配
   task_owner   IN VARCHAR2  := NULL,                             ------------->任务的所有者
   replace      IN BOOLEAN   := FALSE,                               ------------->如果此sql_profile已存在，则决定是否替换，默认值为不替换
   force_match  IN BOOLEAN   := FALSE,                           ------------->是否强制匹配此执行计划与所有HASH值相同的SQL，类似CURSOR_SHARING参数的FORCE
   profile_type IN VARCHAR2  := REGULAR_PROFILE);          ------------->sql_profile的类型，默认为REGULAR_PROFILE，可修改为PX_PROFILE，表示此执行计划变更为并行执行


DROP_SQL_PROFILE                                     #删除一个SQL_PROFILE的应用，让系统自动选择

DBMS_SQLTUNE.DROP_SQL_PROFILE (
   name          IN  VARCHAR2,
   ignore        IN  BOOLEAN  := FALSE);



3.具体演示过程

SQL Profile是10g中的新特性，作为自动SQL调整过程的一部分，由Oracle企业管理器来管理。除了OEM，SQL Profile可以通过DBMS_SQLTUNE包来进行管理。

查询优化器有时候会因为缺乏足够的信息，而对一条SQL语句做出错误的估计，生成糟糕的执行计划。而自动SQL调整通过SQL概要分析来解决这个问题，自动调整优化器会生成这条SQL语句的一个概要，称作SQL Profile。它由针对这条语句的一些辅助统计信息组成，通过采样和局部执行技术来确认，必要的话，会调整执行计划中的估计值。在SQL概要分析中，自 动调整优化器还可以通过一条SQL语句的执行历史信息来设置合适的优化器参数，比如将OPTIMIZER_MODE参数由ALL_ROWS改为 FIRST_ROWS。

换句话说，SQL概要是一个对象，它包含了可以帮助查询优化器为一个特定的SQL语句找到高效执行计划的信息。这些信息包括执行环境、对象统计和对查询优 化器所做评估的修正信息。它的最大优点之一就是在不修改SQL语句和会话执行环境的情况下影响查询优化器的决定。(《Oracle性能诊断艺术》)

SQL Profile中包含的并非单个执行计划的信息，必须注意的是，SQL Profile不会固定一个SQL语句的执行计划。当表的数据增长或者索引创建、删除，使用同一个SQL Profile的执行计划可能会改变，而储存在SQL Profile中的信息会继续起作用。然而，经过一段很长的时间之后，它的信息有可能会过时，需要重新生成。

SQL Profile的作用范围由CATEGORY属性来控制，这个属性决定了哪些用户会话可以应用这个概要。你可以从DBA_SQL_PROFILES中的 CATEGORY字段来查看这个属性。默认情况下，所有概要文件都创建为DEFAULT范畴，这意味着所有SQLTUNE_CATEGORY初始化参数为 DEFAULT的用户会话都可以使用这个概要。你可以修改这个属性，比如将其改为DEV，则SQLTUNE_GATEGORY参数为DEV的用户会话才能 使用它，利用这个功能，你可以在一个受限制的环境中来测试一个SQL Profile。

简单来说，Sql_Profile是用来影响数据库执行计划生成的一组信息文件的集合，可以在不改变原有SQL语句的前提下，达到类似HINTS改变其执行计划的目的。


创建一个sqltune的调优任务(即创建sql_profile的相关信息)

点击(此处)折叠或打开

 DECLARE
 my_task_name VARCHAR2(30);
 BEGIN
    my_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(
                      sql_id => \'c7py7dtaxnsjm\',
                      scope => \'COMPREHENSIVE\',
                      time_limit => 3600,
                      task_name => \'test_falist_tuning_task1\',
                      description => \'Task to tune a query\');
    DBMS_SQLTUNE.EXECUTE_TUNING_TASK(task_name => \'test_falist_tuning_task1\');
 END;

记住，DBMS_SQLTUNE.CREATE_TUNING_TASK是一个函数，必须要有返回值。
上面在定义了一个TASK后，可通过DBMS_SQLTUNE.EXECUTE_TUNING_TASK来执行此调优过程。


获取调优任务的详细信息

点击(此处)折叠或打开

 select dbms_sqltune.report_tuning_task(\'test_falist_tuning_task1\') from dual;

可通过dbms_sqltune.report_tuning_task，输入任务名，及可获取调优的相关信息，如下：

点击(此处)折叠或打开

 GENERAL INFORMATION SECTION
 -------------------------------------------------------------------------------
 Tuning Task Name : test_falist_tuning_task1
 Tuning Task Owner : BOLAN
 Workload Type : Single SQL Statement
 Scope : COMPREHENSIVE
 Time Limit(seconds): 3600
 Completion Status : COMPLETED
 Started at : 03/16/2015 21:03:11
 Completed at : 03/16/2015 21:04:04

 -------------------------------------------------------------------------------
 Schema Name: BOLAN
 SQL ID : b950haw425cq7
 SQL Text : SELECT C.*,D.CONTENT FROM (SELECT OBJECTID, TITLE, EDITTIME,
 SUBSTR(INTRO, :\"SYS_B_0\", :\"SYS_B_1\") || :\"SYS_B_2\" AS INTRO,
 KEYNAME, R
 FROM (SELECT FIE_FINANCECONTENT.OBJECTID,
 FIE_FINANCECONTENT.TITLE,
 TO_CHAR(FIE_FINANCECONTENT.DISPLAYTIME,
 :\"SYS_B_3\") AS EDITTIME,
 FIE_FINANCECONTENT.INTRO,
 BASE_OBJKEY.KEYNAME,
 ROW_NUMBER() OVER(PARTITION BY
 BASE_OBJKEY.KEYNAME ORDER BY FIE_FINANCECONTENT.DISPLAYTIME
 DESC) R
 FROM FIE_FINANCECONTENT
 INNER JOIN BASE_OBJ
 ON FIE_FINANCECONTENT.OBJECTID = BASE_OBJ.OBJECTID
 INNER JOIN BASE_OBJKEY
 ON BASE_OBJ.OBJECTID = BASE_OBJKEY.OBJECTID
 left join base_cateobj
 on base_cateobj.objectid = BASE_OBJKEY.OBJECTID
 WHERE BASE_OBJ.STATUS = :\"SYS_B_4\"
 AND (base_cateobj.CATEGORYID LIKE :\"SYS_B_5\" OR
 base_cateobj.CATEGORYID LIKE :\"SYS_B_6\")
 AND BASE_OBJKEY.SECURITYID IS NOT NULL
 ORDER BY FIE_FINANCECONTENT.DISPLAYTIME DESC) B
 WHERE R < :\"SYS_B_7\")C
 INNER JOIN FIE_OBJCONTENT D
 ON C.OBJECTID =D.OBJECTID
 Bind Variables :
 5 - (VARCHAR2(32)):4
 6 - (VARCHAR2(32)):000200010022%
 7 - (VARCHAR2(32)):000100020008%
 8 - (NUMBER):11

 -------------------------------------------------------------------------------
 FINDINGS SECTION (1 finding)
 -------------------------------------------------------------------------------

 1- SQL Profile Finding (see explain plans section below)
 --------------------------------------------------------
 为此语句找到了性能更好的执行计划 2。选择以下 SQL 概要文件之一进行实施。

 Recommendation (estimated benefit: 75.32%)
  ------------------------------------------
 - 考虑接受推荐的 SQL 概要文件。
  execute dbms_sqltune.accept_sql_profile(task_name =>
  \'test_falist_tuning_task1\', task_owner => \'BOLAN\', replace =>
  TRUE);

  Recommendation (estimated benefit: 99.89%)
  ------------------------------------------
  - 考虑接受建议的 SQL 概要文件, 以便对此语句使用并行执行。
  execute dbms_sqltune.accept_sql_profile(task_name =>
  \'test_falist_tuning_task1\', task_owner => \'BOLAN\', replace =>
  TRUE, profile_type => DBMS_SQLTUNE.PX_PROFILE);

 与 DOP 64 并行执行此查询会使 SQL 概要文件计划上的响应时间缩短 99.56%。但是, 启用并行执行时要付出一些代价。它将增加语句的资源消耗
 (预计为 72.07%), 这会导致系统吞吐量降低。此外, 由于在非常短的持续时间内消耗了这些资源, 因此如果没有足够可用的硬件容量,
 并发语句的响应时间将受到负面影响。

 The following data shows some sampled statistics for this SQL from the past
 week and projected weekly values when parallel execution is enabled.

 Past week sampled statistics for this SQL
 -----------------------------------------
 Number of executions 0
 Percent of total activity 0
 Percent of samples with #Active Sessions > 2*CPU 0
 Weekly DB time (in sec) 0

 Projected statistics with Parallel Execution
 --------------------------------------------
 Weekly DB time (in sec) 0

 -------------------------------------------------------------------------------
 ADDITIONAL INFORMATION SECTION
 -------------------------------------------------------------------------------
 - 优化程序不能合并位于执行计划的行 ID 2 处的视图。. 优化程序不能合并包含窗口函数的视图。.

 -------------------------------------------------------------------------------
 EXPLAIN PLANS SECTION
 -------------------------------------------------------------------------------

 1- Original With Adjusted Cost
 ------------------------------
 Plan hash value: 3849921461

 -----------------------------------------------------------------------------------------------------------
 | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
 -----------------------------------------------------------------------------------------------------------
 | 0 | SELECT STATEMENT | | 19M| 29G| | 4732K (1)| 15:46:36 |
 |* 1 | HASH JOIN | | 19M| 29G| 17G| 4732K (1)| 15:46:36 |
 |* 2 | VIEW | | 19M| 17G| | 3591K (1)| 11:58:18 |
 | 3 | SORT ORDER BY | | 19M| 6717M| 7046M| 3591K (1)| 11:58:18 |
 |* 4 | WINDOW SORT PUSHED RANK | | 19M| 6717M| 7046M| 3591K (1)| 11:58:18 |
 |* 5 | HASH JOIN | | 19M| 6717M| 3462M| 583K (1)| 01:56:43 |
 |* 6 | HASH JOIN | | 20M| 3223M| 3186M| 356K (1)| 01:11:22 |
 |* 7 | FILTER | | | | | | |
 |* 8 | HASH JOIN OUTER | | 24M| 2903M| 61M| 136K (2)| 00:27:24 |
 |* 9 | TABLE ACCESS FULL | BASE_OBJKEY | 1049K| 49M| | 21955 (1)| 00:04:24 |
 | 10 | INDEX FAST FULL SCAN| PK_BASE_CATEOBJ | 14M| 1048M| | 49157 (1)| 00:09:50 |
 |* 11 | TABLE ACCESS FULL | BASE_OBJ | 2650K| 98M| | 55175 (1)| 00:11:03 |
 | 12 | TABLE ACCESS FULL | FIE_FINANCECONTENT | 2345K| 431M| | 32203 (1)| 00:06:27 |
 | 13 | TABLE ACCESS FULL | FIE_OBJCONTENT | 4208K| 2600M| | 134K (1)| 00:26:57 |
 -----------------------------------------------------------------------------------------------------------

 Predicate Information (identified by operation id):
 ---------------------------------------------------

 1 - access(\"OBJECTID\"=\"D\".\"OBJECTID\")
 2 - filter(\"R\"<:sys_b_7>
 4 - filter(ROW_NUMBER() OVER ( PARTITION BY \"BASE_OBJKEY\".\"KEYNAME\" ORDER BY
 INTERNAL_FUNCTION(\"FIE_FINANCECONTENT\".\"DISPLAYTIME\") DESC )<:sys_b_7>
 5 - access(\"FIE_FINANCECONTENT\".\"OBJECTID\"=\"BASE_OBJ\".\"OBJECTID\")
 6 - access(\"BASE_OBJ\".\"OBJECTID\"=\"BASE_OBJKEY\".\"OBJECTID\")
 7 - filter(\"BASE_CATEOBJ\".\"CATEGORYID\" LIKE :SYS_B_5 OR \"BASE_CATEOBJ\".\"CATEGORYID\" LIKE
 :SYS_B_6)
 8 - access(\"BASE_CATEOBJ\".\"OBJECTID\"(+)=\"BASE_OBJKEY\".\"OBJECTID\")
 9 - filter(\"BASE_OBJKEY\".\"SECURITYID\" IS NOT NULL)
 11 - filter(\"BASE_OBJ\".\"STATUS\"=:SYS_B_4)

 2- Using SQL Profile
 --------------------
 Plan hash value: 770845823

 ----------------------------------------------------------------------------------------------------------
 | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time |
 ----------------------------------------------------------------------------------------------------------
 | 0 | SELECT STATEMENT | | 2998K| 4486M| | 1167K (1)| 03:53:33 |
 |* 1 | HASH JOIN | | 2998K| 4486M| 2648M| 1167K (1)| 03:53:33 |
 | 2 | TABLE ACCESS FULL | FIE_OBJCONTENT | 4208K| 2600M| | 134K (1)| 00:26:57 |
 |* 3 | VIEW | | 2997K| 2632M| | 769K (1)| 02:33:53 |
 | 4 | SORT ORDER BY | | 2997K| 1014M| | 769K (1)| 02:33:53 |
 |* 5 | WINDOW SORT PUSHED RANK | | 2997K| 1014M| | 769K (1)| 02:33:53 |
 | 6 | CONCATENATION | | | | | | |
 |* 7 | FILTER | | | | | | |
 |* 8 | HASH JOIN OUTER | | 119K| 40M| 278M| 270K (1)| 00:54:01 |
 |* 9 | HASH JOIN | | 997K| 267M| 100M| 146K (1)| 00:29:19 |
 |* 10 | HASH JOIN | | 1049K| 88M| 61M| 86580 (1)| 00:17:19 |
 |* 11 | TABLE ACCESS FULL | BASE_OBJKEY | 1049K| 49M| | 21955 (1)| 00:04:24 |
 |* 12 | TABLE ACCESS FULL | BASE_OBJ | 2650K| 98M| | 55175 (1)| 00:11:03 |
 | 13 | TABLE ACCESS FULL | FIE_FINANCECONTENT | 2345K| 431M| | 32203 (1)| 00:06:27 |
 | 14 | INDEX FAST FULL SCAN| PK_BASE_CATEOBJ | 14M| 1048M| | 49157 (1)| 00:09:50 |
 |* 15 | FILTER | | | | | | |
 |* 16 | HASH JOIN OUTER | | 2878K| 974M| 278M| 270K (1)| 00:54:01 |
 |* 17 | HASH JOIN | | 997K| 267M| 100M| 146K (1)| 00:29:19 |
 |* 18 | HASH JOIN | | 1049K| 88M| 61M| 86580 (1)| 00:17:19 |
 |* 19 | TABLE ACCESS FULL | BASE_OBJKEY | 1049K| 49M| | 21955 (1)| 00:04:24 |
 |* 20 | TABLE ACCESS FULL | BASE_OBJ | 2650K| 98M| | 55175 (1)| 00:11:03 |
 | 21 | TABLE ACCESS FULL | FIE_FINANCECONTENT | 2345K| 431M| | 32203 (1)| 00:06:27 |
 | 22 | INDEX FAST FULL SCAN| PK_BASE_CATEOBJ | 14M| 1048M| | 49157 (1)| 00:09:50 |
 ----------------------------------------------------------------------------------------------------------

 Predicate Information (identified by operation id):
 ---------------------------------------------------

 1 - access(\"OBJECTID\"=\"D\".\"OBJECTID\")
 3 - filter(\"R\"<:sys_b_7>
 5 - filter(ROW_NUMBER() OVER ( PARTITION BY \"BASE_OBJKEY\".\"KEYNAME\" ORDER BY
 INTERNAL_FUNCTION(\"FIE_FINANCECONTENT\".\"DISPLAYTIME\") DESC )<:sys_b_7>
 7 - filter(\"BASE_CATEOBJ\".\"CATEGORYID\" LIKE :SYS_B_6)
 8 - access(\"BASE_CATEOBJ\".\"OBJECTID\"(+)=\"BASE_OBJKEY\".\"OBJECTID\")
 9 - access(\"FIE_FINANCECONTENT\".\"OBJECTID\"=\"BASE_OBJ\".\"OBJECTID\")
 10 - access(\"BASE_OBJ\".\"OBJECTID\"=\"BASE_OBJKEY\".\"OBJECTID\")
 11 - filter(\"BASE_OBJKEY\".\"SECURITYID\" IS NOT NULL)
 12 - filter(\"BASE_OBJ\".\"STATUS\"=:SYS_B_4)
 15 - filter(\"BASE_CATEOBJ\".\"CATEGORYID\" LIKE :SYS_B_5 AND LNNVL(\"BASE_CATEOBJ\".\"CATEGORYID\"
 LIKE :SYS_B_6))
 16 - access(\"BASE_CATEOBJ\".\"OBJECTID\"(+)=\"BASE_OBJKEY\".\"OBJECTID\")
 17 - access(\"FIE_FINANCECONTENT\".\"OBJECTID\"=\"BASE_OBJ\".\"OBJECTID\")
 18 - access(\"BASE_OBJ\".\"OBJECTID\"=\"BASE_OBJKEY\".\"OBJECTID\")
 19 - filter(\"BASE_OBJKEY\".\"SECURITYID\" IS NOT NULL)
 20 - filter(\"BASE_OBJ\".\"STATUS\"=:SYS_B_4)

 3- Using Parallel Execution
 ---------------------------
 Plan hash value: 89272180

 --------------------------------------------------------------------------------------------------------------------------------------------------------
 | Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU)| Time | TQ |IN-OUT| PQ Distrib |
 --------------------------------------------------------------------------------------------------------------------------------------------------------
 | 0 | SELECT STATEMENT | | 146K| 219M| | 5095 (1)| 00:01:02 | | | |
 | 1 | PX COORDINATOR | | | | | | | | | |
 | 2 | PX SEND QC (RANDOM) | :TQ10010 | 146K| 219M| | 5095 (1)| 00:01:02 | Q1,10 | P->S | QC (RAND) |
 |* 3 | HASH JOIN BUFFERED | | 146K| 219M| | 5095 (1)| 00:01:02 | Q1,10 | PCWP | |
 | 4 | JOIN FILTER CREATE | :BF0000 | 146K| 128M| | 2758 (1)| 00:00:34 | Q1,10 | PCWP | |
 | 5 | PX RECEIVE | | 146K| 128M| | 2758 (1)| 00:00:34 | Q1,10 | PCWP | |
 | 6 | PX SEND HASH | :TQ10008 | 146K| 128M| | 2758 (1)| 00:00:34 | Q1,08 | P->P | HASH |
 |* 7 | VIEW | | 146K| 128M| | 2758 (1)| 00:00:34 | Q1,08 | PCWP | |
 | 8 | SORT ORDER BY | | 146K| 49M| 1022M| 2758 (1)| 00:00:34 | Q1,08 | PCWP | |
 | 9 | PX RECEIVE | | 146K| 49M| | 2758 (1)| 00:00:34 | Q1,08 | PCWP | |
 | 10 | PX SEND RANGE | :TQ10007 | 146K| 49M| | 2758 (1)| 00:00:34 | Q1,07 | P->P | RANGE |
 |* 11 | WINDOW SORT | | 146K| 49M| 1022M| 2758 (1)| 00:00:34 | Q1,07 | PCWP | |
 | 12 | PX RECEIVE | | 146K| 49M| | 2758 (1)| 00:00:34 | Q1,07 | PCWP | |
 | 13 | PX SEND HASH | :TQ10006 | 146K| 49M| | 2758 (1)| 00:00:34 | Q1,06 | P->P | HASH |
 |* 14 | WINDOW CHILD PUSHED RANK | | 146K| 49M| | 2758 (1)| 00:00:34 | Q1,06 | PCWP | |
 |* 15 | FILTER | | | | | | | Q1,06 | PCWC | |
 |* 16 | HASH JOIN OUTER | | 146K| 49M| | 2753 (1)| 00:00:34 | Q1,06 | PCWP | |
 | 17 | PX RECEIVE | | 997K| 267M| | 1897 (1)| 00:00:23 | Q1,06 | PCWP | |
 | 18 | PX SEND HASH | :TQ10004 | 997K| 267M| | 1897 (1)| 00:00:23 | Q1,04 | P->P | HASH |
 |* 19 | HASH JOIN BUFFERED | | 997K| 267M| | 1897 (1)| 00:00:23 | Q1,04 | PCWP | |
 | 20 | JOIN FILTER CREATE | :BF0001 | 1049K| 88M| | 1338 (1)| 00:00:17 | Q1,04 | PCWP | |
 | 21 | PX RECEIVE | | 1049K| 88M| | 1338 (1)| 00:00:17 | Q1,04 | PCWP | |
 | 22 | PX SEND HASH | :TQ10002 | 1049K| 88M| | 1338 (1)| 00:00:17 | Q1,02 | P->P | HASH |
 |* 23 | HASH JOIN BUFFERED | | 1049K| 88M| | 1338 (1)| 00:00:17 | Q1,02 | PCWP | |
 | 24 | JOIN FILTER CREATE | :BF0002 | 1049K| 49M| | 381 (1)| 00:00:05 | Q1,02 | PCWP | |
 | 25 | PX RECEIVE | | 1049K| 49M| | 381 (1)| 00:00:05 | Q1,02 | PCWP | |
 | 26 | PX SEND HASH | :TQ10000 | 1049K| 49M| | 381 (1)| 00:00:05 | Q1,00 | P->P | HASH |
 | 27 | PX BLOCK ITERATOR | | 1049K| 49M| | 381 (1)| 00:00:05 | Q1,00 | PCWC | |
 |* 28 | TABLE ACCESS FULL| BASE_OBJKEY | 1049K| 49M| | 381 (1)| 00:00:05 | Q1,00 | PCWP | |
 | 29 | PX RECEIVE | | 2650K| 98M| | 957 (1)| 00:00:12 | Q1,02 | PCWP | |
 | 30 | PX SEND HASH | :TQ10001 | 2650K| 98M| | 957 (1)| 00:00:12 | Q1,01 | P->P | HASH |
 | 31 | JOIN FILTER USE | :BF0002 | 2650K| 98M| | 957 (1)| 00:00:12 | Q1,01 | PCWP | |
 | 32 | PX BLOCK ITERATOR | | 2650K| 98M| | 957 (1)| 00:00:12 | Q1,01 | PCWC | |
 |* 33 | TABLE ACCESS FULL| BASE_OBJ | 2650K| 98M| | 957 (1)| 00:00:12 | Q1,01 | PCWP | |
 | 34 | PX RECEIVE | | 2345K| 431M| | 558 (1)| 00:00:07 | Q1,04 | PCWP | |
 | 35 | PX SEND HASH | :TQ10003 | 2345K| 431M| | 558 (1)| 00:00:07 | Q1,03 | P->P | HASH |
 | 36 | JOIN FILTER USE | :BF0001 | 2345K| 431M| | 558 (1)| 00:00:07 | Q1,03 | PCWP | |
 | 37 | PX BLOCK ITERATOR | | 2345K| 431M| | 558 (1)| 00:00:07 | Q1,03 | PCWC | |
 |* 38 | TABLE ACCESS FULL | FIE_FINANCECONTENT | 2345K| 431M| | 558 (1)| 00:00:07 | Q1,03 | PCWP | |
 | 39 | PX RECEIVE | | 14M| 1048M| | 853 (1)| 00:00:11 | Q1,06 | PCWP | |
 | 40 | PX SEND HASH | :TQ10005 | 14M| 1048M| | 853 (1)| 00:00:11 | Q1,05 | P->P | HASH |
 | 41 | PX BLOCK ITERATOR | | 14M| 1048M| | 853 (1)| 00:00:11 | Q1,05 | PCWC | |
 | 42 | INDEX FAST FULL SCAN | PK_BASE_CATEOBJ | 14M| 1048M| | 853 (1)| 00:00:11 | Q1,05 | PCWP | |
 | 43 | PX RECEIVE | | 4208K| 2600M| | 2336 (1)| 00:00:29 | Q1,10 | PCWP | |
 | 44 | PX SEND HASH | :TQ10009 | 4208K| 2600M| | 2336 (1)| 00:00:29 | Q1,09 | P->P | HASH |
 | 45 | JOIN FILTER USE | :BF0000 | 4208K| 2600M| | 2336 (1)| 00:00:29 | Q1,09 | PCWP | |
 | 46 | PX BLOCK ITERATOR | | 4208K| 2600M| | 2336 (1)| 00:00:29 | Q1,09 | PCWC | |
 |* 47 | TABLE ACCESS FULL | FIE_OBJCONTENT | 4208K| 2600M| | 2336 (1)| 00:00:29 | Q1,09 | PCWP | |
 --------------------------------------------------------------------------------------------------------------------------------------------------------

 Predicate Information (identified by operation id):
 ---------------------------------------------------

 3 - access(\"OBJECTID\"=\"D\".\"OBJECTID\")
 7 - filter(\"R\"<:sys_b_7>
 11 - filter(ROW_NUMBER() OVER ( PARTITION BY \"BASE_OBJKEY\".\"KEYNAME\" ORDER BY INTERNAL_FUNCTION(\"FIE_FINANCECONTENT\".\"DISPLAYTIME\") DESC
 )<:sys_b_7>
 14 - filter(ROW_NUMBER() OVER ( PARTITION BY \"BASE_OBJKEY\".\"KEYNAME\" ORDER BY INTERNAL_FUNCTION(\"FIE_FINANCECONTENT\".\"DISPLAYTIME\") DESC
 )<:sys_b_7>
 15 - filter(\"BASE_CATEOBJ\".\"CATEGORYID\" LIKE :SYS_B_5 OR \"BASE_CATEOBJ\".\"CATEGORYID\" LIKE :SYS_B_6)
 16 - access(\"BASE_CATEOBJ\".\"OBJECTID\"(+)=\"BASE_OBJKEY\".\"OBJECTID\")
 19 - access(\"FIE_FINANCECONTENT\".\"OBJECTID\"=\"BASE_OBJ\".\"OBJECTID\")
 23 - access(\"BASE_OBJ\".\"OBJECTID\"=\"BASE_OBJKEY\".\"OBJECTID\")
 28 - filter(\"BASE_OBJKEY\".\"SECURITYID\" IS NOT NULL)
 33 - filter(\"BASE_OBJ\".\"STATUS\"=:SYS_B_4 AND SYS_OP_BLOOM_FILTER(:BF0002,\"BASE_OBJ\".\"OBJECTID\"))
 38 - filter(SYS_OP_BLOOM_FILTER(:BF0001,\"FIE_FINANCECONTENT\".\"OBJECTID\"))
 47 - filter(SYS_OP_BLOOM_FILTER(:BF0000,\"D\".\"OBJECTID\"))

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

重点关注红字部分，即为SQL_TUNE任务给出的调优建议，我们看到对于上面的语句，ORACLE建议其并行执行，下面也列出来了当前的执行计划和调整后的执行计划。


对上面的SQL_PROFILE进行应用

点击(此处)折叠或打开

 begin
 dbms_sqltune.accept_sql_profile(task_name =>
             \'test_falist_tuning_task1\', task_owner => \'BOLAN\', replace =>
             TRUE, profile_type => DBMS_SQLTUNE.PX_PROFILE);
 end;

查询已存在的SQL_PROFILE
select * from DBA_SQL_PROFILES;

DBA_SQL_PROFILES视图可查看当前系统中所有的SQL_PROFILES信息。


查询已存在的SQLTUNING TASK
select * from USER_ADVISOR_TASKS
USER_ADVISOR_TASKS视图可用来查看当前用户下所创建的调优任务


删除已应用的SQL_PROFILE

点击(此处)折叠或打开

 begin
 dbms_sqltune.drop_sql_profile(name => \'SYS_SQLPROF_014c22dc852c0004\');
 end;

删除当前用户创建的SQLTUNING TASK

点击(此处)折叠或打开

 begin
   DBMS_SQLTUNE.drop_tuning_task(task_name => \'test_falist_tuning_task6\');
 end;

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/22166274/viewspace-1464707/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/22166274/viewspace-1464707/