杨建旭
作者杨建旭2017-09-30 15:45
技术经理, 中国人民银行清算总中心

性能测试关注的Oracle指标

字数 4622阅读 4604评论 2赞 7

数据库的性能优化是个非常复杂的事情,熟悉Oracle的专家能手更是数不胜数,让哥仰视。所以写了50篇的帖子都没敢写过Oracle。直到最近,单位请来了Oracle原厂培训(叫Oracle大学),请Oracle大师来给新入职的同学做培训,哥呢,作为一个张罗这事的参与者之一,也跟着听了一天。听了一天竟然发现大师有几个地方讲错了,主要是在理论联系实际的问题分析、AWR报告解读方面,提问之后竟然把大师挂在了台上。后来想了想,大师也有不懂的,我怕什么呢,写!从性能测试的角度看Oracle,我们换个视角。

一个业务的响应时间受到这个业务所以环节性能的影响,如果被测系统涉及到数据库,则需要对数据库指标进行监控。这里的数据库指标并不是服务器本身的CPU、内存、IO等指标(当然,这些指标也是要监控的),而是指从数据库角度来看的指标,例如Buffer命中率、SQL执行时间等,这一章介绍Oracle数据库的指标。

数据库的指标千千万,一般来说,会重点关注一些指标,这里就介绍一下作为测试人员需要关注的指标。

关注指标之前,需要做的是关注Oracle系统的告警(例如:表空间满了)。只有告警消除后,各类指标才是正常状态下的指标。

查看Oracle性能指标的方法有不少,本文主要以AWR报告为目标做介绍。自动工作量存储(Automatic Workload Repository AWR)是随着数据库一起被安装的,它不仅能收集统计数据,还能从统计数据中分析出度量数据,后续会详细介绍AWR,本节主要介绍指标本身的概念。

SQL语句执行时间、吞吐量

数据库的用户是应用,应用使用数据库来执行SQL语句。SQL语句的执行时间最能反映满意用户需要的能力。当一个应用处理速度比较慢的时候,自然会查看数据库的SQL执行时间。

一个数据库有千千万个指标,其他指标即使异常到令人发指,只要用户满意,往往也没有人去刻意做调优。
执行时间:
在AWR>Main Report>SQL Statistics目录下,可以看到如下SQL语句执行时间的分目录。

1.png

1.png

如果应用程序比较慢,并且比较怀疑是数据库的原因,那么关注一下排在前几位的SQL语句。作为初次观察,关注SQL ordered by Elapsed Time,这个指标是按照整个SQL的执行时间来排序的,以下图为例:

这里有SQL语句的名称、执行次数(Executions)和每次的执行时间(Elapsed Time per Exec(s))。如果这个执行时间比预想的要长,那么需要查看一下这个语句的执行计划。

吞吐量:
执行次数除以总时间(两个AWR快照之间的时间)就是这条SQL的吞吐量,吞吐量同样是比较重要的指标。SQL吞吐量无法根据业务压力而增长说明单条SQL的执行效率有问题或者系统的并发有问题(应用、中间件、数据库等环节均可能有并发的问题)

另外,%Total、%CPU、%IO这些指标一定要注意这个分目录的具体解释,因为每个分目录下的解释不一定一样,并且,这些指标可能和你大脑中想象的含义也不一样。

%Total:在“SQL ordered by Elapsed Time”这个分目录下,含义是:这条SQL的执行时间(Elapsed Time)占总DB Time(所有SQL语句执行的时间之和)的百分比。而在“SQL ordered by CPU Time”这个分目录下,含义是:CPU Time占总DB Time的百分比。

%CPU:这条SQL的CPU Time除以Elapsed Time。表示执行时间里面有多少是花在CPU上的,没花在CPU上自然就是花在等待上,等待IO或者等待其他资源。

%IO:这条SQL的User I/O Time除以Elapsed Time

我看了解释以后发现和我的第一想象是不一样的。在看指标的时候,千万不要根据自己的猜测、经验来看,一定要查阅各个系统、各个产品自身对该指标的定义。

这里再多说几句,我们个人会对Oracle的一些指标有误解,那么Oracle作为一个产品也会对其他产品有误解。例如,AWR报告的开头部分:

2.png

2.png

这一段是Oracle对自身所处的系统环境信息做一个抓取,系统共18个核,72个逻辑CPU,但这个系统不一定有18个核的能力,还得具体查看环境是不是虚拟化平台,如果是,那么这18个核是虚拟的核,而真正能得到的CPU能力可能小于18。

Top等待

如果觉得数据库有性能问题,那么最先查看的就是Top等待事件。

3.png

3.png

看看哪个事件的Total Wait Time最大,就重点解决哪个事件。DB CPU如果最大一般是正常的,需继续关注DB CPU之外的事件。

等待事件五花八门,遇到没见过的可以网上查查,但看懂网上查来的结果也是需要些数据库的知识了,此处不是一朝一夕的花架子。

举一个性能测试中常见的例子,测试环境或者是刚刚搭建的生产环境常常是Oracle的默认参数,没有经过调整,log switch占到了Top等待事件的前面。

日志切换(Log switch)为什么等待时间这么多呢?首先就要了解日志、日志组是干什么,日志为什么要切换,什么情况下切不过去。

Redo日志组假如初始是2个日志,每个日志10M大小,分别记为A和B。当A写满的时候,就要switch到B去写日志,这时候就发生了日志切换。此时,可能1)如果开启了日志归档,需要将A写到归档日志里面。如果B这时候也写满了,就要再次switch回A。如果A还没有归档完成,那么就需要切换等待。可能2)A里面的内容还没有完成提交,B也不能把A的日志冲掉,此时产生了切换等待。

了解清楚之后,在不改变应用程序的情况下,可以通过增加单个日志大小(减少切换次数)、增加日志组个数(减少切换时可能的等待)来解决。比如日志大小从10M改为1G,日志从2个改为4个。

Instance Efficiency Percentages

这个分类下面大部分是Buffer命中率。命中率在数据库中是至关重要的,命中率的高低直接影响了数据库的性能。
介绍几个经常关注的指标
4.png

4.png

Buffer Nowait >99
在缓冲区中获取buffer 的未等待比率, 一旦此数据较低说明数据库存在大量出现buffer busy waits。

Buffer Hit >95
数据块在数据缓冲区中的命中率,通常应该在95%以上,否则考虑加大db_cache_size。当然,命中率低也不一定是cache小,也可能SQL写的烂、执行计划不当等原因。

Library Hit >95
代表着SQL在共享区的命中率,通常在95%以上。
当你发出一条SQL语句交付Oracle,在执行和获取结果前,Oracle对此SQL将进行几个步骤的处理过程,语法检查、语义检查、对sql语句进行解析、执行SQL返回结果。其中SQL解析的过程生成解析树(parse tree)及执行计划(execution plan)。这个过程是非常消耗CPU资源的,因此Oracle将解析好的SQL语句(或者说是执行计划)放在library cache中等待复用。
较低的库缓冲区的命中率意味着SQL语句被过早的推出了缓冲区(又要再次硬解析),加大共享池。

Redo Nowait >99
写日志的不等待比率,太低可能是log_buffer偏小,或者log_buffer向磁盘刷日志的参数 _log_io_size(默认为1/3*log_buffer/log_block_size,设置_log_io_size 为合适的值,比如适当减小),或者存放日志的磁盘性能不好(比如RAID划分不当,RAID5或6改为RAID10),或者日志组个数偏少、每个redo log大小偏小,导致log buffer的数据不能及时进入磁盘。

In Memory Sort >95
值过低表明很多排序都在TEMP表(磁盘)中进行,需要检查是否有效率过低的SQL,分析sort_area_size是否太小。也有可能是SQL太烂,需要优化SQL,技术上优化不了了就改为优化业务流程。

Soft Parse >95
能够复用现有执行计划就是软解析,不能复用就要重新硬解析。
近似当作SQL在共享区的命中率,通常高,代表使用了绑定变量, 如果低于80%意味着大量硬解析,SQL没有被有效的重用,需要调整应用使用绑定变量,或者设置cursor sharing参数。

内存使用情况

数据库的内存大小对性能的影响往往比CPU的多少还要重要。

因此需要关注操作系统分给Oracle多少内存(memory target),以及Oracle内部各个内存区域的使用情况。
尽管Oracle11g之后内存默认是自动管理的,但我们了解内存自动变化的情况,对性能分析也有帮助,另外有些用户还是习惯用采用手工方式进行内存区域的划分,划分的是否合理,也可以从内存使用的情况来检查。

memory_target:操作系统分给Oracle多少内存,可以从v$parameter中查到:
select name,value,display_value from v$parameter;
sga_target:SGA区域的大小,如果=0,则系统自动分配。
pga_aggregate_target:PGA区域大小,如果=0,则系统自动分配。
其他内存参数如db_cache_size、shared_pool_size也类似。

假如内存采用了默认的自动管理方式,我们关注的不仅仅是大小,还有在测试过程中的变化趋势。所有的项目都有Begin时的大小和End时的大小,关注其变化趋势。

6.png

6.png

7.png

7.png

如果某个区域有明显变大的趋势,说明对这个区域的需求量比较大,而初始的值比较小,Oracle在运行过程中慢慢的调整它。

但Oracle的调整并不是实时的,也不一定能把各个内存区域的配比调到性能最优状态(况且还会有Oracle自身的bug)。

本人有一次测试,数据库性能非常差,测了好几次都没有好转。测试环境为一个Oracle RAC,每台实例分给Oracle 8G内存,测试过程中并没有发现哪个内存区域有逐渐增长的趋势,但发现DB1的Buffer Cache是320M,DB2的Buffer Cache是864M,而大部分业务跑在DB1上。果断手工修改(其实耗了我周六周日2天时间琢磨AWR)DB1和DB2的Buffer Cache=2G。整个场景的响应时间从20分钟变为了3分钟。这个例子说明,自动管理内存不一定能达到性能最优,但有时可以借助它来分析问题。

内存advisory
内存的advisory也是值得一看的。可以从中看看目前的内存够不够用。毕竟一个项目上线之前,谁都不知道它会吃多少内存,或者吃某个区域多少内存,测试环境可能内存还是打折的,遇到性能缓慢是不是由内存不足引起的呢?

关注Main Report>Advisory Statistics,可以看到好多区域的advisory

8.png

8.png

以SGA为例

9.png

9.png

可以看到SGA设置为多少M的情况下,对应的DB Time是多少,物理读是多少。由此可以初步判断当前的内存设置是不是合理。

搜索微信号关注“性能测试与调优”

如果觉得我的文章对您有用,请点赞。您的支持将鼓励我继续创作!

7

添加新评论2 条评论

#跃马江湖商业智能工程师, 银行
2019-08-25 08:25
拜读了。
#wangmj系统运维工程师, CES
2017-10-01 08:58
感谢分享!
Ctrl+Enter 发表

本文隶属于专栏

关于TWT  使用指南  社区专家合作  厂商入驻社区  企业招聘  投诉建议  版权与免责声明  联系我们
© 2019  talkwithtrend — talk with trend,talk with technologist 京ICP备09031017号-30