在为国投做SQL调优时,他们开发说不要动现在的SQL,调整一下执行计划即可,即查询某个表时执行特定的执行计划。乍一听,我是吓了一跳!
由于他们开发不让动SQL结构(该SQL经过PLSQL优化后有500多行,其是2层嵌套递归查询,外边一个SQL如图1-2,外层SQL的每一个列是一个子查询如下图1-1,递归子查询有32个),所以只能从SQL涉及的表、索引下手,查找问题的具体原因及解决办法。我的做法是,先查看了SQL涉及的表的统计信息,问题SQL涉及了8张表(最大的表有300M左右,小表只有几M大小),表的统计信息距离现在有3个月。通过与他们维护人员沟通,对问题SQL涉及的8张表进行了统计信息更新;然后在他们的测试环境中测试问题SQL,发现SQL执行的速度比之前的20多分钟缩减到15分钟,速度有提升但是不明显。然后,在不改变SQL结构的前提下,我做了如下调整(由于SQL涉及薪水查询,比较敏感,这里只能大概给出处理涉及的部分):
图 1-1 递归查询部分中添加的hint
图 1-2 外层查询中添加的hint
我的处理依据是:执行该sql生成的执行计划中有比较多的全表扫描(全表扫描的表是同一个表,大小有12M,全表扫的次数有18次之多),根据提示的全表扫描,又查询了谓词涉及的列中是否有索引,查询到谓词涉及的列中有索引但是执行计划没有走而是全表扫描。先不计较添加hint是否有利于执行速度的提高,我就试了一下。添加hint后,SQL的执行速度果然有提高,在他们的测试库中执行时间从15分钟减少到3分多钟,有明显的提高了。但是,在他们的生产库中进行优化实施后,发现SQL的执行速度不但没有改善反而严重下降了,从原来的20多分钟到3个多小时,简直让人发疯。
此时,我意识到,他们运行SQL是通过ORACLE DISCOVER运行的,执行后生成报表,就是薪资表,但是他们开发坚持该SQL执行客户端没问题。我只能在他们的生产库中生成执行计划查找原因,经过与测试环境中调整后的SQL执行计划对比发现个很严重的问题,如下图所示:
执行计划提示:当前SQL执行使用的执行计划是老版本,也就是说我们做的统计信息更新及hint的设置根本没任何作用,这就是导致SQL问题慢的具体原因了(也是他们开发说的让调整SQL执行计划,但是又不能改变SQL的结构)。
接下来,我做了如下步骤的操作:
1、业务用户登录数据库服务器
2、SQL>set autot on
SQL>set timing on
3、执行速度慢的SQL
4、观察执行计划尾部是否有如下提示:
Note -- plan table is old version
5、在4有提示的情况下(建议在服务器端sqlplus中执行)
SQL>drop table plan_table; --业务用户执行
SQL>@?/rdbms/admin/utlxplan; --具有DBA权限的用户(SYS)执行
6、再次重复执行速度慢的SQL3-5次,观察SQL速度是否有所改善
经过调整后,再次运行SQL,发现添加hint的SQL执行时间是3:15s,不添加hint的SQL执行时间是6::35s;终于,生产库的执行时间也能从20多分钟减少到3分多钟,达到了他们开发的基本要求了。总结:问题SQL执行慢的原因有3个,一是表的统计信息没有及时更新,二是表的索引没有被用上,三是plan_table缓存了执行计划。
ORACLE SQL调优之'PLAN_TABLE' is old version
时间: 2025-01-29 23:47:49
ORACLE SQL调优之'PLAN_TABLE' is old version的相关文章
ORACLE SQL调优之统计信息缺失导致的逻辑读暴增
2016年11月8日,接到广西负责人申告,说决策系统一条SQL平时执行2s左右能执行完,现在却要执行2:30多才能出结果,请求对其做处理. 操作系统:RHEL LINUX 6.4 数据库版本:11.2.0.4 首先,登录服务器查看数据库服务器的状态: [oracle@orcl ~]$ free -m total used free shared buffers cached Mem:
ORACLE SQL调优之执行计划与隐藏参数_complex_view_merging
最近,赤峰windows 版的11.2.0.3的oracle数据库出现一条sql语句执行非常慢,需要1天的时间还出不来,但是观察服务器的IO和CPU都是很空闲,并且将 该sql语句涉及的对象全部导出,然后分别导入其他机器oracle数据库与出现性能问题的数据库,发现其他机器数据库执行非常快而问题数据库依旧很慢.尝试 收集方案及表的统计信息后,再次执行sql语句还是没有改善,在问题处理的过程中,注意到一个很明显的问题,就是不管收集统计信息还是给sql加并行.使 用强制sql走hash,其执
ORACLE SQL调优案例一则
收到监控告警日志文件(Alert)的作业发出的告警邮件,表空间TEMPSCM2不能扩展临时段,说明临时表空间已经被用完了,TEMPSCM2表空间不够用了 Dear All: The Instance SCM2' alert log occured the ora errors ,please see the detail blow and take action for it. many thanks! ------------------------------------------
ORACLE SQL调优之记录一次trim函数引发的大表全表扫描
Oracle专家调优秘密
oracle Oracle专家调优秘密 前言 在过去的十年中, Oracle 已经成为世界上最专业的数据库之一.对于 IT 专家来说,就是要确保利用 Oracle 的强大特性来提高他们公司的生产力.最有效的方法之一是通过 Oracle 调优.它有大量的调整参数和技术来改进你的 Oracle 数据库的性能. Oracle 调优是一个复杂的主题.关于调优可以写整整一本书,不过,为了改善 Oracle 数据库的性能,有一些基本的概念是每个 Oracle DBA 都应该遵从的. 在这篇简介中,我们将简要
Oracle专家调优秘密(二)
oracle SQL调优 Oracle的SQL调优是一个复杂的主题,甚至是需要整本书来介绍Oracle SQL调优的细微差别.不过有一些基本的规则是每个Oracle DBA都需要跟从的,这些规则可以改善他们系统的性能.SQL调优的目标是简单的: . 消除不必要的大表全表搜索:不必要的全表搜索导致大量不必要的I/O,从而拖慢整个数据库的性能.调优专家首先会根据查询返回的行数目来评价SQL.在一个有序的表中,如果查询返回少于40%的行,或者在一个无序的表中,返回少于7%的行,那么这个查询都可以调整为
sql 调优 oracle 执行速度再快一点
问题描述 sql 调优 oracle 执行速度再快一点 select psf.pol_num, psf.bank_acct_num, cba_dda.bank_acct_nm from tbank_pos_slip_files psf, tclient_policy_links cpl_dda, tclient_bank_accounts cba_dda where cpl_dda.cli_num = cba_dda.cli_num and cpl_dda.bank_acct_typ = cba
Oracle专家调优秘密(一)
oracle 前言 在过去的十年中,Oracle已经成为世界上最专业的数据库之一.对于IT专家来说,就是要确保利用Oracle的强大特性来提高他们公司的生产力.最有效的方法之一是通过Oracle调优.它有大量的调整参数和技术来改进你的Oracle数据库的性能. Oracle调优是一个复杂的主题.关于调优可以写整整一本书不过,为了改善Oracle数据库的性能,有一些基本的概念是每个Oracle DBA都应该遵从的. 在这篇简介中,我们将简要地介绍以下的Oracle主题: --外部调整:我们应该记住
Oracle性能调优实践中的几点心得
oracle|心得|性能 很多的时侯,做Oracle DBA的我们,当应用管理员向我们通告现在应用很慢.数据库很慢的时侯,我们到数据库时做几个示例的Select也发现同样的问题时,有些时侯我们会无从下手,因为我们认为数据库的各种命种率都是满足Oracle文档的建议.实际上如今的优化己经向优化等待(waits)转型了,实际中性能优化最根本的出现点也都集中在IO,这是影响性能最主要的方面,由系统中的等待去发现Oracle库中的不足.操作系统某些资源利用的不合理是一个比较好的办法,下面把