- 浏览: 485341 次
- 性别:
- 来自: OnePiece
文章分类
- 全部博客 (196)
- --------- 基础----------- (0)
- java 碎碎念 (12)
- java 并行编程 (11)
- java I/O (6)
- java Charset & Encoding (2)
- spring学习笔记 (8)
- 正则表达式 (5)
- web前端-javascript (11)
- web前端-jQuery (7)
- web前端-碎碎念 (1)
- mybatis (0)
- 数据库-通用 (8)
- 数据库-oracle (20)
- nosql-redis (11)
- nosql-mongoDB (1)
- xml (2)
- log4j (2)
- uml (3)
- web services: soap/wsdl (6)
- soa-tuscany (2)
- linux (6)
- ----------修养----------- (0)
- 深入理解java虚拟机 (7)
- java 设计模式 (9)
- 数据结构和算法 (2)
- 读书笔记--代码整洁之道 (2)
- 计算机基础 (1)
- -----------践行---------- (0)
- 重构(refactor) (7)
- jvm-诊断 (4)
- 数据库-让oracle跑得更快 (7)
- Nginx (6)
- ehcache (2)
- 短信开发 (1)
- Servlet+Filter+Listener (2)
- 运维 (6)
- 问题记录 (38)
- 杂七杂八 (12)
最新评论
-
zhanggang807:
第二种方法比较好
<spring> 定时任务每次都执行两次的问题,慎用new ClassPathXmlApplicationContext() -
assasszt:
谢谢分享,很清楚的讲明了原理。
字符集与字符编码简介 -
su0nils000:
难得的笔记
<进阶-2> 打造高效正则表达式 -
足至迹留:
mini188 写道用MD5来解决碰撞是不是也是可行的呢?个人 ...
Hash简介 -
mini188:
用MD5来解决碰撞是不是也是可行的呢?
Hash简介
如果要分析某条(不是整体性能,后面还会讲到awr报告,会再次说明)sql的性能问题,通常来讲,首先要去看sql的执行计划,看看sql的每一步执行计划是否存在问题。如果一条sql平时执行得都很好,却有一天突然性能很差,如果排除了系统资源和阻塞的原因,那么基本上可以断定是执行计划出了问题。
看懂执行计划便成了sql优化(大多数情况下,sql优化指的是sql的性能问题定位)的先决条件。
在讨论sql执行计划之前,需要知道执行计划当中一个非常重要的概念:Cardinality(基数)。
5.1 Cardinality (基数)
在看执行计划的每一步操作时,当前操作的Cardinality值表示CBO预期从一个行源(row source)返回的记录数,这个行源可能是一个表,一个索引,也可能是一个子查询。比如:
在执行计划中,Card就是Cardinality的缩写(在10g之后,Card值被rows替换),它表示CBO估算当前操作预期获取的记录数。
在上面的执行计划中,CBO估算从T_INX索引中预期获取193个索引键值(card=193),通过这193个键值,估算从表中返回的结果集为482条记录。
Cardinality的值对于CBO做出正确的执行计划来说至关重要。如果CBO获得的Cardinality值不够准确(通常是没有做分析或者分析数据过旧导致),在执行成本计算上就会出现偏差,从而导致CBO错误地制定出执行计划。比如:
我们创建了一张表T,表里id=99的记录有1条,id=1的记录有50585条,相对id值来说,这是一个数据分布非常不均匀的表。
我们查询select /*+ dynamic_sampling(t 0) */ * from t where id=1;
执行计划:
表T没有被分析过,提示/*+ dynamic_samping(t 0) */的目的是让CBO无法通过动态采样获得表中实际数据的情况,此时CBO只能根据数据字典表中表T的非常有限的信息(比如表的extents数量,数据块的数量)来猜测表中的数据。
从执行计划看,CBO猜出表中id=1的数据有194条,这个数值相对于表的总数来说是一个比较小的值,所以CBO选择了索引而不是全表扫描。
但实际情况是:
通过动态采样(10g下,如果表没有做过分析,oracle自动通过动态采样的方式来收集分析数据),CBO估算出表中的实际数据量52987,从执行计划中看到,这个数值非常接近表的实际数据50585,CBO判断id=1的数据基本上等同于表中的数据,所以选择了全表扫描。
可以使用
在多表关联查询或sql中有子查询时,每个关联表或子查询的Cardinality的值对主查询的影响非常大,甚至可以说,CBO就是依赖于各个关联表或子查询的cardinality值来计算出最后的执行计划。
对于多表查询,CBO使用每个关联表返回的行数(Cardinality)决定使用什么样的访问方式来做表关联(比如nested loops或是hash join);对于子查询,它的Cardinality将决定子查询是使用索引还是使用全表扫描的方式访问数据。
Hash join通常适用于两张关联的表都比较大的时候,否则采用nested loops。
5.2 sql的执行计划
如果一条sql的性能出了问题,首先应该看一下它的执行计划,以便于确定或猜测问题的所在。
生成sql的执行计划是oracle在对sql做硬分析时的一个非常重要的步骤,它制定出一个方案告诉oracle在执行这条sql时以什么样的方式访问数据:索引还是全表扫描,是hash join还是nested loops join等。
执行计划可以使用以下方式(当然还有其他方式)获得:
(1) explain plan for
(2) sqlplus命令 set autotrace on
(3) 第三方软件提供的GUI工具,最常见的是Toad, pl/sql
第二种方式除了生成执行计划之外,还可以输出sql消耗的各种资源的统计,比如LIO(逻辑读), PIO(物理读)等信息。
方式一:
Explain plan for select * from t1, t2 where t1.id=t2.id;
Select * from table(dbms_xplan.display);
方式二:
我们看到,set autotrace的语法不但可以生成执行计划,还可以跟踪sql,并获取sql执行中各种资源的使用情况。
上面两种方法都可以用来生成sql的执行计划,下面讨论如何看懂一个执行计划。
下面看这样的一个执行计划:
Select t1.* from t1, t2 where t1.id=t2.id and t1.id=5 and t2.name=’A’;
看执行计划时:
(1)首先从缩进度最大的行读取,在这个执行计划中,id=3和id=4是最先被执行的;当两行的缩进一样时,最上面的最先执行,也就是id=3的先执行;
(2)然后是缩进度次之的行,这里就是id=2的行;然后是id=1,最后是id=0的行。
把上面的过程翻译成语言描述大概如下:
1)从T2表第一行开始读取,全表扫描查看每一行是否符合下面的条件:
T2.id=5 and t2.name=’A’
2)如果符合就拿出一行来,然后到索引IND_T1中找到id=5的值,然后重复,直到把整个T2表扫描完,这个过程叫做nested loops.
3)当整个T2表被扫描完之后,会产生一个结果集,这个结果集是IND_T1的一个索引集,然后oracle根据索引键值上的rowid去T1表中找到相应的记录,就是这一步:
Operation: TABLE ACCESS BY INDEX ROWID
4)然后将结果返回:
Operation: select statement
执行计划如果显示是access,就表示这个谓词条件的值将会影响数据的访问路径(表还是索引,在这里是索引);而filter表示谓词条件的值并不会影响数据访问路径,只起到过滤的作用。
如果执行计划最下面的一步是:
Note
-----
-Dynamic sampling used for this statement
这一步提示用户CBO当前使用的技术,需要用户在分析执行计划时考虑到这些因素,比如现在提示注意的信息时,当前表示用了动态采集,通过这个提示我们就知道,这个表可能没有做过分析。
如果表分析过,但是分析信息过旧,这时候CBO就不会再使用动态采样,而是使用这些旧的分析数据,从而可能导致错误的执行计划。
另外,如果我们通过hint强制使用RBO时,会有下面提示信息:
Note
-----
-Rule based optimizer used (consider using cbo)
它提醒我们,当前使用的是基于规则的优化器(RBO),如果你在做sql性能优化时,看到执行计划提示这个信息,那么必须引起注意,分析一下这个执行计划是否是合适的,是否是人为的失误或者其他的原因导致的RBO被使用。
看懂执行计划便成了sql优化(大多数情况下,sql优化指的是sql的性能问题定位)的先决条件。
在讨论sql执行计划之前,需要知道执行计划当中一个非常重要的概念:Cardinality(基数)。
5.1 Cardinality (基数)
在看执行计划的每一步操作时,当前操作的Cardinality值表示CBO预期从一个行源(row source)返回的记录数,这个行源可能是一个表,一个索引,也可能是一个子查询。比如:
在执行计划中,Card就是Cardinality的缩写(在10g之后,Card值被rows替换),它表示CBO估算当前操作预期获取的记录数。
在上面的执行计划中,CBO估算从T_INX索引中预期获取193个索引键值(card=193),通过这193个键值,估算从表中返回的结果集为482条记录。
Cardinality的值对于CBO做出正确的执行计划来说至关重要。如果CBO获得的Cardinality值不够准确(通常是没有做分析或者分析数据过旧导致),在执行成本计算上就会出现偏差,从而导致CBO错误地制定出执行计划。比如:
Create table t as select 1 id, object_name from dba_objects; Update t set id=99 where rownum=1; Commit; Create index t_ind on t(id);
我们创建了一张表T,表里id=99的记录有1条,id=1的记录有50585条,相对id值来说,这是一个数据分布非常不均匀的表。
我们查询select /*+ dynamic_sampling(t 0) */ * from t where id=1;
执行计划:
表T没有被分析过,提示/*+ dynamic_samping(t 0) */的目的是让CBO无法通过动态采样获得表中实际数据的情况,此时CBO只能根据数据字典表中表T的非常有限的信息(比如表的extents数量,数据块的数量)来猜测表中的数据。
从执行计划看,CBO猜出表中id=1的数据有194条,这个数值相对于表的总数来说是一个比较小的值,所以CBO选择了索引而不是全表扫描。
但实际情况是:
通过动态采样(10g下,如果表没有做过分析,oracle自动通过动态采样的方式来收集分析数据),CBO估算出表中的实际数据量52987,从执行计划中看到,这个数值非常接近表的实际数据50585,CBO判断id=1的数据基本上等同于表中的数据,所以选择了全表扫描。
可以使用
exec dbms_stats.gather_table_stats(user, ‘t’, cascade=>true);来启动表的数据收集。
在多表关联查询或sql中有子查询时,每个关联表或子查询的Cardinality的值对主查询的影响非常大,甚至可以说,CBO就是依赖于各个关联表或子查询的cardinality值来计算出最后的执行计划。
对于多表查询,CBO使用每个关联表返回的行数(Cardinality)决定使用什么样的访问方式来做表关联(比如nested loops或是hash join);对于子查询,它的Cardinality将决定子查询是使用索引还是使用全表扫描的方式访问数据。
Hash join通常适用于两张关联的表都比较大的时候,否则采用nested loops。
5.2 sql的执行计划
如果一条sql的性能出了问题,首先应该看一下它的执行计划,以便于确定或猜测问题的所在。
生成sql的执行计划是oracle在对sql做硬分析时的一个非常重要的步骤,它制定出一个方案告诉oracle在执行这条sql时以什么样的方式访问数据:索引还是全表扫描,是hash join还是nested loops join等。
执行计划可以使用以下方式(当然还有其他方式)获得:
(1) explain plan for
(2) sqlplus命令 set autotrace on
(3) 第三方软件提供的GUI工具,最常见的是Toad, pl/sql
第二种方式除了生成执行计划之外,还可以输出sql消耗的各种资源的统计,比如LIO(逻辑读), PIO(物理读)等信息。
方式一:
Explain plan for select * from t1, t2 where t1.id=t2.id;
Select * from table(dbms_xplan.display);
方式二:
我们看到,set autotrace的语法不但可以生成执行计划,还可以跟踪sql,并获取sql执行中各种资源的使用情况。
上面两种方法都可以用来生成sql的执行计划,下面讨论如何看懂一个执行计划。
下面看这样的一个执行计划:
Select t1.* from t1, t2 where t1.id=t2.id and t1.id=5 and t2.name=’A’;
看执行计划时:
(1)首先从缩进度最大的行读取,在这个执行计划中,id=3和id=4是最先被执行的;当两行的缩进一样时,最上面的最先执行,也就是id=3的先执行;
(2)然后是缩进度次之的行,这里就是id=2的行;然后是id=1,最后是id=0的行。
把上面的过程翻译成语言描述大概如下:
1)从T2表第一行开始读取,全表扫描查看每一行是否符合下面的条件:
T2.id=5 and t2.name=’A’
2)如果符合就拿出一行来,然后到索引IND_T1中找到id=5的值,然后重复,直到把整个T2表扫描完,这个过程叫做nested loops.
3)当整个T2表被扫描完之后,会产生一个结果集,这个结果集是IND_T1的一个索引集,然后oracle根据索引键值上的rowid去T1表中找到相应的记录,就是这一步:
Operation: TABLE ACCESS BY INDEX ROWID
4)然后将结果返回:
Operation: select statement
执行计划如果显示是access,就表示这个谓词条件的值将会影响数据的访问路径(表还是索引,在这里是索引);而filter表示谓词条件的值并不会影响数据访问路径,只起到过滤的作用。
如果执行计划最下面的一步是:
Note
-----
-Dynamic sampling used for this statement
这一步提示用户CBO当前使用的技术,需要用户在分析执行计划时考虑到这些因素,比如现在提示注意的信息时,当前表示用了动态采集,通过这个提示我们就知道,这个表可能没有做过分析。
如果表分析过,但是分析信息过旧,这时候CBO就不会再使用动态采样,而是使用这些旧的分析数据,从而可能导致错误的执行计划。
另外,如果我们通过hint强制使用RBO时,会有下面提示信息:
Note
-----
-Rule based optimizer used (consider using cbo)
它提醒我们,当前使用的是基于规则的优化器(RBO),如果你在做sql性能优化时,看到执行计划提示这个信息,那么必须引起注意,分析一下这个执行计划是否是合适的,是否是人为的失误或者其他的原因导致的RBO被使用。
发表评论
-
<让oracle跑得更快-7> AWR性能报告
2015-03-01 22:45 2073AWR是oracle 10g下提供的一 ... -
<让oracle跑得更快-6> 绑定变量
2015-02-28 21:52 1197变量绑定是OLTP系统中一 ... -
<让oracle跑得更快-4> 优化器(optimizer)
2015-02-27 21:27 2008Oracle数据库中优化器(o ... -
<让oracle跑得更快-3> latch和等待
2015-02-27 21:18 1123经常有人把latch造成的 ... -
<让oracle跑得更快-2> 锁和阻塞
2015-02-26 22:24 11262.1 锁和阻塞 首先,注意区别并发(concurrency) ... -
<让oracle跑得更快-1> 引起数据库性能问题的因素
2015-02-26 22:04 1498此《让oracle跑得更快》 ... -
OLTP(联机事务处理)和OLAP(联机分析处理) 【转】
2015-02-12 14:13 1209做数据库优化时,一定要先了解数据库支撑的应用特点,不同类型的应 ... -
<oracle优化>(url收藏)
2015-02-11 22:18 7871. CBO & RBO Rule Based Opt ... -
<oracle-11> 数据类型
2015-02-08 20:06 2503选择一个正确的数据类 ... -
<oracle-10> 索引
2015-02-01 21:19 1984索引是应用设计和开发的一个重要方面。如果有太多的索引,修改(插 ... -
<oracle-9> 数据库表
2015-01-30 15:44 12799.1 表类型 Oracle主要有 ... -
<oracle-8> redo和undo
2015-01-26 22:23 1621本章介绍oracle数据库中 ... -
<oracle-7> 事务
2015-01-26 11:07 1516事务(transaction)是数 ... -
<oracle-6> 并发多版本控制
2015-01-12 21:17 14256.1 什么是并发控制 并 ... -
<oracle-5> 锁(lock)和闩(latch)
2015-01-07 21:11 2699开发多用户、数据库驱动的应用时,最大的难点之一是:一方面要力争 ... -
<oracle-4> oracle进程
2015-01-06 23:02 1361Oracle中的各个进程要完成某个特定的任务或一组任务,每个进 ... -
<oracle-3> 内存结构
2015-01-05 22:20 1513这一篇主要讨论oracle的3 ... -
<oracle-2> oracle文件
2014-12-22 20:57 1102与oracle实例相关的文件只有下面几种: 参数文件(para ... -
<Oracle-1> oracle体系结构概述
2014-12-21 22:02 1159本系列主要参考《Oracle ...
相关推荐
<driver-class>oracle.jdbc.driver.OracleDriver</driver-class> <user-name>nana</user-name> <password>easyflowgp</password> <min-pool-size>20</min-pool-size> <max-pool-size>100</max-pool-size> ...
让Oracle跑得更快.pdf-Oracle 10g 性能分析与优化思路
让Oracle跑得更快(扫描版).pdf 高清下载
--driver-name>oracle.jdbc.OracleDriver</driver-name--> <!--url>jdbc:log4jdbc:oracle:thin:@10.15.0.138:1521:orcl</url--> <!--url>jdbc:log4jdbc:oracle:thin:@192.168.10.11:1521:orcl</url--...
让Oracle跑得更快2基于海量数据的数据库设计与优化
本次采用手动xtts的方式,该方法适用任意平台之间,源端>=oracle10.2.0.3,目标端>=11.2.0.4,包括windows<->linux,aix<->linux,windows<->aix,solaris<->windows,solaris<->linux,aix<->solaris,hp-unix<->aix,hp-...
让oracle跑得更快!如果你想深入学习oracle,如果你想学习优化oracle,下它吧!
<--------------------只做验证----...为便于验证oracle<1>/<2>的sql语句而上传的配套sql格式数据库源文件 <--------------------只做验证--------------------> <--------------------只做验证-------------------->
让Oracle跑得更快(2):基于海量数据的数据库设计与优化 - 谭怀远。
让Oracle跑得更快基于海量数据的数据库设计与优化].谭怀远.第2版
Oracle数据库分区和压缩技术应用——让Oracle跑得更快.pdf
让Oracle跑得更快.pdf 个人收集电子书,仅用学习使用,不可用于商业用途,如有版权问题,请联系删除!
Oracle的执行计划--下,Oracle的执行计划--下,Oracle的执行计划--下
--<add key="typeName" value="Common.DataAccess.OracleDbOperator"/>--><!-- Oracle方式 --> <!--<add key="typeName" value="Common.DataAccess.OleDBOperator"/>--><!-- Access(兼容)方式 --> </configuration...
让Oracle跑得更快2:基于海量数据的数据库设计与优化 谭怀远 清晰扫描版 带书签目录
在: \jboss-4.2.2.GA\docs\examples\jca\oracle-ds.xml,拷贝oracle-ds.xml 到: \jboss-4.2.2.GA\server\all\deploy 配置内容: <jndi-name>OracleDS</jndi-name> <connection-url>jdbc:oracle:thin:@localhost:1521...
让ORACLE跑得更快。。。。。。。。。。。。。。。。。。。
Oracle的执行计划--上,Oracle的执行计划--上,Oracle的执行计划--上
通过文档可以让你了解到是什么在影响着数据库的性能,如何才能让数据库更为优化,让系统速度更快