Oracle案例：分析10053跟踪文件

首先介绍与CBO计算成本有关的一些参数说明，介绍了CBO在查询中如何计算成本。接着给出10053跟踪文件分析的一般方法，最后结合一个具体跟踪文件，对如何分析10053跟踪文件进行详细阐述。 1. 关于Oracle案例学习 Oracle案例学习主要是作为一种工具，主要提供对复杂事件、进程、过程以及一系列相关事件的信息与知识。每个案例都是在处理实际问题的经验基础上编写的。每个学习案例包含一定的技能级别。技能级别指文档的阅读者在学习此案例之前，应该具备什么样的技能级别。有以下几个级别：专家级：在相关主题领域有丰富经验中级：在相关主题领域有一定的经验入门级：在相关主题领域没什么经验本案例建议的级别：专家级 2. 案例学习摘要本案例使用跟踪文件，阐述分析10053跟踪文件的方法体系。注意，10053事件跟踪文件主要用于辅助oracle开发者以及技术支持来诊断优化器相关的问题，它随着新版本或者补丁集而有所变化。本文的主要目的不是对10053跟踪文件提供全面的参考，而是介绍oracle工程师怎样使用这种跟踪文件。同时，我们将窥探CBO在查询中如何计算成本，以及CBO是如何最终获得执行计划的。需要指出的是，CBO在估算成本的时候，会随着版本的变化，其算法会有不同。这里我们将会分析一个糟糕的执行计划，并判断出CBO是如何计算成本并导致不好的计划的。我们会在不同地方比较10053跟踪，但主要精力还是放在这个糟糕的计划是如何计算成本的。良好的执行计划一般而言比不好的执行计划（其中没有考虑使用索引）更简短。检查10053的原因一般是为了搞清楚CBO为什么这样进行选择。10053可以帮我们回答诸如“索引为什么没被使用”之类的问题。“CBO为什么要选择全表扫描？” 。一般来说，10053不是处理性能问题时最先使用的方法---在这方面，查看执行计划并使用tkprof工具能更好的获取信息。10053用于深入CBO进行选择的原因分析。 3. 案例历史执行一个未使用提示的sql语句（一个包含3种连接的select语句）需要9个小时，而如果使用"NO_INDEX"提示，将会在4分钟内执行完。表使用的是分区表，而且用到了并行查询。另外，用户将"OPTIMIZER_INDEX_CACHING"设置为70（不知用户为什么这么做，我们猜测可能是因为当时他们并没有得到想要的执行计划才这么做）。此参数设置效果可以使单块索引I/O下降70%。使用10053跟踪，获取未加提示（“不好的”）的执行计划与加提示（“好的”）的执行计划。两个执行计划的主要不同点是，未加提示的执行计划使用nested嵌套循环连接方式，内层连接使用的是INDEX FULL SCAN（不是index fast full scan）操作来作为内层行集。加提示的执行计划使用哈希连接，INDEX FAST FULL SCAN （IFF）操作的结果集作为内层行集。注意，就本案例而言，新版本中使用10053产生的跟踪文件可能会发生很大变化。一般而言，新版本的跟踪文件比较容易阅读，在"预分析工作"部分需要做的工作较少。

Oracle商务智能套件产品简介修改Session存放方式为MySQL的类相关资讯 oracle

[INS-32052] Oracle基目录和Oracle （07/22/2014 07:41:41）
Oracle 4个大对象（lobs）数据类型（02/03/2013 12:33:05）
Oracle按时间段分组统计（07/26/2012 10:36:48）

[Oracle] dbms_metadata.get_ddl的（07/12/2013 07:37:30）
Liferay Portal 配置使用Oracle和（07/31/2012 20:07:18）
Concurrent Request:Inactive （07/20/2012 07:44:05）

本文评论查看全部评论（0）