Oracle 深入解析10053事件(一)

2014-11-24 18:09:53 · 作者: · 浏览: 6

本次我们主要讲解oracle 10053事件和实验,好多朋友可能对这个事件不是很熟悉,因为在日常运维中用到的不是很多。Oracle 10046和10053都是非官方trace sql的方法,在官方文档上是找不到相关资料的,但在MOS上可以找到。sql_trace是官方推荐的trace sql的方法,在官方文档上是可以查询出来的。


10053事件:用来描述oracle如何选择执行计划的过程,然后输出到trace文件里,共我们参考,因为我们经常看执行计划怎么执行的消耗了哪些资源,而不是常看执行计划怎么选择出来了的。


10053场景:当SQL语句执行时走的是错误的执行计划,而又找不到原因时,这时请用10053来分析一下原因。


10053特点:


(1)只可以了解oracle执行计划的选择过程


(2)无法获知代价的计算公式,因为这是oracle内部的商业机密,而且每个oracle版本的优化器计算公式都不相同差距还是蛮大的,不同版本的同一个语句的代价也不一样,优化器现在还不是很成熟,还有待完善。


(3)在这个里面我们重点要了解的是“代价”是如何计算出来的,然后我们才能了解执行计划是如何选择的。


(4)在10053中可以了解哪些因素影响sql的执行代价


(5)oracle 8i cost等价IO资源消耗 9i以后cost等价IO+CPU+网络+等待事件+其他代价


一般IO资源的权重比较大CPU权重较小


10053内容:


参数区:初始化参数,隐含参数,这些参数可以左右oracle工作方式


SQL区:执行的SQL语句,是否使用绑定变量,是否进行了转换操作


系统信息区:操作系统统计信息 cpu主频CPU执行时间IO寻址时间单块读时间多块读时间


对象统计信息区:


数据访问方式:访问方式不一样计算代价的方法也不一样,全表扫描走索引多表关联代价都不同


关联查询:把每张表都作为驱动表去组合,择优选择“代价”最小的关联方式,与哪个表在前无关系


代价的最后修正:oracle会对选择出来的代价再进行最后的修正,使其更准确一些,更合理一些


选择出最终执行计划:这个过程是非常快速的,毫秒级就搞定啦


实验环境


LEO1@LEO1> select * from v$version; 这是我的oracle edition


BANNER


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


Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production


PL/SQL Release 11.2.0.1.0 - Production


CORE 11.2.0.1.0 Production


TNS for Linux: Version 11.2.0.1.0 - Production


NLSRTL Version 11.2.0.1.0 - Production



1.验证全表扫描的成本计算公式,贴出执行计划和计算公式。


LEO1@LEO1> col sname for a20


LEO1@LEO1> col pname for a20


LEO1@LEO1> col pual1 for a30


LEO1@LEO1> col pual2 for a30


LEO1@LEO1> select * from sys.aux_stats$; 查看操作系统统计信息


SNAME PNAME PVAL1 PVAL2


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


SYSSTATS_INFO STATUS COMPLETED


SYSSTATS_INFO DSTART 08-15-2009 00:49


SYSSTATS_INFO DSTOP 08-15-2009 00:49


SYSSTATS_INFO FLAGS 1


SYSSTATS_MAIN CPUSPEEDNW 2657.0122


SYSSTATS_MAIN IOSEEKTIM 10


SYSSTATS_MAIN IOTFRSPEED 4096


SYSSTATS_MAIN SREADTIM


SYSSTATS_MAIN MREADTIM


SYSSTATS_MAIN CPUSPEED


SYSSTATS_MAIN MBRC


SYSSTATS_MAIN MAXTHR


SYSSTATS_MAIN SLAVETHR


说明


aux_stats$是sys管理员用户下的一个基表后缀为$,必须写schema才能查询到,所谓的基表就是给动态性能视图提供数据的原始表,由于基表非常重要,oracle规定不允许直接访问和修改基表,如果你比较了解这些那么另说了。这个表中记录了“操作系统统计信息”。Oracle会利用操作系统统计信息来修正执行计划的代价,也就是说这些信息是影响代价计算的因素之一。


注意:如果oracle收集了操作系统统计信息,那么CBO采用工作量统计模式计算代价


如果oracle没有收集操作系统统计信息,那么CBO采用非工作量统计模式计算代价,看上面MBRC没有参数值就说明还没有收集操作系统统计信息


这两个模式计算代价的公式是不同的。


SNAME:是指操作系统统计信息


PNAME:parameter name参数名


PVAL1:参数值


PVAL2:参数值


参数解释


FLAGS:标志


CPUSPEEDNW:非工作量统计模式下CPU主频,直接来自硬件


IOSEEKTIM:IO寻址时间(毫秒),直接来自硬件


IOTFRSPEED:IO传输速率(字节/毫秒)


SREADTIM:读取单个数据块的平均时间


MREADTIM:读取多个数据块的平均时间


CPUSPEED:工作量统计模式下CPU主频,根据当前工作量评估出一个合理值


MBRC:oracle收集完统计信息后评估出的一次多块读可以读几个数据块db_file_multiblock_read_count


MAXTHR:最大IO吞吐量(字节/秒)


SLAVETHR:平均IO吞吐量(字节/秒)


后面这6个参数是在oracle收集完统计信息后才能得出的参数值,有什么用呢?我来解释一下下


CBO在计算SQL语句的代价时,需要使用数据库对象例如表索引等对象统计数据,还要使用操作系统统计数据例如CPU周期IO速度数据块读时间等,选择花费时间最少的执行计划为最佳执行计划。


Oracle使用dbms_stats.gather_system_stats存储过程来收集操作系统统计信息,收集来的数据存放在sys.aux_stats$表中,如果我们做了收集操作那么会有统计数据,如果没有做就没有统计数据,这两种计算代价的方法是不同的,后续会讲。


dbms_stats.gather_system_stats语法


execute dbms_stats.gather_system_stats(


gathering_mode va