oracle解释计划不一样,一个SQL的执行计划不一样

最新推荐文章于 2023-11-02 15:33:30 发布
最新推荐文章于 2023-11-02 15:33:30 发布
阅读量413 收藏
点赞数
文章标签： oracle解释计划不一样

从  FROM V$SQL_PLAN_STATISTICS_ALL P 获得 01wa3qb3vd2qm 的执行计划 932283339

Global Stats

=========================================================================================

| Elapsed |   Cpu   |    IO    | Concurrency | Cluster  | Fetch | Buffer | Read | Read  |

| Time(s) | Time(s) | Waits(s) |  Waits(s)   | Waits(s) | Calls |  Gets  | Reqs | Bytes |

=========================================================================================

|     895 |     150 |      744 |        0.00 |     2.13 |     1 |    22M | 217K |   4GB |

=========================================================================================

SQL Plan Monitoring Details (Plan Hash Value=932283339)

=================================================================================================================================================================================================

| Id |                    Operation                    |        Name        |  Rows   | Cost |   Time    | Start  | Execs |   Rows   | Read  | Read  | Activity |        Activity Detail        |

|    |                                                 |                    | (Estim) |      | Active(s) | Active |       | (Actual) | Reqs  | Bytes |   (%)    |          (# samples)          |

=================================================================================================================================================================================================

|  0 | SELECT STATEMENT                                |                    |         |      |        43 |   +848 |     1 |        7 |       |       |          |                               |

|  1 |   VIEW                                          |                    |       3 | 3408 |        43 |   +848 |     1 |        7 |       |       |          |                               |

|  2 |    COUNT STOPKEY                                |                    |         |      |        43 |   +848 |     1 |        7 |       |       |          |                               |

|  3 |     CONCATENATION                               |                    |         |      |        43 |   +848 |     1 |        5 |       |       |          |                               |

|  4 |      FILTER                                     |                    |         |      |         7 |   +848 |     1 |        5 |       |       |          |                               |

|  5 |       FILTER                                    |                    |         |      |         7 |   +848 |     1 |        5 |       |       |          |                               |

|  6 |        NESTED LOOPS OUTER                       |                    |       1 |  945 |         7 |   +848 |     1 |        5 |       |       |          |                               |

|  7 |         NESTED LOOPS OUTER                      |                    |       1 |  942 |         7 |   +848 |     1 |        5 |       |       |          |                               |

|  8 |          NESTED LOOPS OUTER                     |                    |       1 |  939 |         7 |   +848 |     1 |        5 |       |       |          |                               |

|  9 |           NESTED LOOPS OUTER                    |                    |       1 |  936 |         7 |   +848 |     1 |        5 |       |       |          |                               |

| 10 |            NESTED LOOPS                         |                    |       1 |  935 |       885 |     +6 |     1 |        5 |       |       |          |                               |

| 11 |             NESTED LOOPS OUTER                  |                    |       1 |  932 |       885 |     +6 |     1 |       4M |       |       |     0.34 | Cpu (3)                       |

| 12 |              PARTITION RANGE ALL                |                    |       1 |  931 |       885 |     +6 |     1 |       4M |       |       |          |                               |

| 13 |               TABLE ACCESS FULL                 | ACC_SITE_REC       |       1 |  931 |       889 |     +2 |    18 |       4M | 54970 |   3GB |    23.34 | gc cr multi block request (1) |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | Cpu (53)                      |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | db file scattered read (88)   |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | db file sequential read (65)  |

| 14 |              TABLE ACCESS BY INDEX ROWID        | CMS_ORG_DETAIL     |       1 |    1 |       885 |     +6 |    4M |       4M |       |       |     1.69 | Cpu (15)                      |

| 15 |               INDEX UNIQUE SCAN                 | CMS_ORG_DETAIL_PK  |       1 |      |       885 |     +6 |    4M |       4M |     2 | 16384 |     1.35 | Cpu (12)                      |

| 16 |             TABLE ACCESS BY GLOBAL INDEX ROWID  | ACC_SITE_SEND      |       1 |    3 |       885 |     +6 |    4M |        5 |   925 |   7MB |     1.80 | Cpu (11)                      |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | db file sequential read (5)   |

| 17 |              INDEX UNIQUE SCAN                  | ACC_SITE_SEND_PK   |       1 |    2 |       890 |     +1 |    4M |       4M |  161K |   1GB |    71.48 | gc cr grant 2-way (2)         |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | Cpu (60)                      |

|    |                                                 |                    |         |      |           |        |       |          |       |       |          | db file sequential read (572) |

| 18 |            TABLE ACCESS BY INDEX ROWID          | CMS_ORG_DETAIL     |       1 |    1 |         7 |   +848 |     5 |        5 |       |       |          |                               |

| 19 |             INDEX UNIQUE SCAN                   | CMS_ORG_DETAIL_PK  |       1 |      |         7 |   +848 |     5 |        5 |       |       |          |                               |

| 20 |           TABLE ACCESS BY GLOBAL INDEX ROWID    | OPT_SIGN           |       1 |    3 |         1 |   +848 |     5 |        1 |       |       |          |                               |

| 21 |            INDEX UNIQUE SCAN                    | OPT_SIGN_PK        |       1 |    2 |         1 |   +848 |     5 |        1 |     5 | 40960 |          |                               |

| 22 |          TABLE ACCESS BY GLOBAL INDEX ROWID     | OPT_BILL           |       1 |    3 |         7 |   +848 |     5 |        5 |     1 |  8192 |          |                               |

| 23 |           INDEX UNIQUE SCAN                     | OPT_BILL_PK        |       1 |    2 |         7 |   +848 |     5 |        5 |       |       |          |                               |

| 24 |         TABLE ACCESS BY GLOBAL INDEX ROWID      | ACC_BILL           |       1 |    3 |         7 |   +848 |     5 |        5 |       |       |          |                               |

| 25 |          INDEX UNIQUE SCAN                      | ACC_BILL_PK        |       1 |    2 |         7 |   +848 |     5 |        5 |       |       |          |                               |

| 26 |      FILTER                                     |                    |         |      |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 27 |       FILTER                                    |                    |         |      |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 28 |        NESTED LOOPS OUTER                       |                    |       2 | 2463 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 29 |         NESTED LOOPS OUTER                      |                    |       2 | 2457 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 30 |          NESTED LOOPS OUTER                     |                    |       2 | 2451 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 31 |           NESTED LOOPS OUTER                    |                    |       2 | 2445 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 32 |            NESTED LOOPS OUTER                   |                    |       2 | 2444 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 33 |             NESTED LOOPS                        |                    |       2 | 2442 |         1 |   +890 |     1 |        2 |       |       |          |                               |

| 34 |              PARTITION RANGE ITERATOR           |                    |       6 | 2424 |         1 |   +890 |     1 |        3 |       |       |          |                               |

| 35 |               TABLE ACCESS BY LOCAL INDEX ROWID | ACC_SITE_SEND      |       6 | 2424 |         1 |   +890 |     1 |        3 |    15 | 120KB |          |                               |

| 36 |                INDEX RANGE SCAN                 | ACC_SITE_SEND_IDX1 |     223 | 2212 |         1 |   +890 |     1 |    12736 |     1 |  8192 |          |                               |

| 37 |              TABLE ACCESS BY GLOBAL INDEX ROWID | ACC_SITE_REC       |       1 |    3 |         1 |   +890 |     3 |        2 |       |       |          |                               |

| 38 |               INDEX UNIQUE SCAN                 | ACC_SITE_REC_PK    |       1 |    2 |         1 |   +890 |     3 |        3 |     1 |  8192 |          |                               |

| 39 |             TABLE ACCESS BY INDEX ROWID         | CMS_ORG_DETAIL     |       1 |    1 |         1 |   +890 |     2 |        2 |       |       |          |                               |

| 40 |              INDEX UNIQUE SCAN                  | CMS_ORG_DETAIL_PK  |       1 |      |         1 |   +890 |     2 |        2 |       |       |          |                               |

| 41 |            TABLE ACCESS BY INDEX ROWID          | CMS_ORG_DETAIL     |       1 |    1 |         1 |   +890 |     2 |        2 |       |       |          |                               |

| 42 |             INDEX UNIQUE SCAN                   | CMS_ORG_DETAIL_PK  |       1 |      |         1 |   +890 |     2 |        2 |       |       |          |                               |

| 43 |           TABLE ACCESS BY GLOBAL INDEX ROWID    | OPT_SIGN           |       1 |    3 |           |        |     2 |          |       |       |          |                               |

| 44 |            INDEX UNIQUE SCAN                    | OPT_SIGN_PK        |       1 |    2 |           |        |     2 |          |       |       |          |                               |

| 45 |          TABLE ACCESS BY GLOBAL INDEX ROWID     | OPT_BILL           |       1 |    3 |         1 |   +890 |     2 |        2 |     1 |  8192 |          |                               |

| 46 |           INDEX UNIQUE SCAN                     | OPT_BILL_PK        |       1 |    2 |         1 |   +890 |     2 |        2 |     1 |  8192 |          |                               |

| 47 |         TABLE ACCESS BY GLOBAL INDEX ROWID      | ACC_BILL           |       1 |    3 |         1 |   +890 |     2 |        2 |       |       |          |                               |

| 48 |          INDEX UNIQUE SCAN                      | ACC_BILL_PK        |       1 |    2 |         1 |   +890 |     2 |        2 |       |       |          |                               |

=================================================================================================================================================================================================

然后把该语句在PLSQL DELEVOPER 下 和 SQLPLUS 下得到是与上面不一样的执行计划

Execution Plan

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

Plan hash value: 3643155137

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

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

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

|   0 | SELECT STATEMENT                            |                         |     1 |  2237 |    18   (0)| 00:00:01 |         |         |

|*  1 |  VIEW                                            |                         |     1 |  2237 |    18   (0)| 00:00:01 |         |         |

|*  2 |   COUNT STOPKEY                             |                         |         |         |              |          |         |         |

|*  3 |    FILTER                                    |                         |         |         |              |          |         |         |

|   4 |     NESTED LOOPS OUTER                            |                         |     1 |   591 |    18   (0)| 00:00:01 |         |         |

|   5 |      NESTED LOOPS OUTER                     |                         |     1 |   579 |    17   (0)| 00:00:01 |         |         |

|   6 |       NESTED LOOPS OUTER                    |                         |     1 |   567 |    16   (0)| 00:00:01 |         |         |

|   7 |        NESTED LOOPS                            |                         |     1 |   326 |    13   (0)| 00:00:01 |         |         |

|   8 |         NESTED LOOPS OUTER                    |                         |     1 |   214 |    10   (0)| 00:00:01 |         |         |

|   9 |          NESTED LOOPS OUTER                    |                         |     1 |   185 |     7   (0)| 00:00:01 |         |         |

|  10 |           PARTITION RANGE ITERATOR            |                         |     1 |   154 |     4   (0)| 00:00:01 |   KEY |   KEY |

|* 11 |            TABLE ACCESS BY LOCAL INDEX ROWID| ACC_SITE_SEND         |     1 |   154 |     4   (0)| 00:00:01 |   KEY |   KEY |

|* 12 |             INDEX RANGE SCAN                    | ACC_SITE_SEND_IDX1 |     1 |         |     3   (0)| 00:00:01 |   KEY |   KEY |

|  13 |           TABLE ACCESS BY GLOBAL INDEX ROWID| OPT_SIGN                 |     1 |    31 |     3   (0)| 00:00:01 | ROWID | ROWID |

|* 14 |            INDEX UNIQUE SCAN                    | OPT_SIGN_PK         |     1 |         |     2   (0)| 00:00:01 |         |         |

|  15 |          TABLE ACCESS BY GLOBAL INDEX ROWID | OPT_BILL                 |     1 |    29 |     3   (0)| 00:00:01 | ROWID | ROWID |

|* 16 |           INDEX UNIQUE SCAN                    | OPT_BILL_PK         |     1 |         |     2   (0)| 00:00:01 |         |         |

|  17 |         TABLE ACCESS BY GLOBAL INDEX ROWID  | ACC_SITE_REC         |     1 |   112 |     3   (0)| 00:00:01 | ROWID | ROWID |

|* 18 |          INDEX UNIQUE SCAN                    | ACC_SITE_REC_PK         |     1 |         |     2   (0)| 00:00:01 |         |         |

|  19 |        TABLE ACCESS BY GLOBAL INDEX ROWID   | ACC_BILL                 |     1 |   241 |     3   (0)| 00:00:01 | ROWID | ROWID |

|* 20 |         INDEX UNIQUE SCAN                    | ACC_BILL_PK         |     1 |         |     2   (0)| 00:00:01 |         |         |

|  21 |       TABLE ACCESS BY INDEX ROWID            | CMS_ORG_DETAIL         |     1 |    12 |     1   (0)| 00:00:01 |         |         |

|* 22 |        INDEX UNIQUE SCAN                    | CMS_ORG_DETAIL_PK  |     1 |         |     0   (0)| 00:00:01 |         |         |

|  23 |      TABLE ACCESS BY INDEX ROWID            | CMS_ORG_DETAIL         |     1 |    12 |     1   (0)| 00:00:01 |         |         |

|* 24 |       INDEX UNIQUE SCAN                     | CMS_ORG_DETAIL_PK  |     1 |         |     0   (0)| 00:00:01 |         |         |

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

Wonder王达
关注
Oracle数据库 | SQL语句执行计划、语句跟踪与优化实例
不断学习，不断进步，提高自己
05-08 5431
如何发现最消耗系统资源的SQL语句呢? 利用I/O优化鉴定耗费资源的方法即AWR报告,即可使之变得很容易。 当确定了一个最有可能出问题的 SQL 语句后,接下来就是如何追踪这一语句的执行,最普遍的方法就是找出该SQL语句的执行计划。 随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的主要问题之一，系统优化中一个很重要的方面就是SQL语句的优化。 大量的数据指出劣质的SQL语句和优质的SQL语句之间的速度差别可以达到上百倍，对一个系统不是简单的能实现功能就可以，而是要写出高质量的SQL语句提
oracle 删除sql基线,Oracle SQL执行计划基线总结（SQL Plan Baseline）
weixin_30199989的博客
04-06 615
Oracle 11g开始，提供了一种新的固定执行计划的方法，即SQL plan baseline，中文名SQL执行计划基线(简称基线)，可以认为是OUTL一、基础概念Oracle 11g开始，提供了一种新的固定执行计划的方法，即SQL plan baseline，中文名SQL执行计划基线(简称基线)，可以认为是OUTLINE(大纲)或者SQL PROFILE的改进版本，基本上它的主要作用可以归纳为...
oracle相同sql执行计划不同,相同的SQL 在正式和测试环境中执行计划的不同
weixin_35410099的博客
04-13 924
相同的SQL 在两个环境里面执行计划不同 ，由于 测试环境 数据行数比较小 ，执行很快，而正式环境 数据量大 得执行6个多小时 ，大家帮忙看看差别在哪 ？ 多谢语句大概是这样的 select tab1.* from(a ,b) tab1 ,tab2 where tab1 tab2select tab1.cardno cardno,tab1.totalamt totalamt,...
为什么预估执行计划与真实执行计划会有差异？
Enmotech的博客
04-12 485
云和恩墨北区技术工程师专注于 SQL 审核和优化相关工作。曾经服务的客户涉及金融保险、电信运营商、政府、生产制造等行业。郭成日本文由恩墨大讲堂154期线上分享整理而成。一问题概要对同一个 SQL 语句的 ExplainPlan 里显示的预估执行计划与通过 V$SQL_PLAN 视图获取的 Runtime Plan 真实执行计划，偶尔会发现两边有不一致的情况，为什么呢？为什么预估执行计划会不准确？怎
oracle执行计划不一致的sql,一个简单的SQL在不同服务器下的执行计划不一样的问题...
weixin_39929566的博客
04-08 504
今天创建的一个视图，视图如下：create or replace view vw_nfw_feeinvoice_sum asselect a.billid,sum(b.amount) as invoiceamountfrom fe_fee ainner join oc_billlink b on a.billid=b.pbillidinner join fe_invoice c on b.bill...
oracle执行计划中，同一条语句块，在不同情况下执行计划不一样问题。子查询，union 导致索引失效。
qq_39255840的博客
09-22 1585
sql执行过程中，视图查询，使用子查询、union或者多层视图嵌套，都可能会导致执行计划发生改变，多层视图嵌套结构的语句，where条件位置等都有可能导致执行计划发生改变，索引不生效的问题，这些应当尽量避免。sql调优过程中也可以使用些hint进行优化。使用视图查询，还是有明细的劣势的，条件允许，尽量使用直接的sql语句查询，避免sql里面用到视图。
oracle查询，为什么相同的sql，执行计划不同？
qq_16939219的博客
09-03 1190
**背景：**系统线上运行，出现性能问题，最后定位是某个表的索引存在问题，执行计划看到某个sql耗时挺长，走了全扫描，这个表是以某个时间字段分区的。 **测试发现：**用的同一个SQL去查询，执行计划不一样，有一个是走了索引，有一个没走，就不太明白是怎么回事。 这个表的组合索引为(D_REPORT_DATE,C_PORT_CODE,C_REPORT_TEMPLATE,C_ELEMENT_CODE)四个字段 其中D_REPORT_DATE 为分区字段，日期类型。 为什么会是这样呢，不懂是什么原理。 我的查询
ORACLE执行计划和SQL调优.pptx
11-23
但是，每个表都有一个 rowid 伪列，该列可以像其他列一样使用，但不能删除、修改或插入该列的值。Rowid 在该行的生命周期内是唯一的，即使该行产生行迁移，行的 rowid 也不会改变。 Recursive SQL 概念 Recursive ...
oracle单个sql耗时,同一SQL,同一执行计划，执行耗时却相差很大，求解。。。
weixin_32126843的博客
04-12 1342
数据库最近发现了些怪异问题在同一次客户端，同一SQL的情况下(没有绑定变量)，产生的执行计划也一样，但耗时却会出现很明显的不同。 为什么会出现这样情况？当时ACTIVE SESSION也只有以下2个，而且每次执行 EVENT基本上都是 latch: cache buffers chainsS_ID SERIAL# USERNAME OSUSER PROGRAM ...
Oracle 同一sql语句在测试和开发环境不同的执行计划
11-30 1228
昨天下班前收到开发的邮件，一个执行sql语句执行的很慢，看了执行计划，为未走索引。 收到邮件后，登入到开发环境devdb,执行语句，果真很慢。登入到测试环境uatdb，执行同样的语句，速度很快。 开发和测试的为同一份生...
vpd对oracle执行计划的影响（plsql 查看执行计划与实际计划不一致）
viviliving的专栏
09-21 626
         大的项目软件使用到oracle vpd的话，vpd都会在运行时在底层给涉及到vpd权限的sql附加配置好的条件， 这样plsq F5查看的计划就不是最真实的，所以大家遇到这种情况，不要奇怪          要找到真是的执行计划可以这么试试： 1、oracle10g以上都有em console，从sql监控中找到对应的会话，sql然后查看最真的执行计划之oracle版 2...
【oracle】关于同一个SQL在两个环境执行计划不一样的问题记录
sgqsll的博客
11-22 1780
【oracle】关于同一个SQL在两个环境执行计划不一样的问题记录 问题描述：两个生产环境，部署系统、数据库版本等一致，执行sql: select a.field_1,a.field_2,b.field_1 from table_a a left join table_b b on a.id=b.a_id where b.field_conditon = '123'...
oracle执行大sql,同一个sql，参数不同，执行计划差异很大
weixin_35144647的博客
04-03 338
select count(*)from (selectquxiantodishi(ti.city_code) city_code, t.trade_moneyfrom trade_history t, sp_info tiwhere t.sp_id = ti.sp_idand t.partition_id = 2and t.start_time betweento_date('20160202...
oracle获取的执行计划区别及获取真实执行计划
comprel的博客
06-30 1403
oracle查看真实的执行计划oracle查看到的执行计划，偶尔并不是真实的执行计划， 查看是否是真实的执行计划，就是看SQL有没有真正的执行，若没有被执行，那么由于统计信息与实际直接误差，或其他原因，执行计划可能是不准确的。10046获取的是执行计划 explain plan，dbms_xplan,autotrace这三种方法获取到的执行计划，可能不是真实的执行计划1.1004610046事件
oracle 11g 基数反馈造成同一sql执行产生不同的执行计划
10-17 427
ardinality Feedback基数反馈是版本11.2中引入的关于SQL 性能优化的新特性，该特性主要针对 统计信息陈旧、无直方图或虽然有直方图但仍基数计算不准确的情况， Cardinality基数的计算直接影响到后续的J...
oracle执行计划完全一样,急求解答:两个相同的数据库的执行计划差别怎么那么大，附带执行计划!!!...
weixin_35009700的博客
04-05 320
最近工作中遇到一个很郁闷的问题:前提:我一个培训环境，一个测试环境，均是AIX 5.3的操作系统，2个CPU ,6G内存,测试环境是1个月前通过rman方式将数据从培训环境中导入的检查确认参数文件保持一致,表结构一致,数据量差别非常小问题现象:一个sql语句在两个配置和表结构相同的数据库中的执行计划不同，而且差别太大,查询结果出来后一个是5秒,一个几分钟sql语句:select *from (se...
Oracle执行计划详解
jalays的专栏
09-03 618
<br /><br />　什么是执行计划<br />　　所谓执行计划，顾名思义，就是对一个查询任务，做出一份怎样去完成任务的详细方案。举个生活中的例子，我从珠海要去英国，我可以选择先去香港然后转机，也可以先去北京转机，或者去广州也可以。但是到底怎样去英国划算，也就是我的费用最少，这是一件值得考究的事情。同样对于查询而言，我们提交的SQL仅仅是描述出了我们的目的地是英国，但至于怎么去，通常我们的SQL中是没有给出提示信息的，是由数据库来决定的。<br />　　我们先简单的看一个执行计划的对比：<br />　　
Oracle-执行计划
最新发布
UntifA的博客
11-02 2345
Oracle-执行计划生成及查看的几种方法
Oracle表统计信息是否准确,oracle表的统计信息完全正确，执行计划无故改变。原厂人员如是回复...
weixin_35407400的博客
04-08 300
就像在电话里提到的那样，Oracle内部的优化器是根据一系列的内部算法基于表上的统计信息来产生执行计划的。对于特别复杂的SQL语句，Oracle的优化器有一定几率不能得到最优的执行计划(因为机器代码实际上是比较死板的，虽然得到的执行计划按照内部的算法来看是比较快的，但是实际上这个执行计划可能在实际执行中比较慢)。我们现在碰到的就是这种情况，虽然表的统计信息是准的，但恰恰优化器在基于这个统计信息使用...
Oracle执行计划深入理解：Rowid、Recursive SQL与优化
执行计划是ORACLE解释和执行SQL语句的详细步骤，包括了数据的获取路径、操作顺序以及预计的资源消耗等信息。 Recursive SQL是指在执行用户SQL语句时，ORACLE为了完成任务可能需要额外执行的一些内部SQL语句。例如，...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值