安科网

Oracle 10g的隐含参数_complex_view_merging引发的性能问题

狂浪的旮旯天地

狂浪的旮旯天地

2014-03-04

关注 关注

今天在Oracle 10g上碰到一个奇怪的问题，有一条sql在数据库1上很快，在数据库2上很慢，数据库2的数据是从数据库1上导的，数据量差不多。

在数据库1上执行0.01s。

SQL> SELECT A.*,
  2        B.INCREASE_ID,
  3        B.TRANSACTION_ID,
  4        B.LINK_CARD_ID,
  5        B.VALIDATE_FLAG,
  6        B.ASSET_VALUE_SHARING,
  7        B.RELATED_DEVICE_ID,
  8        B.PARENT_CARD_CODE,
  9        B.PROJECT_VALUE,
 10        B.DELETE_FLAG,
 11        B.DEPRECIATION_ADJUST_VALUE,
 12        T.TRANSACTION_MODE_CODE,
 13        T.TRANSACTION_NO,
 14        T.TRANSACTION_FROM,
 15        T.FROM_MODEL,
 16        (SELECT T.FULL_PATH
 17            FROM AM_TECH_OBJECT_NODE_0900 T
 18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID
 19            AND T.NODE_TYPE = 2
 20            AND ROWNUM = 1) AS FULL_PATH,
 21        AAC.FULL_NAME CLASSIFY_FULL_PATH
 22    FROM V_ASSET_CARD_0900      A,
 23        GG_ASSET_INCREASE_ITEM B,
 24        GG_ASSET_TRANSACTION  T,
 25        AM_ASSET_CLASSIFY      AAC
 26  WHERE A.CARD_ID = B.CARD_ID
 27    AND B.TRANSACTION_ID = T.TRANSACTION_ID
 28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)
 29    AND B.TRANSACTION_ID = '0101109514';
已用时间:  00: 00: 00.01
执行计划
----------------------------------------------------------
Plan hash value: 3643758043
-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                          | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT                |                                |    21 | 24129 |  167  (0)| 00:00:03 |
|*  1 |  COUNT STOPKEY                  |                                |      |      |            |          |
|  2 |  TABLE ACCESS BY INDEX ROWID    | AM_TECH_OBJECT_NODE_0900      |    1 |    73 |    4  (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN              | IDX_TECH_NODE_ID_0900          |    1 |      |    3  (0)| 00:00:01 |
|  4 |  NESTED LOOPS OUTER              |                                |    21 | 24129 |  167  (0)| 00:00:03 |
|  5 |  NESTED LOOPS                  |                                |    21 | 22533 |  146  (0)| 00:00:02 |
|  6 |    NESTED LOOPS                  |                                |    20 | 12700 |  106  (0)| 00:00:02 |
|  7 |    NESTED LOOPS                |                                |    20 | 10900 |    46  (0)| 00:00:01 |
|  8 |      NESTED LOOPS                |                                |    20 |  2000 |    6  (0)| 00:00:01 |
|  9 |      TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION          |    1 |    42 |    2  (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN        | PK_GG_ASSET_TRANSACTION        |    1 |      |    1  (0)| 00:00:01 |
|  11 |      TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM        |    20 |  1160 |    4  (0)| 00:00:01 |
|* 12 |        INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    20 |      |    1  (0)| 00:00:01 |
|  13 |      TABLE ACCESS BY INDEX ROWID | GG_ASSET_CARD_0900            |    1 |  445 |    2  (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN          | PK_GG_ASSET_CARD_0303          |    1 |      |    1  (0)| 00:00:01 |
|  15 |    TABLE ACCESS BY INDEX ROWID  | GG_ASSET_VALUE_0900            |    1 |    90 |    3  (0)| 00:00:01 |
|* 16 |      INDEX RANGE SCAN            | ID_FAV_CARD_VALIDITY_0303      |    1 |      |    2  (0)| 00:00:01 |
|  17 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_0900                  |    1 |  438 |    2  (0)| 00:00:01 |
|* 18 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_0900              |    1 |      |    1  (0)| 00:00:01 |
|  19 |  TABLE ACCESS BY INDEX ROWID    | AM_ASSET_CLASSIFY              |    1 |    76 |    1  (0)| 00:00:01 |
|* 20 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_CLASSIFY          |    1 |      |    0  (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter(ROWNUM=1)
  3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)
  10 - access("T"."TRANSACTION_ID"='0101109514')
  12 - access("B"."TRANSACTION_ID"='0101109514')
  14 - access("GG_ASSET_CARD"."CARD_ID"="B"."CARD_ID")
  16 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND
              "GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")
  18 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")
  20 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
统计信息
----------------------------------------------------------
          8  recursive calls
          0  db block gets
        28  consistent gets
          0  physical reads
          0  redo size
      12384  bytes sent via SQL*Net to client
        338  bytes received via SQL*Net from client
          2  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
          1  rows processed

 

 

在数据库2上很慢，27.48s
SQL> SELECT A.*,
  2        B.INCREASE_ID,
  3        B.TRANSACTION_ID,
  4        B.LINK_CARD_ID,
  5        B.VALIDATE_FLAG,
  6        B.ASSET_VALUE_SHARING,
  7        B.RELATED_DEVICE_ID,
  8        B.PARENT_CARD_CODE,
  9        B.PROJECT_VALUE,
 10        B.DELETE_FLAG,
 11        B.DEPRECIATION_ADJUST_VALUE,
 12        T.TRANSACTION_MODE_CODE,
 13        T.TRANSACTION_NO,
 14        T.TRANSACTION_FROM,
 15        T.FROM_MODEL,
 16        (SELECT T.FULL_PATH
 17            FROM AM_TECH_OBJECT_NODE_0900 T
 18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID
 19            AND T.NODE_TYPE = 2
 20            AND ROWNUM = 1) AS FULL_PATH,
 21        AAC.FULL_NAME CLASSIFY_FULL_PATH
 22    FROM V_ASSET_CARD_0900      A,
 23        GG_ASSET_INCREASE_ITEM B,
 24        GG_ASSET_TRANSACTION  T,
 25        AM_ASSET_CLASSIFY      AAC
 26  WHERE A.CARD_ID = B.CARD_ID
 27    AND B.TRANSACTION_ID = T.TRANSACTION_ID
 28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)
 29    AND B.TRANSACTION_ID = '0101109514';
已选择200行。
已用时间:  00: 00: 27.48
执行计划
----------------------------------------------------------
Plan hash value: 2944357796
-------------------------------------------------------------------------------------------------------------------------
| Id  | Operation                      | Name                          | Rows  | Bytes |TempSpc| Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT              |                                |    25 |  255K|      | 45815  (1)| 00:09:10 |
|*  1 |  COUNT STOPKEY                |                                |      |      |      |        |            |
|  2 |  TABLE ACCESS BY INDEX ROWID  | AM_TECH_OBJECT_NODE_0900      |    1 |    75 |      |    4  (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN            | IDX_TECH_NODE_ID_0900          |    1 |      |      |    3  (0)| 00:00:01 |
|  4 |  NESTED LOOPS OUTER            |                                |    25 |  255K|      | 45815  (1)| 00:09:10 |
|*  5 |  HASH JOIN                    |                                |    25 |  253K|      | 45790  (1)| 00:09:10 |
|  6 |    NESTED LOOPS                |                                |    25 |  2750 |      |    6  (0)| 00:00:01 |
|  7 |    TABLE ACCESS BY INDEX ROWID| GG_ASSET_TRANSACTION          |    1 |    53 |      |    2  (0)| 00:00:01 |
|*  8 |      INDEX UNIQUE SCAN        | PK_GG_ASSET_TRANSACTION        |    1 |      |      |    1  (0)| 00:00:01 |
|  9 |    TABLE ACCESS BY INDEX ROWID| GG_ASSET_INCREASE_ITEM        |    25 |  1425 |      |    4  (0)| 00:00:01 |
|* 10 |      INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    25 |      |      |    1  (0)| 00:00:01 |
|  11 |    VIEW                        | V_ASSET_CARD_0900              |  280K|  2744M|      | 45781  (1)| 00:09:10 |
|* 12 |    HASH JOIN                  |                                |  280K|  257M|  141M| 45781  (1)| 00:09:10 |
|* 13 |      HASH JOIN                |                                |  274K|  137M|    27M| 12222  (1)| 00:02:27 |
|  14 |      TABLE ACCESS FULL        | GG_ASSET_VALUE_0900            |  292K|    24M|      |  910  (2)| 00:00:11 |
|  15 |      TABLE ACCESS FULL        | GG_ASSET_CARD_0900            |  274K|  114M|      |  4073  (1)| 00:00:49 |
|  16 |      TABLE ACCESS FULL        | AM_ASSET_0900                  |  756K|  315M|      | 10464  (1)| 00:02:06 |
|  17 |  TABLE ACCESS BY INDEX ROWID  | AM_ASSET_CLASSIFY              |    1 |    76 |      |    1  (0)| 00:00:01 |
|* 18 |    INDEX UNIQUE SCAN          | PK_AM_ASSET_CLASSIFY          |    1 |      |      |    0  (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter(ROWNUM=1)
  3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)
  5 - access("A"."CARD_ID"="B"."CARD_ID")
  8 - access("T"."TRANSACTION_ID"='0101109514')
  10 - access("B"."TRANSACTION_ID"='0101109514')
  12 - access("AM_ASSET"."DEVICE_ID"="GG_ASSET_CARD"."DEVICE_ID")
  13 - access("GG_ASSET_VALUE"."CARD_ID"="GG_ASSET_CARD"."CARD_ID" AND
              "GG_ASSET_VALUE"."VALIDITY_DATE_END"="GG_ASSET_CARD"."DECREASE_DATE")
  18 - access("A"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
统计信息
----------------------------------------------------------
        218  recursive calls
          0  db block gets
      70112  consistent gets
      26412  physical reads
        348  redo size
      38174  bytes sent via SQL*Net to client
        480  bytes received via SQL*Net from client
        15  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        200  rows processed

第一次诊断：起初觉得应该是索引的集群因子的问题，检查了下，差不多。

第二次诊断：感觉是环境、参数不一样引起，开始试验。

使用视图v$sql和v$sql_plan、dbms_xplan.display_cursor查出sql真实的执行计划。

select distinct s.SQL_ID, s.HASH_VALUE, s.CHILD_NUMBER, s.SQL_TEXT
  from v$sql s, v$sql_plan p
 where s.SQL_ID = p.SQL_ID
  and p.PLAN_HASH_VALUE = '3643758043';
select * from table(dbms_xplan.display_cursor(150270666, 0, 'advanced'));

性能慢的数据库：
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
      OPT_PARAM('_complex_view_merging' 'false')
      ALL_ROWS
      ............省略............
  */

性能快的数据库： 
  /*+
      BEGIN_OUTLINE_DATA
      IGNORE_OPTIM_EMBEDDED_HINTS
      OPTIMIZER_FEATURES_ENABLE('10.2.0.4')
      ALL_ROWS
      ............省略............
  */


看到两个执行的大纲有点不同，于是到两个数据库中查这个_complex_view_merging这个隐含参数，性能慢的数据库设置为false,性能快的数据库的设置则为true。

SQL语句中是有视图的，莫非这个隐含参数有问题，按字面的意思是复杂视图的合并，抱着试一试的心情调整了下这个参数：
alter session set "_complex_view_merging" = true; 

结果非常快，0.6s。

SQL> SELECT A.*,
  2        B.INCREASE_ID,
  3        B.TRANSACTION_ID,
  4        B.LINK_CARD_ID,
  5        B.VALIDATE_FLAG,
  6        B.ASSET_VALUE_SHARING,
  7        B.RELATED_DEVICE_ID,
  8        B.PARENT_CARD_CODE,
  9        B.PROJECT_VALUE,
 10        B.DELETE_FLAG,
 11        B.DEPRECIATION_ADJUST_VALUE,
 12        T.TRANSACTION_MODE_CODE,
 13        T.TRANSACTION_NO,
 14        T.TRANSACTION_FROM,
 15        T.FROM_MODEL,
 16        (SELECT T.FULL_PATH
 17            FROM sz_1230.AM_TECH_OBJECT_NODE_0900 T
 18          WHERE T.TECH_OBJECT_ID = A.DEVICE_ID
 19            AND T.NODE_TYPE = 2
 20            AND ROWNUM = 1) AS FULL_PATH,
 21        AAC.FULL_NAME CLASSIFY_FULL_PATH
 22    FROM sz_1230.V_ASSET_CARD_0900      A,
 23        sz_1230.FM_ASSET_INCREASE_ITEM B,
 24        sz_1230.FM_ASSET_TRANSACTION  T,
 25        sz_1230.AM_ASSET_CLASSIFY      AAC
 26  WHERE A.CARD_ID = B.CARD_ID
 27    AND B.TRANSACTION_ID = T.TRANSACTION_ID
 28    AND A.CLASSIFY_ID = AAC.DEVICE_CLASSIFY_ID(+)
 29    AND B.TRANSACTION_ID = '0101109514';
已选择200行。
已用时间:  00: 00: 00.06
执行计划
----------------------------------------------------------
Plan hash value: 801438153
-------------------------------------------------------------------------------------------------------------------
| Id  | Operation                        | Name                          | Rows  | Bytes | Cost (%CPU)| Time    |
-------------------------------------------------------------------------------------------------------------------
|  0 | SELECT STATEMENT                |                                |    25 | 28475 |  206  (0)| 00:00:03 |
|*  1 |  COUNT STOPKEY                  |                                |      |      |            |          |
|  2 |  TABLE ACCESS BY INDEX ROWID    | AM_TECH_OBJECT_NODE_0900      |    1 |    75 |    4  (0)| 00:00:01 |
|*  3 |    INDEX RANGE SCAN              | IDX_TECH_NODE_ID_0900          |    1 |      |    3  (0)| 00:00:01 |
|  4 |  NESTED LOOPS                    |                                |    25 | 28475 |  206  (0)| 00:00:03 |
|  5 |  NESTED LOOPS OUTER            |                                |    25 | 26275 |  131  (0)| 00:00:02 |
|  6 |    NESTED LOOPS                  |                                |    25 | 24375 |  106  (0)| 00:00:02 |
|  7 |    NESTED LOOPS                |                                |    25 | 13425 |    56  (0)| 00:00:01 |
|  8 |      NESTED LOOPS                |                                |    25 |  2475 |    6  (0)| 00:00:01 |
|  9 |      TABLE ACCESS BY INDEX ROWID| FM_ASSET_TRANSACTION          |    1 |    42 |    2  (0)| 00:00:01 |
|* 10 |        INDEX UNIQUE SCAN        | PK_FM_ASSET_TRANSACTION        |    1 |      |    1  (0)| 00:00:01 |
|  11 |      TABLE ACCESS BY INDEX ROWID| FM_ASSET_INCREASE_ITEM        |    25 |  1425 |    4  (0)| 00:00:01 |
|* 12 |        INDEX RANGE SCAN          | TRANSACTION_DETAIL_REF_TRANSAC |    25 |      |    1  (0)| 00:00:01 |
|  13 |      TABLE ACCESS BY INDEX ROWID | FM_ASSET_CARD_0900            |    1 |  438 |    2  (0)| 00:00:01 |
|* 14 |      INDEX UNIQUE SCAN          | PK_FM_ASSET_CARD_0303          |    1 |      |    1  (0)| 00:00:01 |
|  15 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_0900                  |    1 |  438 |    2  (0)| 00:00:01 |
|* 16 |      INDEX UNIQUE SCAN          | PK_AM_ASSET_0900              |    1 |      |    1  (0)| 00:00:01 |
|  17 |    TABLE ACCESS BY INDEX ROWID  | AM_ASSET_CLASSIFY              |    1 |    76 |    1  (0)| 00:00:01 |
|* 18 |    INDEX UNIQUE SCAN            | PK_AM_ASSET_CLASSIFY          |    1 |      |    0  (0)| 00:00:01 |
|  19 |  TABLE ACCESS BY INDEX ROWID    | FM_ASSET_VALUE_0900            |    1 |    88 |    3  (0)| 00:00:01 |
|* 20 |    INDEX RANGE SCAN              | ID_FAV_CARD_VALIDITY_0303      |    1 |      |    2  (0)| 00:00:01 |
-------------------------------------------------------------------------------------------------------------------
Predicate Information (identified by operation id):
---------------------------------------------------
  1 - filter(ROWNUM=1)
  3 - access("T"."TECH_OBJECT_ID"=:B1 AND "T"."NODE_TYPE"=2)
  10 - access("T"."TRANSACTION_ID"='0101109514')
  12 - access("B"."TRANSACTION_ID"='0101109514')
  14 - access("FM_ASSET_CARD"."CARD_ID"="B"."CARD_ID")
  16 - access("AM_ASSET"."DEVICE_ID"="FM_ASSET_CARD"."DEVICE_ID")
  18 - access("AM_ASSET"."CLASSIFY_ID"="AAC"."DEVICE_CLASSIFY_ID"(+))
  20 - access("FM_ASSET_VALUE"."CARD_ID"="FM_ASSET_CARD"."CARD_ID" AND
              "FM_ASSET_VALUE"."VALIDITY_DATE_END"="FM_ASSET_CARD"."DECREASE_DATE")
统计信息
----------------------------------------------------------
          0  recursive calls
          0  db block gets
      3029  consistent gets
          0  physical reads
          0  redo size
      38039  bytes sent via SQL*Net to client
        480  bytes received via SQL*Net from client
        15  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        200  rows processed


 于是将_complex_view_merging全局设置为true, alter system set "_complex_view_merging" = true scope=both;

 再看了下其他的oracle 10g的数据库设置都是为true,应该是安装数据库的问题。

oracle执行计划 数据库 oracle oracle数据库

狂浪的旮旯天地

狂浪的旮旯天地

0 关注 0 粉丝 0 动态

关注 关注

相关推荐

关于ORACLE索引的几种扫描方式

一条sql执行的效率因执行计划的差异而影响，经常说这条sql走索引了，那条sql 全表扫了。索引是怎么走的呢，说说我了解到的几种索引走的方式。具体来说，仅当查询谓词使用等号运算符引用唯一索引键中的所有列时，数据库才执行唯一扫描.数据库从索引条目中获取行标识

娜娜 2020-07-18

疑问？ Oracle普通的B树索引是升序还是降序？

Oracle普通的B树索引是升序还是降序？SQL> create table a as select * from dba_objects;SQL> select object_name from a where object_id in or

talkingDB 2020-07-05

oracle执行计划打印

下班逗猫闲得无聊，写写自己对几种oracle执行计划打印的认识。废话少说开始吧方式一：explain plan for使用explain plan for，这种查询方式适合查看单条执行SQL的执行计划。explain plan for的查看方式也有两种：1

zhangchaoming 2020-06-21

Oracle绑定变量优缺点

因为oracle对于sql语句的首先的解析逻辑，会先匹配是否可以软解析，不行则会进行硬解析，相对而言 硬解析比较麻烦。select * from table where id = ‘1‘ 和select * from table where id = ‘2

zhangchaoming 2020-05-27

Oracle里的执行计划

第二章：Oracle里的执行计划2.1 什么是执行计划Oracle用来执行目标SQL语句的这些步骤的组合就被称为执行计划。可以看到Oracle在执行目标SQL时所用的内部执行步骤，这些步骤的执行顺序，所对应的的谓词信息、列信息，优化器评估出来执行这些步骤后

LuoXinLoves 2020-05-04

面试篇三：数据库MySQL、Oracle

SELECT * FROM admin_company ORDER BY id LIMIT 0,10;limit后参数代表什么意思？LIMIT[位置偏移量,]行数，第一个参数是从哪个序号加上，初始是0，第二个参数是查询多少行记录。MySQL在创建表时就会创

康慧欣 2020-05-02

[ORACLE]自适应游标共享Adaptive Cursor Sharing

v$SQL_CS_SELECTIVITY --查看SQL游标的各个变量选择范围,它包含着各个条件谓词,绑定变量值以及它的最大值和最小值等信息。select IS_BIND_SENSITIVE,IS_BIND_AWARE,IS_SHAREABLE,SQL_T

Justdoit00 2020-04-26

oracle数据库应用开发经验

一般应用都会有一些表用来记录用户操作日志，数据变更记录，交易流水等日志型的库表。这些表最好按时间字段做分区，这样在迁移或者清理历史记录时会比较方便，借助oracle的分区交换清理特性，效率比delete高很多。Oracle在创建序列可以指定cache参数，

oraclemch 2019-12-29

Oracle调优之no_unnest和unnest用法简介

本博客介绍Oracle SQL调优的一种常用也是很实用的方法，也即/*+no_unnest */和/*+ unnest*/，介绍Oracle 的 /*+unnest */ 、 /*+ no_unnest */之前，先介绍一下Hint。Hint对于开发人员来

talkingDB 2020-01-11

Oracle查看SQL执行计划1--explain plan

SQL> set linesize 800SQL> select * from table;Oracle10g\11g中，如果我们对目标SQL执行explain plan命令，则oracle就将解析目标SQL所产生的执行计划的具体执行步骤写入P

Streamoutput 2020-01-10

数据库-Oracle通过执行计划查看查询语句是否使用索引【转】

select * from t_call_records where t_bjhm=‘123456‘。如上图所示，index range scan为索引范围扫描;索引范围扫描，当优化器发现在UNIQUE列上使用了大于、小于、大于等于、小于等于以及BETWE

Streamoutput 2019-12-02

Oracle Proc编程性能优化经验

Proc 是Oracle提供的一种数据库操作的AP。它是基于ESql技术的，需要预编译后才可以变成普通c代码，非常不直观，使用起来不太方便，阅读也存在困难。因为这些问题导致程序员平时开发中会出现一些Proc操作存在效率低下的情况，本文介绍一些Proc一些编

oraclemch 2019-12-01

记一次Oracle数据库实验--索引的常见执行计划

INDEX FULL SCAN：索引的全扫描，单块读，有序INDEX RANGE SCAN：索引的范围扫描INDEX FAST FULL SCAN：索引的快速全扫描，多块读，无序INDEX FULL SCAN：针对MAX(),MIN()函数的查询INDEX

der 2019-11-27

Oracle笔记

utm_source=blogxgwz14

zgxzowen 2015-07-01

分享一份Oracle官方文档学习路线图

概述今天主要分享下Oracle数据库的官方文档学习路线图。重点如下：1、sql、pl/sql. 作为oracle的基本功，需要大家对sql和plsql非常的熟悉。特别是sql里面的多表连接、子查询、各种新版本的函数，以及plsql里面的所有语法。不要认为这

jbossllx 2019-11-05

SQL Server,MySQL,Oracle三者的区别

完全支持所有的工业标准。对开发商全力支持，Oracle并行服务器通过使一组结点共享同一簇中的工作来扩展Windows NT的能力，提供高可用性和高伸缩性的簇的解决方案。Oracle的并行服务器对各种UNIX平台的集群机制都有着相当高的集成度。　Oracle

静思苑 2019-01-15

Oracle中游标Cursor使用实例

Oracle数据库中的cursor分为2中类型：shared cursor，session cursor. 会缓存存储目标sql的sql文本、解析树、该sql所涉及的对象定义、该sql所使用的绑定变量类型和长度，以及改sql的执行计划等信息。分别在V$SQ

人勤阡陌绿 2019-03-27

Oracle SQL性能分析之10053事件

优化器生成正确执行计划的前提条件是要有正确的统计信息，不准确的统计信息往往会导致错误的执行计划。当通过SQL和基数推断出的执行计划和实际执行计划不同时，就可以借助10053事件。10053事件是用来诊断优化器如何估算成本和选择执行计划的，用它产生的trac

Cavlier 2019-03-19

Oracle高并发系列1：DML引起的常见问题及优化思路

王鹏冲，平安科技数据库技术专家，浸淫数据库行业十多年，对Oracle数据库有浓厚兴趣，也对MySQL、MongoDB、Redis等数据库有一定架构和运维经验，目前正沉迷在PostgreSQL数据库与Oracle数据库的PK之中，重点在关系型数据库的分布式架

EricRay 2017-05-26

oracle--如何分析执行计划

当这个操作完成之后，产生的rowsource中的数据被送往下一步骤进行处理，在此例中，SELECTSTATEMENT操作是这个查询语句的最后一步。决定该语句使用何种优化器的唯一方法是看后面的cost部分。例如，如果给出的是下面的形式，则表明使用的是CBO优

javamao00 2011-08-15
狂浪的旮旯天地

狂浪的旮旯天地

W3CSchool教程
HTML 教程
CSS 教程
Bootstrap 教程
Javascript 教程
jQuery 教程
后端教程
C 教程
Java 教程
PHP 教程
Python 教程
Go 教程
移动开发
Android 教程
Swift 教程
Kotlin 教程
jQuery Mobile 教程
ionic 教程
关于我们
新闻动态
联系方式
招聘英才
安科实验室
帮助与反馈

安科网(Ancii)，中国第一极客网

Copyright © 2013 - 2019 Ancii.com

京ICP备18063983号 京公网安备11010802014868号