且听AWR之父解读AWR报告

AWR报告是数据库性能评估和优化的重要参考,将数据库的问题已量化的形式展现出来,给DBA带来了很多便利。然而AWR中的内容是非常多的,如何才能以最佳的方式解读AWR报告,最高效地找出数据库的性能问题所在呢?

在刚刚过去的OOW2017大会上,AWR之父Graham 做了一个主题分享,名为“AWR Analysis for Admins, Developers and Architects” 运维、开发及架构师都应该一读的AWR报告分析。演讲ppt已在oow官网公开,接下来我们简单解读一下分享的主要内容。希望对大家有所帮助和借鉴。

注:原ppt可以关注数据和云(OraNews)回复关键字2017oow 获取。

以下是对该ppt的解读

真实环境下,性能问题的根源有以下几种:

1、数据库没有按照预期设计的目的被使用

2、应用的架构或代码设计不佳

3、数据库中存在一些不良的算法可能会引发问题

对于大部分人来说,都会讲优化的目标集中在一些小细节上,比如某一条SQL的性能比较差,shared pool的某一组件设置不合理等等。对于这些细节的调整,一般会带来小幅度的性能提升,而大部分人则满足于此。

RWP团队一直追求千倍以上极致的性能提升,对于他们来说,每一个性能问题,都应该找到根源,从最有效的角度解决问题,而不是满足于小幅度的性能提升。

在他们的工作当中,一般性能优化会涉及到以下几个方面的处理:

代码的改写,应用的逻辑修改,保证被正常地使用,bug的修复等。通过多个维度的调整和修改,最终实现系统性能千倍的提升。

发现数据库性能问题的方法很多,而不只是简单地看wait event 和 top SQL。事实上,我们需要的很多数据都可以从AWR报告中获取,同时,我们也需要了解系统架构的设计方式、实现原理。在我们的经验中,很多性能问题都是架构设计不合理或者应用代码的逻辑问题导致的。

接下来我们分享如何通过AWR的解读来定位问题,在AWR报告中应该关注哪些重要的信息,有效地利用报告中的数据,从而发挥AWR的真正价值。

首先看AWR报告的头部。要关注的部分如图中黄色标记所示。首先我们看到系统中有4个socket,总共32核,CPUs显示为64,应该是开了超线程。session值很高,在采样时间内还不断增长。

猜测:可能是会话泄露或者是连接风暴。

知识点补充

会话泄露:当应用程序断开连接而数据库中对应的会话还处于活动状态的时候,就会发生会话泄露。对于应用来说,就意味着程序的丢失。一般都是由于应用程序的异常导致的,在数据库中没有正常地执行commit或者rollback的时候失去了与数据库的联系。

在session本身很高的时候,每个session中的cursor值也从8增加到了26。这说明会话中游标耗尽,

猜测:可能存在游标泄露的问题。

再看详细负载信息

DBtime达到260,就意味着同一时间的活动会话数量达到260,DB CPUs大于系统CPU核数(32)。

Logons 为10.5,每秒有10+的会话登录,这个值是非常高的,在正常情况下,一般系统可能在1左右。这说明系统存在异常,再次推测可能是会话泄露或连接风暴等原因,与前面的信息相符。

60%的用户事务在做回滚。(图中写40%应该是误写,40%的事务是做提交)这也是不正常的。

接下来我们来看数据库的一些参数的设置。

我们看到数据库中块的大小是非默认块16k。同时将cursor_sharing设置为Force。

知识点补充

cursor_sharing 参数有 exact和Force两个选项,force 选项指的是优化器会将所有的文本值用系统生成的绑定变量替换,如果在使用绑定变量之后SQL语句一样的话,优化器就会使用同样的执行计划。

在一般情况下不建议将参数设置为Force。这很可能会引发SQL注入的风险,对于SQL中的函数来说,在一些直接使用文本而非绑定变量更优的情况下,如果使用系统生成的绑定变量,可能会对执行计划产生负面的影响。

因此系统一般建议设置为EXACT,只有在特殊情况下才设置为Force。详情请参考官网(http://docs.oracle.com/database/122/TGSQL/improving-rwp-cursor-sharing.htm#TGSQL-GUID-6C3AFFA0-21DD-41BC-8DEE-5FC9A58B0954)

DB_file_multiblock_read_count 默认值对应于可以高效执行且与平台相关的最大I / O大小 。此处与系统CPUs核数相等,说明IO没有问题。

open_cursors 参数指定一个会话一次最多可以打开的游标的数量,默认值为50.现在设置为2000,这是很高的,说明系统存在异常。

而从db_recovery_file_dest参数的设置是哪个,我们看到存储类型为ASM,ASM是支持异步IO的,在支持异步IO 的情况下,open_cursor达到2000也是不正常的。

DB_Writer_processes的默认值为1或者CPU_count/8,取较大者。此时设置为12,比默认值大,应该是手动调整过。

前面的信息判断,系统应该是2个节点的RAC,processes推荐值为 50*2+50=150. 此时达到5500,而sessions默认值为processes*1.5+22=8272,图中的值应该也是手动调整过。 而调整的原因,推测是8272也不够用。这是很不正常的。

接下来是等待事件的分析。看到系统大部分处于等待。

以下是对于具体的top SQL的分析描述。

因此,综合上述的信息,推测系统可能是出现会话泄露和游标泄露的问题。对于会话泄露,一般是由于应用的异常导致,不能直接通过数据库层面的分析得出结论也不能单纯从数据库的层面解决。

以上,针对一份具体的AWR报告,我们看到哪些问题是最需要我们关注的,是能够帮助我们最有效地分析出系统的问题所在的。希望对大家有借鉴意义。

原文发布于微信公众号 - 数据和云(OraNews)

原文发表时间:2017-10-13

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏技术翻译

Web应用程序开发指南

Web应用程序是与服务器端编程相结合的动态Web站点,它提供诸如与用户交互,连接到后端数据库以及向浏览器生成结果等功能。

842
来自专栏Web项目聚集地

你真的懂前后端分离吗?

最近这一段时间由于Nodejs的逐渐成熟和日趋稳定,越来越多的公司中的前端团队开始尝试使用Nodejs来练一下手,尝一尝鲜。

1163
来自专栏IT派

用 Python 实现每秒处理 120 万次 HTTP 请求

用 Python 做到每秒处理上百万次 HTTP 请求,可能吗?也许不能,但直到最近,这已成为现实。

943
来自专栏北京马哥教育

使用Heapster和Splunk监控Kubernetes运行性能

作者:naughty Kubernetes已经成为容器编排的事实上的王者,连Docker都已经向K8s女王大人低头。对于Kubernetes的cluster的...

3236
来自专栏北京马哥教育

从苦逼到牛逼,详解Linux运维工程师的打怪升级之路

做运维也快四年多了,就像游戏打怪升级,升级后知识体系和运维体系也相对变化挺大,学习了很多新的知识点。 运维工程师是从一个呆逼进化为苦逼再成长为牛逼的过程,前提在...

3774
来自专栏杨建荣的学习笔记

平台设计中的脚本管理

前期揉入了一些功能,因为主要是面向基础功能,所以进度略慢,如果要想一下子有种井喷的效果,那就是脚本化和流程化大显身手的时候了。 如果尽可能减少开发和业务同学之间...

3234
来自专栏杨建荣的学习笔记

初识JMeter

今天在地铁上,一直在琢磨高可用测试的一些补充场景,除了功能之外,就是一些异常场景的考虑,总之,能想到可能发生的任何场景,然后和实际应用场景结合起来,给出...

3889
来自专栏情醉中国风

基于云安全环境的最佳实践

无论您是打算使用托管服务来处理你们组织的云安全,还是决定创建管理自己的安全项目,至少,将所需的所有信息汇总起来就可能是一项复杂的任务了。为了解决这个问题,我们想...

1939
来自专栏数据和云

DBA生存警示:系统存储级误删除案例及防范建议

编辑手记:对于资深的老DBA们,他们在漫长的职业生涯中养成了很多稀奇古怪的守则,以在复杂多变的环境中“幸存”,这源于无数血泪的教训,我曾经在《数据安全警示录》一...

32010
来自专栏微服务生态

Kafka之Consumer获取消费数据全过程图解

这篇文章是作为:跟我学Kafka源码之Consumer分析 的补充材料,看过我们之前源码分析的同学可能知道。 本文将从客户端程序如何调用Consumer获取到...

552

扫描关注云+社区