如何用“新云监控”进行DB2性能监控和调优

前言

   

和很多从业多年的DB2 DBA聊天，都说到DB2绝对是个好产品，无论功能和性能在数据库领域都是数一数二的，但是要用好不容易，甚至可以说很难。理由无外乎就是没有一个好的工具，基本都是凭借DBA的经验，通过命令和脚本来运维以及调优DB2。在外人看来，吧嗒吧嗒敲着谁也看不懂的命令行似乎很酷，确实是大牛的风范。其实广大DB2 DBA内心苦楚，内牛满面，我们是因为实在没有一个易用的工具啊···，也渴望鼠标点吧点吧就把活干了，一些初级的DBA遇到棘手问题时候，甚至会有无从下手的感觉。在这里，我们推荐用一款专业的DB2监控调优工具“新云监控”，借此工具能真正地提升DB2运维和调优品质和效率，是DBA在学习、使用、监控和调优DB2 LUW数据库性能的利器！

   

首先来看看新云监控的前世今生，新云监控是新数科技开发的一款图形化的专业DB2监控工具，新数科技核心团队是由一批原IBM DB2开发实验室的专家出来创业而组建，在DB2领域有很深的耕耘。新云监控顾名思义，监控肯定是其基础功能，其不仅可以实时动态监控DB2状态和性能，而且其还会记录DB2所有的历史信息，非常有助于分析系统性能变化轨迹。新云监控还是性能调优的利器，此文我们就是要看看，如何用新云监控来进行DB2的性能监控和调优。

   

一、新云监控下载安装

   

新云监控安装非常简单方便，支持window和Linux平台，一键安装。详细的安装和数据库配置方法可以参考安装包里面的文档《新云监控的安装与使用》。

   

下载地址：http://www.newdt.cn/list-31.html

   

   

二、用新云监控进行DB2性能监控

   

DB2的性能指标相当的多，如何从DB2出繁杂的性能指标点中，清晰提炼出了DB2数据库性能监控的几个最重要的点就成为了监控的关键因素。

   

在此，我们一起来看看新云监控在性能这一块都监控了哪些关键点。

   

1. DB2整体性能监控和告警机制

   

一个DBA首先要确保的是数据库在整体层面稳定运行，没有明显瓶颈，才能有效为上层应用提供服务。在新云监控中，有一个总览可以总体来判断系统的实时瓶颈。

   

1.1 所有数据库性能总览及其主动告警机制

   

我们DBA在运维的时候，往往需要监控好几个，甚至几十个个数据库，新云监控为此专门提供了一个仪表盘进行总览和主动告警功能，提炼出了DB2中的关键指标进行实时监控。当这些指标超出经验阈值时候，新云监控会自动进行告警，甚至发送邮件告警。

   

   

   

当然，我们也可以对告警阈值根据系统实际情况进行调整。

   

配置à数据库配置à监控项

   

   

下面是新云监控中对上述6个指标告警的阈值的预设值：

   

   

   

1.2 单个DB2数据库性能总览

   

数据库à性能à总览

   

   

从上图我们已经可以很轻松地监控DB2的总体性能变化以及分析主要瓶颈，在这里有6个每5秒自动刷新的颜色块，分别是CPU使用率、内存使用率、物理读平均水平、缓冲区命中率、锁等待和排序溢出率。这6个指标在DB2可以说是最关键的指标，如果这6个指标没有超出告警阀值，基本就可以判断DB2没有大的瓶颈。

   

1.3 DB2总体性能实时+历史分析

   

当然我们还可以通过“主机”这一栏，来更详细分析系统资源的实时和历史水平。在此，我们以CPU使用率为例，其分为实时CPU利用率和平均CPU利用率的概念。实时CPU利用率是指，是判断系统当前繁忙程度的一个重要指标；平均CPU利用率是指CPU的在数据库总体或者某个时间段的平均利用率，从而整体来判断判断我们这个数据库是否有CPU瓶颈。我们往往需要考虑的是闲时平均利用率和忙时平均利用率。

   

   

过去一天的CPU利用率， 我们可以轻松观察到不同时段的系统负载。当然我们还可以去观察一个月，甚至自定义时间段来观察。

   

历史数据对我们性能监控来说是非常有意义的，我们突然发现系统的性能急剧下降，我们就可以通过观察历史的变化，报告CPU、IO、缓冲区、锁等待这些信息的变化，来快捷分析性能下降的原因，非常有助于我们有针对性的去调优。

   

   

2. Top SQL分析和调优

   

一说到性能，大家首先想到的SQL的运行时间，这是性能最直观也是最重要的体现。如何来获取这个SQL的平均时间呢？找到耗时最长的SQL后，又该如何操作呢？

   

在新云监控中有一个项，专门就是Top Sql，轻松一点就列出来了：

   

   

现在拿到这个SQL了，我们一般需要来分析其读取的行，锁等一些情况，点击左侧的SQL ID，我们就可以轻松看到这个SQL读取的数据量级、CPU和锁的情况。

   

右下角的饼状图，非常直观的展现了SQL在执行时间上的开销占比，帮助我们迅速判断调优着手点。

   

   

点击右侧“SQL历史分析”，我们可以惊喜发现，新云监控帮助我们智能分析了这个SQL的开销关键指标值，红色就是需要我们重点关注的啦。后面还给出了相对应的调优指示，而且还详细记录了这个SQL历史执行时间，真堪称调优神器。

   

   

在这里我们需要注意上图中一个重要概念“有效读比率”，有效读比例是反映表有没有合理索引的重要指标，因此也可以称其为索引效率。有效读比例低说明索引或查询计划不合理，有效读比例低于10%时需关注，低于1%需严重关注。可以通过增加索引或检查查询计划来优化。另外，我们还可以从应用层及来观察有效读比率。

   

   

   

再接下来，点击查询计划，仔细分析其DB2查询优化器，观察其cost，有针对性地来优化SQL。

   

   

   

通过新云监控的这个步骤，就可以轻松来监控和调优耗时最长的SQL的平均执行时间。

   

如果想了解更多的SQL监控和调优，可以参考《通过新云监控工具监控并优化DB2数据库中的SQL语句》

   

3.  DB2性能开销分析

   

新云监控对数据库总时间消耗进行了分类展示，如下图中我们看到，总等待时间过长，达到了26.5%。我们需要对其进行分析，都是发生了什么等待。在数据库等待时间分布图中，清晰展示了每一类等待的花销: IO等待、锁等待等等。在这个图表中，我们可以看到其主要时间消耗在等待上，显然有问题。进一步去分析等待时间分布，会发现其主要是发生了锁等待。

   

   

   

4. 锁等待、锁超时和死锁分析

   

在上图中，我们看到，数据库主要时间开销在说等待上，那么如何去分析锁等待呢？

   

在实际系统运维中，锁等待、锁超时和死锁总是经常会遇到，而且很头疼。前台应用反应系统慢，然后DBA开始赶紧查，发现锁等待严重，有赶紧看，是哪个应用被锁，分析能不能杀掉，每次都弄得紧张无比。如果是锁超时和死锁，还更麻烦，只看到曾经发生过几次死锁，也不知道谁和谁发生了死锁，向来头疼无比。

   

新云监控通过自动告警机制，一旦锁等待严重，紧急提醒DBA处理锁问题，并详细列出锁等发生的应用情况，提前预防。

   

   

   

新云监控还会自动抓取锁超时和死锁信息，直观列出其发生时的详细情况，可以让开发人员很明确地去调整代码，防止再次发生。

   

更多关于锁等待、锁超时和死锁的更多信息请参考《通过新云监控分析DB2锁等待、死锁和锁超时》

   

   

   

5. DB2内存信息分析

   

DB2在内存管理拥有非常优秀的STMM功能，一般情况下，足以应付正常负载。但是在一些高负载或者应用异常的情况下，STMM可能会导致某一部分内存发生急剧变化，进而影响系统性能。新云监控实时展现了DB2中每一总内存类型的使用大小和占比，还可以通过点击内存列表里面左侧内存类型名，分析每一种类型的内存变化历史，从而帮助我们分析问题发生的过程和原因。

   

   

   

说到内存，我们肯定都非常关注内存中最大占比的缓冲区，以及其命中率。新云监控，同样直观展现了每个缓冲区的实时和历史命中率，并对其主动监控和告警。

   

   

6. 平均I/O响应时间。

   

根据大多数客户经验，I/O响应时间往往会成为我们系统的瓶颈，需要我们重点关注。其中最重要的一个指标是：平均物理读时间，一般我们要求其小于5ms，当超过10ms时，会导致系统性能指数级下降。

   

   

   

三、总结

   

DBA始终是一个需要大量经验积累的工作，因为运维和调优涉及系统的很多方面，需要DBA拥有丰富的IT知识和经验积累。新云监控通过关键指标的提炼、主动告警机制、图形化的展示方式可以很大程度地提高运维和调优的效率，这是一个比较初略的入门文档，更多的深入功能期待大家去深入挖掘，同时也可以参考上文提到的两篇调优文章。