Category Archives: Oracle性能优化

同样的SQL,怎么突然就慢了?

本篇文章素材来源于某银行系统的一次性能问题分析。 许久没写这种troubleshooting类型的技术文章了,因为曾在服务公司呆过多年,工作原因,这方面之前做的多,听的更多,导致已经达到在自己认知维度下的一个小瓶颈,纯技术型的问题,稍微常见的基本都遇到过,非常少见的也基本是bug类(软件缺陷只能通过补丁或一些workaround的方式绕过去),感觉实在是没啥可写的。 另外注意,我这里说的“常见”指的是所有客户群中相对常见,而对单个具体客户而言,就非常可能从没有见过,这也是纯甲方技术人员(这里的纯甲方是指毕业就在一个甲方呆着,只能看到自己公司系统运行情况)的局限性,在早些年时,一些行业前辈们还会建议新的技术从业者即使想去甲方,也要先在乙方吃几年苦,能多见一些场景,再去甲方,这样会有比较准确的判断力,不至于轻易被乙方忽悠,也不会瞎挑毛病挑不到点子上让人鄙视。 前些日子有客户遇到问题,申请出差过去现场帮客户分析解决了,这个分析过程还是有些意思的,但最终结论简单来说就是DPR(直接路径读)问题,定位那一刻就觉得没啥可写的了,相关文章也太多了,今天突然想换个思路,看能否以故事线的方式来呈现这个问题,并解释所有技术细节,试图能够让所有人(包括技术小白)都能看得懂,所有用户相关信息均已做遮蔽处理。 首先你要忘掉这是个DPR的问题,让我们一起体会下这个分析问题的历程。 起初是被同事叫来帮忙一起分析客户问题,搞了一个微信群,客户先发了一些所谓异常时间的AWR、ASH、ADDM报告。 说明环境是普通X86服务器上的一套Oracle RAC数据库,版本是11.2.0.4,有应用补丁,触发BUG风险相对较低。嗯,还是要强调下,这里说的低只是说主观感觉上,因为11g已经摸爬滚打了那么多年,无数客户曾趟出的bug也都做了修复,遇到新bug的概率相对小而已,但并不是遇不到,一旦运气不好遇到就麻烦了,所以我们现在会强烈建议你升级到现有的LTS(长期支持版本)19c,可不要再用11g了。 这里提到非常有用的报告: AWR(Automatic Workload Repository) ASH(Active Session History) ADDM(Automatic Database Diagnostic Monitor) 其中ADDM相对用的少,它可以自动分析 AWR 中的性能数据,识别潜在的性能问题,并生成相应的建议报告。对于复杂问题可能不够准确,但至少也能给我们提供一个思路。 AWR可以记录某个时段下的真实负载情况,ASH可以在某个时段下看到是哪些会话在运行,非常好用,对等待事件的细致划分程度,也是其他数据库梦寐以求的东西。 和应用配合明确这个业务感知慢的SQL是否是AWR中显示的Top SQL,同时明确对应的具体sql_id,开始深入分析。 起初明确的sql_id,有一个对应的是一个存储过程,但此时没有进一步去查。 因为另外一个sql_id被认为更值得关注,这是一条简单的SQL,查询一个分区表,谓词条件只有一个定位到某一天的日期,该表是按月分区的。该SQL奇怪是正常的时候1分钟以内完成,异常的时候要接近10分钟完成,前者客户认为正常可接受,后者认为无法接受。 同样的SQL,查询不同日期,效率差距如此明显,另外客户反馈每天数据量基本相当,并没有数量级的差异。 此时最先想要排查的是是否有不同的执行计划? 可结果并不是,执行计划虽然是全表扫,但是前后并没有任何变化。 当时给的AWR中,我也看了IO部分,但只有3.3G的量级,感觉影响并不大,就忽略掉了。 后来去现场,实际动手分析发现,其实故障时刻远没有之前的AWR报告那样轻描淡写,重新收集后续故障时刻的AWR(1小时间隔)可以看到此时的DPR非常显著,达到了314G+,要是之前做紧急救援服务,看到这就已经结束了,直接凭借经验断定,DPR禁用掉再看效果。因为再慢的话,会影响其他客户问题的处理进度。 其实那种凭借历史经验直接判断问题虽然有很快很厉害的感觉,但却是不严谨的,现在我们要进一步确认细节,确认是否是这个问题。既然是DPR,再看TOP SQL中通过Reads的排序,发现Top 2都值得关注,因为物理读几千万,和后面SQL存在数量级上的差异: Top 1是一个存储过程,Top 2是一个SQL,经确认这个SQL也是存储过程之内的一条SQL,但是并不是之前我们分析的那条SQL,说明之前提供的方向有一定错误。这也说明这个Top 2才是问题根本。 同时配合ASH也可以看到的确就是这SQL引发的DPR,导致性能严重下降。 … Continue reading

Posted in Oracle性能优化, Oracle故障处理 | Tagged | Comments Off on 同样的SQL,怎么突然就慢了?

如何快速获取AWR中涉及到的表

最近遇到一个很少见的需求,是关于应用测试方面的。 具体来说,这个应用的测试需求要基于一个固定的时间点数据,而且只能测试一轮,再测试就需要还原到测试前状态。 因为我们使用的存储是分层的(热数据在Flash上,冷数据在传统机械盘),但因为每次测试都需要将数据库闪回还原到固定时间点,效果不佳,所以需要尽可能的预热测试涉及的对象。 方法也很简单,尽可能将所有使用到的相关对象提前全扫下,将其预热。 而相关对象,最佳方式是应用直接提供,这样最准确;但是各种原因,应用无法提供,那么DB层面观察,从测试期间的AWR获取,可以有不同维度: 1.精确找到所有I/O慢的TOP SQL,收集相关表进行预热 2.尽可能找更多AWR中的SQL,收集相关表进行预热 如果是第一种方式,需要人工去定位,SQL数量会很少的几条。 如果是第二种方式,会列出大量SQL,但工作量很大。 那有什么简单的方式吗? AWR本质就是文本内容,我们可以依据通常出现在表名前的关键字来定位。同样是有多种维度,比如SELECT语句表名前会有FROM关键字。 通过Shell列出: grep -o -i ‘\bFROM\s\+\(\w\+\)’ awr.html | sort -u 上面会把所有from关键字及之后的名字列出,然后再人为过滤下不是表的行,好为预热脚本做准备。 这个命令将使用 grep 工具, -o 表示只输出匹配的部分 -i 表示不区分大小写 \b 表示单词边界 FROM 表示匹配 FROM 关键字 \s+ 表示一个或多个空白字符 (\w+) 表示一个或多个字母数字字符(表名或视图名) sort … Continue reading

Posted in Oracle性能优化 | Tagged | Comments Off on 如何快速获取AWR中涉及到的表

小知识:PDML的注意事项补充

关于PDML,之前在 [并行,想说爱你不容易]中的第一节就介绍过,今天在客户现场协助测试时又遇到几个有关PDML的问题,都蛮典型的,记录一下 Continue reading

Posted in Oracle性能优化 | Tagged , , , | Comments Off on 小知识:PDML的注意事项补充

并行,想说爱你不容易

在计算机的世界里,如果能用好并行这件利器,可以大幅提升性能;如果没用好,轻则达不到预期性能,重则会连带影响到整个系统的可用性。 Continue reading

Posted in Oracle性能优化 | Tagged , | Comments Off on 并行,想说爱你不容易

Oracle之SQL优化专题03-如何看懂SQL的执行计划

主要介绍下如何看懂SQL的执行计划。毕竟如果SQL的执行计划都看不懂,那优化就无从谈起了。 Continue reading

Posted in Oracle性能优化 | Tagged , | Comments Off on Oracle之SQL优化专题03-如何看懂SQL的执行计划

Oracle之SQL优化专题02-稳固SQL执行计划的方法

首先构建一个简单的测试用例来实际演示。 Continue reading

Posted in Oracle性能优化 | Tagged , , | Comments Off on Oracle之SQL优化专题02-稳固SQL执行计划的方法

使用COE脚本绑定SQL Profile

日常运维中,经常会遇到需要绑定好的执行计划的场景。
简单来说,就是将一个sql_id绑定好的plan_hash_value。如果没有使用到绑定变量,还需要把force_match设置为true。 Continue reading

Posted in Oracle性能优化 | Tagged , | Comments Off on 使用COE脚本绑定SQL Profile

记录一则完整的SPA(10g->11g)测试过程

因为Oracle跨越大版本,优化器、新特性变动较多,需要进行SPA测试比对前后期性能差异。 Continue reading

Posted in Oracle性能优化 | Tagged | Comments Off on 记录一则完整的SPA(10g->11g)测试过程

Oracle之SQL优化专题01-查看SQL执行计划的方法

在我2014年总结的“SQL Tuning 基础概述”中,其实已经介绍了一些查看SQL执行计划的方法,但是不够系统和全面。 Continue reading

Posted in Oracle性能优化 | Tagged , , , , , | Comments Off on Oracle之SQL优化专题01-查看SQL执行计划的方法

关于Oracle开启自动收集统计信息的SPA测试

本着尽可能减少对生产Primary环境影响的原则,在Standby DG环境临时开启snapshot standby来进行SPA(SQL Performance Analyze)测试,比对开启统计信息自动收集前后的性能差异 Continue reading

Posted in Oracle性能优化 | Tagged | Comments Off on 关于Oracle开启自动收集统计信息的SPA测试