- 浏览: 496930 次
- 性别:
- 来自: 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 2134AWR是oracle 10g下提供的一 ... -
<让oracle跑得更快-6> 绑定变量
2015-02-28 21:52 1252变量绑定是OLTP系统中一 ... -
<让oracle跑得更快-4> 优化器(optimizer)
2015-02-27 21:27 2060Oracle数据库中优化器(o ... -
<让oracle跑得更快-3> latch和等待
2015-02-27 21:18 1171经常有人把latch造成的 ... -
<让oracle跑得更快-2> 锁和阻塞
2015-02-26 22:24 11712.1 锁和阻塞 首先,注意区别并发(concurrency) ... -
<让oracle跑得更快-1> 引起数据库性能问题的因素
2015-02-26 22:04 1547此《让oracle跑得更快》 ... -
OLTP(联机事务处理)和OLAP(联机分析处理) 【转】
2015-02-12 14:13 1256做数据库优化时,一定要先了解数据库支撑的应用特点,不同类型的应 ... -
<oracle优化>(url收藏)
2015-02-11 22:18 8261. CBO & RBO Rule Based Opt ... -
<oracle-11> 数据类型
2015-02-08 20:06 2565选择一个正确的数据类 ... -
<oracle-10> 索引
2015-02-01 21:19 2044索引是应用设计和开发的一个重要方面。如果有太多的索引,修改(插 ... -
<oracle-9> 数据库表
2015-01-30 15:44 13239.1 表类型 Oracle主要有 ... -
<oracle-8> redo和undo
2015-01-26 22:23 1656本章介绍oracle数据库中 ... -
<oracle-7> 事务
2015-01-26 11:07 1551事务(transaction)是数 ... -
<oracle-6> 并发多版本控制
2015-01-12 21:17 14686.1 什么是并发控制 并 ... -
<oracle-5> 锁(lock)和闩(latch)
2015-01-07 21:11 2769开发多用户、数据库驱动的应用时,最大的难点之一是:一方面要力争 ... -
<oracle-4> oracle进程
2015-01-06 23:02 1409Oracle中的各个进程要完成某个特定的任务或一组任务,每个进 ... -
<oracle-3> 内存结构
2015-01-05 22:20 1560这一篇主要讨论oracle的3 ... -
<oracle-2> oracle文件
2014-12-22 20:57 1142与oracle实例相关的文件只有下面几种: 参数文件(para ... -
<Oracle-1> oracle体系结构概述
2014-12-21 22:02 1228本系列主要参考《Oracle ...
相关推荐
“让Oracle跑得更快2:基于海量数据的数据库设计与”这一主题,正是聚焦于解决这一问题,旨在通过合理的数据库设计和性能优化策略,提升Oracle在处理大规模数据集时的效率。 ### 一、海量数据处理 海量数据处理的...
标题和描述均指向一个主题:“让Oracle跑得更快”,这显然是一份专注于提升Oracle数据库性能的资料。Oracle作为全球领先的关系型数据库管理系统之一,其性能优化对于提高数据处理速度、增强系统响应能力和确保业务...
由于文件中的部分内容是重复的链接,我们将忽略这些重复内容,并专注于标题和描述中提到的“让oracle跑得更快”以及“如果你深入学习oracle,如果你想学习优化oracle,下它吧!”。以下是对这些知识点的详细说明: ...
鉴于提供的文件信息中没有包含可分析的具体内容,我无法针对"让Oracle跑得更快.pdf"这一电子书提供详细的知识点。然而,基于标题中提到的“Oracle”和“跑得更快”,我可以提供一些普遍性的知识点和建议,这些建议...
《让Oracle跑得更快》是针对Oracle 10g数据库性能分析与优化的一份深入指南。Oracle数据库系统作为全球广泛使用的数据库管理系统之一,其性能优化对于企业数据处理效率至关重要。Oracle 10g版本在性能方面引入了许多...
第5章 执行计划 85 5.1 cardinality (基数) 85 5.2 sql的执行计划 94 第6章 hint 109 6.1 和优化器相关的hint 115 6.1.1 all_rows和first_rows(cbo) 115 6.1.2 rule hint 117 6.2 访问路径相关的hint 117 6.2.1 full...
"让Oracle跑得更快1、2集合"的主题显然聚焦于如何提升Oracle数据库的运行效率,这涉及到多个方面的知识,包括但不限于SQL优化、索引策略、数据库设计、存储结构、并行处理以及资源管理等。 首先,SQL优化是提高...
不过,根据标题《让Oracle跑得更快2:基于海量数据的数据库设计与优化》以及描述中的作者名“谭怀远”,我们可以推测该文档应是一本专注于Oracle数据库性能提升和海量数据处理的优化指南。以下将基于这一主题,结合...
《让Oracle跑得更快 2 基于海量数据的数据库设计与优化》是一本深入探讨如何在大数据环境下提升Oracle数据库性能的专业书籍。该书详细阐述了针对大规模数据的数据库设计策略以及优化技术,旨在帮助读者理解并解决...
### 让你的Oracle跑得更快 #### 概述 在当今快速发展的信息技术领域,数据库性能优化已成为企业提高竞争力的关键因素之一。Oracle作为全球最流行的数据库管理系统之一,在金融、电信、制造等多个行业中广泛应用。...
《让Oracle跑得更快》是一本专注于Oracle数据库性能优化的专业书籍。通过阅读这本书,你可以深入理解如何提升Oracle数据库的运行效率,从而优化整个系统的性能。Oracle数据库是全球广泛使用的大型企业级数据库系统,...
《让Oracle跑得更快:基于海量数据的数据库设计与优化》是谭怀远先生的著作,专注于讲解如何在处理大规模数据时提升Oracle数据库的性能。这本书对于深入理解Oracle数据库的内部机制、设计高效的数据库架构以及实施...
《让Oracle跑得更快:基于海量数据的数据库设计与优化》是谭怀远先生的著作,专注于探讨如何在处理大规模数据时提升Oracle数据库的性能。这本书的第二版深入讲解了Oracle数据库在面对海量数据时的设计策略和优化技巧...
Oracle优化方面的书籍,需要你已经有一定的SQL基础,里面介绍了一系列的优化技巧,也较会你去了解Oracle底层的执行计划。本书籍为chm格式的,发现打开为不可显示的,请察看文件属性,然后将锁定...
### 让Oracle跑得更快:Oracle调优知识详解 #### 一、Oracle调优基础知识 在探讨具体的调优技巧之前,我们首先需要了解一些Oracle数据库的基础知识,这将有助于我们更好地理解后续的内容。 ##### 1.1 Oracle架构...
国内第一本真正意义上从工作经验出发,以作者的心得体会全面论述...书中涉及很多新的性能话题,比如执行计划,bind peeking,并行执行,10046及10053事件,AWR报告等,基本上涵盖了所有Oracle数据库性能方面的知识。
例如,某个应用系统在高峰期出现大量慢查询现象,通过使用AWR报告定位到问题SQL语句后,可以通过优化这些语句的执行计划、调整相关索引等方式来解决问题。 综上所述,Oracle 10g性能分析与优化是一个复杂但重要的...
### 让Oracle跑得更快:优化策略与实践 在当今数据驱动的世界中,数据库性能对于企业的业务连续性和竞争力至关重要。Oracle作为一款广泛使用的数据库管理系统,其性能优化是IT专业人士关注的重点之一。“让Oracle跑...