背景:

某表忽然出现查询很缓慢的情况。cost 100+ 秒以上;严重影响生产。

原SQL:

explain plan for
select * from (
select ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS,
EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg
from interface_table where ((command_code in('AASSS')
and status in('F','E') and (re_f = 'N') and FROM_SYS = 'MEE')
or (COMMAND_CODE in('XXXX','XXXX9') and FROM_SYS = 'EXT' and RE_F = 'N')
) and MOD(id, 1) = 0 order by id) where rownum <= 100 ;

查看其运行计划:

SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
Plan hash value: 1871549687
 
----------------------------------------------------------------------------------------------------
| Id  | Operation                     | Name               | Rows  | Bytes | Cost (%CPU)| Time     |
----------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT              |                    |    99 |   382K|   637   (1)| 00:00:08 |
|*  1 |  COUNT STOPKEY                |                    |       |       |            |          |
|   2 |   VIEW                        |                    |   100 |   386K|   637   (1)| 00:00:08 |
|*  3 |    TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE    |   355 | 55735 |   637   (1)| 00:00:08 |
|*  4 |     INDEX FULL SCAN           | PK_INTERFACE_TABLE |  1439 |       |   280   (2)| 00:00:04 |
----------------------------------------------------------------------------------------------------

优化后的SQL:

explain plan for
select * from (
select /*+ index(INT_TABLE IX_INT_TABLE_2)*/ ID id,RET_NO retNo, FROM_SYS fromSy, TO_SYS toSys, COMMAND_CODE commandCode, COMMAND, STATUS,
EXT_CODE, ORIGN_CODE orignCode,error_message errorMessage, RE_F, RET_MSG retMsg
from interface_table where ((command_code in('AASSS')
and status in('F','E') and (re_f = 'N') and FROM_SYS = 'MEE')
or (COMMAND_CODE in('XXXX','XXXX9') and FROM_SYS = 'EXT' and RE_F = 'N')
) and MOD(id, 1) = 0 order by id) where rownum <= 100 ;

查看其运行计划:

SELECT plan_table_output FROM TABLE(DBMS_XPLAN.DISPLAY('PLAN_TABLE'));
Plan hash value: 3625182869
 
--------------------------------------------------------------------------------------------------------
| Id  | Operation                       | Name                 | Rows  | Bytes | Cost (%CPU)| Time     |
--------------------------------------------------------------------------------------------------------
|   0 | SELECT STATEMENT                |                      |    99 |   382K| 19105   (1)| 00:03:50 |
|*  1 |  COUNT STOPKEY                  |                      |       |       |            |          |
|   2 |   VIEW                          |                      |   356 |  1376K| 19105   (1)| 00:03:50 |
|*  3 |    SORT ORDER BY STOPKEY        |                      |   356 | 55892 | 19105   (1)| 00:03:50 |
|   4 |     CONCATENATION               |                      |       |       |            |          |
|*  5 |      TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE      |    69 | 10833 |  9552   (1)| 00:01:55 |
|*  6 |       INDEX RANGE SCAN          | IX_INTERFACE_TABLE_2 | 77145 |       |    99   (0)| 00:00:02 |
|*  7 |      TABLE ACCESS BY INDEX ROWID| INTERFACE_TABLE      |   287 | 45059 |  9552   (1)| 00:01:55 |
|*  8 |       INDEX RANGE SCAN          | IX_INTERFACE_TABLE_2 | 77145 |       |    99   (0)| 00:00:02 |
--------------------------------------------------------------------------------------------------------

比較:

查看运行计划。原来是使用 full scan - 当数据量大时很慢。优化后oracle优先走range scan,hint 的 index 是未处理标识字段的索引,正常情况下这个数据集合相对较小--------所以能够达到优化目的。

详细情况详细分析,我们必需要看实际的表存的业务数据。分析其业务关系找到最小业务集合。后者要看懂运行计划,依据rows, bytes, cost, time 找到最优项目。这个分析顺序不能倒置。

问题:为何使用 rownum 后,oracle运行计划会走full scan?

转:怎样看懂运行计划:http://jadethao.iteye.com/blog/1613943

====  section2 ====

http://blog.chinaunix.net/uid-77311-id-3233190.html

环境:
OS:Red Hat Linux As 5
DB:10.2.0.4
 
Oracle通过STA给出某个SQL运行建议,以下通过一个測试检查Oracle给出的优化建议是否正确.
 
1.建表并生成測试数据
SQL> create table tb_test(id number not null,name varchar2(30));
Table created.
SQL> create index idx_tb_test on tb_test(id);
Index created.
SQL> declare
begin
  for i in 1 .. 100000 loop
    insert into tb_test values (i, 'test');
    commit;
  end loop;
end;
/
 
2.分析表
begin
  dbms_stats.gather_table_stats(ownname => 'SCOTT', tabname => 'TB_TEST');
end;

3.编造一个运行计划不正确的SQL

select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1

我们知道在ID列上有索引,这个SQL走索引是正确的运行计划,但这里强制oracle走全表扫描,然后通过STA,看oracle给出的运行计划是否正确.

4.创建TUNING_TASK并运行

declare
  l_task_name varchar2(30);
  l_sql       clob;
begin
  l_sql       := 'select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1';
  l_task_name := DBMS_SQLTUNE.CREATE_TUNING_TASK(sql_text    => l_sql,
                                                 user_name   => 'SCOTT',
                                                 scope       => 'COMPREHENSIVE',
                                                 time_limit  => 60,
                                                 task_name   => 'task_name01',
                                                 description => null);
dbms_sqltune.Execute_tuning_task(task_name => 'task_name01');
end;

5.查看oracle给出的优化建议

SQL> set serveroutput on;
SQL> set long 999999999;
SQL> SELECT DBMS_SQLTUNE.REPORT_TUNING_TASK('task_name01') FROM DUAL;

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------
GENERAL INFORMATION SECTION
-------------------------------------------------------------------------------
Tuning Task Name                  : task_name01
Tuning Task Owner                 : SYS
Scope                             : COMPREHENSIVE
Time Limit(seconds)               : 60
Completion Status                 : COMPLETED
Started at                        : 06/03/2012 00:07:58
Completed at                      : 06/03/2012 00:07:59
Number of SQL Profile Findings    : 1

DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_TASK_NAME01')
--------------------------------------------------------------------------------
-------------------------------------------------------------------------------
Schema Name: SCOTT
SQL ID     : ga3q5tqjgsj5u
SQL Text   : select/*+ full(t)*/ count(1) from scott.tb_test t where t.id=1

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

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

DBMS_SQLTUNE.REPORT_TUNING_TASK('MY_TASK_NAME01')
--------------------------------------------------------------------------------
  A potentially better execution plan was found for this statement.

  Recommendation (estimated benefit: 84.11%)
  ------------------------------------------
  - Consider accepting the recommended SQL profile.
    execute dbms_sqltune.accept_sql_profile(task_name => 'task_name01',
            replace => TRUE);

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

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------

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

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

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

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

-- 当前的运行计划
DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------
|   0 | SELECT STATEMENT   |           |     1 |     4 |     6   (0)| 00:00:01 |

|   1 |  SORT AGGREGATE    |           |     1 |     4 |            |          |

|*  2 |   TABLE ACCESS FULL| TB_TEST   |     1 |     4 |     6   (0)| 00:00:01 |

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

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

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------

   2 - filter("T"."ID"=1)

 

-- Oracle给出的运行计划

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

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

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------
--------------------------------------------------------------------------------
---
|   0 | SELECT STATEMENT  |               |     1 |     4 |     1   (0)| 00:00:0
1 |
|   1 |  SORT AGGREGATE   |               |     1 |     4 |            |
  |
|*  2 |   INDEX RANGE SCAN| IDX_TB_TEST   |     1 |     4 |     1   (0)| 00:00:0
1 |
--------------------------------------------------------------------------------
---

DBMS_SQLTUNE.REPORT_TUNING_TASK('TASK_NAME01')
--------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------

   2 - access("T"."ID"=1)

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

从上面的输出能够看出Oracle给出的运行计划是正确的.能够使用例如以下方法使用正确的运行计划

begin
  dbms_sqltune.accept_sql_profile(task_name => 'task_name01', replace => TRUE);
end;

-- The End --

使用hint优化Oracle的运行计划 以及 SQL Tune Advisor的使用的更多相关文章

  1. 【ORACLE】记录通过执行Oracle的执行计划查询SQL脚本中的效率问题

    记录通过执行Oracle的执行计划查询SQL脚本中的效率问题   问题现象: STARiBOSS5.8.1R2版本中,河北对帐JOB执行时,无法生成发票对帐文件.   首先,Quartz表达式培植的启 ...

  2. [Oracle] 获取运行计划的各方法总结

    总的结论: 一.获取运行计划的6种方法(具体步骤已经在每一个样例的开头凝视部分说明了): 1. explain plan for获取:  2. set autotrace on .  3. stati ...

  3. oracle分区表运行计划

    分区表有非常多优点,以大化小,一小化了,加上并行的使用,在loap中能往往能提高几十倍甚至几百倍的效果. 当然表设计得不好也会适得其反.效果比普通表跟糟糕. 为了更好的使用分区表,这里看一下分区表的运 ...

  4. .Oracle固定执行计划之SQL PROFILE概要文件

    1.  引子Oracle系统为了合理分配和使用系统的资源提出了概要文件的概念.所谓概要文件,就是一份描述如何使用系统的资源(主要是CPU资源)的配置文件.将概要文件赋予某个数据库用户,在用户连接并访问 ...

  5. Oracle rownum影响运行计划

    今天调优一条SQL语句,因为SQL比較复杂,用autotrace非常难一眼看出哪里出了问题,直接上10046. SELECT AB.* FROM (SELECT A.*, rownum RN FROM ...

  6. Oracle 固定执行计划-使用SPM(Sql Plan Management)固定执行计划

    固定执行计划-使用SPM(Sql Plan Management)固定执行计划 转载自:http://www.lunar2013.com/2016/01/固定执行计划-使用spm%EF%BC%88sq ...

  7. MySQL运行计划不准确 -概述

    为毛 MySQL优化器的运行计划 好多时候都不准确,不是最优的呢(cpu+io)??? 因素太多了:: 存在information_schema的信息是定期刷新上去的,好多时候不是最真的,甚至相差好大 ...

  8. Pig源代码分析: 简析运行计划的生成

    摘要 本文通过跟代码的方式,分析从输入一批Pig-latin到输出物理运行计划(与launcher引擎有关,通常是MR运行计划.也能够是Spark RDD的运行算子)的总体流程. 不会详细涉及AST怎 ...

  9. 用DBMS_ADVISOR.SQLACCESS_ADVISOR创建SQL Access Advisor访问优化建议

    使用OEM方式来创建SQL Access Advisor访问优化建议,已经是四五年的事了,下面就来写写怎样使用DBMS_ADVISOR.SQLACCESS_ADVISOR来创建SQL Access A ...

随机推荐

  1. Angular2入门:TypeScript的类型 - let , var, const

    一.let 二.const

  2. 【微收藏】FourShadows.js – 时间感知的算法驱动的图标阴影JS库

    废话一箩筐,筐筐有心得 不小心养成了一个刷微博的习惯,主要还是关注一些前端人士,学习一些前端方面的知识,看到大家都有一些刷微博的小习惯.有的是转发一下,转发内容来一个标记(MARK).也有评论中标记为 ...

  3. 身份认证与加密浅谈(PKI)

    利用PKI体系解决私密文件传输中一系列问题的大体思路 背景:现有A用户和B用户之间想加密传输一些秘密文件,通过什么样的技术可以确保A和B传输数据的安全性?方案:采用对称秘钥对数据进行加密传输(对称加密 ...

  4. 【Spring】20、使用TransactionSynchronizationManager在spring事务提交之后进行一些操作。

    本文内容 如何在spring事务提交之后进行一些操作,这些操作必须得在该事务成功提交后才执行,回滚则不执行. 要点 如何在spring事务提交之后操作 如何在spring事务回滚之后操作 实现方案 使 ...

  5. Java 支付宝支付,退款,单笔转账到支付宝账户(支付宝支付)

    最近一直在接触第三方,刚接入完支付宝的API做一下总结,个人能力薄弱有不对的地方望指教.  做的是一个小型电商项目,所以会接入第三方的支付和登入功能, 第一次接入第三方撸了很多官方文档. 进入主题, ...

  6. java——线程

    线程与进程 1.线程:程序中单独顺序的控制流 线程本身是通过程序进行运行 线程是程序中的顺序控制流,只能使用分配给程序的资源与环境 2.进程:执行中的程序 一个进程可以包含一个或多个线程 一个进程至少 ...

  7. module.exports和exports.md

    推荐写法 具体解释可以往后看. 'use strict' let app = { // 注册全局对象 ... } ... // 封装工具箱 exports = module.exports = app ...

  8. 通过swagger将API业务版本号与Gitlab代码版本号绑定

    1.调用Gitlab API获取项目commit ID 2.编辑 Swagger2.java @Configuration @EnableSwagger2 @EnableWebMvc public c ...

  9. var声明变量

    var操作符定义变量将成为定义该变量作用域的局部变量 举例说明: 例子1: function test(){ var message = "hi"; //message是函数内部局 ...

  10. 限制Apache日志access.log、error.log文件大小

    在 Windows 下的设置例子如下: # 限制错误日志文件为 1M ErrorLog "|bin/rotatelogs.exe -l logs/error-%Y-%m-%d.log 1M& ...