当Oracle查询出现效率问题时,我们往往须要了解问题所在,这样才干针对问题给出解决方式.Oracle提供了SQL运行的trace信息,当中包括了SQL语句的文本信息.一些运行统计,处理过程中的等待,以及解析阶段(如生成运行计划)产生的信息. 这些信息有助于你分解sql语句的服务时间和等待时间,并了解所用资源和同步点的具体信息,从而帮助你诊断存在的性能问题. 这篇文章介绍了怎么开启SQL跟踪和获取trace文件,具体信息例如以下. 开启SQL跟踪 从内部技术细节看,SQL跟踪是基于10046调试…

对象统计信息描写叙述数据是如何在数据库中存储的,查询优化器使用这些统计信息来做出正确的决定.Oracle中有三种类型的对象统计信息:表统计.列统计和索引统计.而在每种类型中,有细分为:表或索引级别的统计.分区级别统计和子分区级别的统计,后面两种仅仅有在对象被分区和具有子分区的情况下才可用. 统计信息相关视图 表统计信息 表/索引级别的统计 user_tab_statistics user_tables 分区级别的统计 user_tab_statistics user_tab_partitions…

tkprof它是Oracle它配备了一个命令直插式工具,其主要作用是将原始跟踪文件格文本文件的类型,例如,最简单的方法,使用下面的: tkprof ly_ora_128636.trc ly_ora_128636.txt tkprof带有非常多參数,在多数情况下,使用这些參数对你的分析将非常有帮助. tkprof參数 假设不带不论什么參数执行tkprof,它将打印出完整的參数列表,并带有简单的描写叙述.以下是对參数的说明: explain 为每一个SQL语句提供一个运行计划. 该參数须要指定用户.…

在缺乏的可视化工具来监控数据库性能的情形下,常用的脚本就派上用场了,下面提供几个关于Oracle性能相关的脚本供大家参考.以下脚本均在Oracle 10g测试通过,Oracle 11g可能要做相应调整. 1.寻找最多BUFFER_GETS开销的SQL 语句 --filename: top_sql_by_buffer_gets.sql --Identify heavy SQL (Get the SQL with heavy BUFFER_GETS) SET LINESIZE 190 COL sql…

查看连接数变化 CPU利用率到达100%,首先怀疑,是不是业务高峰活跃连接陡增,而数据库预留的资源不足造成的结果.我们需要查看下,问题发生时,活跃的连接数是否比平时多很多.对于RDS for PG,数据库上的连接数变化,可以从控制台的监控信息中看到.而当前活跃的连接数>可以直接连接数据库,使用下列查询语句得到: select count( * ) from pg_stat_activity where state not like '%idle'; 追踪慢SQL 如果活跃连接数的变化处于正常范围…

早期Oracle查询优化器的开销计算是基于运行SQL语句所须要的物理读,这种方法被叫做I/O开销模式(I/O cost model),这种方法的主要缺点是觉得单块读和多块读开销相当.在Oracle 8i中,初始化參数optimizer_index_caching和optimizer_index_cost_adj攻克了这个问题,但參数的默认值仅适用于报告系统和数据仓库.直到Oracle 9i,ORacle引入了一种新的CPU开销模式(CPU cost model),消除了这个缺陷,但必须提供数据库…

在创建索引时,我们往往希望可以预估索引大小,以评估对现有project环境的影响,我们也希望创建索引的过程可以最小化的影响我们正在执行的project环境,并能查看索引的状况. 预估索引大小 预估索引大小,最好的办法是在測试环境中创建它,測试环境最好包括完整的project环境数据,否则仅仅有通过部分数据来推算完整的索引大小. 假设不能搭建測试环境,Oracle提供了存储过程DBMS_SPACE.CREATE_INDEX_COST来估算索引的大小,以下是一个样例: declare used_by…

1.--查出耗时长的 10条SQL select * from (select v.sql_id, v.child_number, v.sql_text, v.elapsed_time, v.cpu_time, v.disk_reads, rank() over(order by v.elapsed_time desc) elapsed_rank from v$sql v) a ;…

思维导图 Oracle优化10-SQL_TRACE解读 Oracle优化11-10046事件 概述 当我们想了解一条SQL或者是PL/SQL包的运行情况时,特别是当他们的性能非常差时,比如有的时候看起来就好好像卡在什么地方一样,该如何入手呢? 是不是恨不得钻进去看下到底发生了什么? 好在Oracle提供了我们这样的一种方法使用SQL_TRACE来跟踪SQL的执行情况,通过SQLTRACE我们可以很容易的知道当前正在执行的SQL正在干什么. 以下操作基于Oracle Database 11g En…

思维导图 10053事件概述 我们在查看一条SQL语句的执行计划时,只看到了CBO最终告诉我们的执行计划结果,但是我们并不知道CBO为何要这样做. 特别是当执行计划明显失真时,我们特别想搞清楚为什么CBO会做出这样的一个选择,那么就可以用10053事件来分析SQL分析过程的trace文件. 同10046事件一样,10053事件依然无法在官网上找到相关的信息. 10053事件为我们真正的揭开蒙在CBO身上的面纱. 如何做10053事件分析 Connected to Oracle Database…