简介： 确保数据库健康运行对于数据库管理员来说是一项重要且具有挑战性的工作。本文将介绍如何使用 IBM Optim Performance Manager(OPM) 来帮助数据库管理员监控DB2数据库和之上的应用，确保它们健康运行。在文中，首先介绍 DB2 应用健康运行的关键因素及通用问题解决步骤，然后介绍 OPM 的适用领域及使用方式，最后以一个实战案例来直观地演示 OPM 的强大功能。

概述

当今时代，很多企业的关键业务依赖于部署的企业应用，而企业应用的性能好坏，甚至决定了企业的成功。如何保证企业应用的健康和性能是数据库管理员一项非常重要又具有挑战性的工作。特别是基于 DB2 数据库的应用，在中国应用很广泛，但相关的专业性人才更少，使得企业的调优成本大幅提高。IBM 最新发布了 Optim Performance Manager v4.1（简称 OPM）就是为了简化调优工作，降低企业运营成本的。通过 OPM，数据库管理员可以轻松的监控整个企业的应用 , 确保应用健康运行。

本文将首先介绍健康 DB2 应用所必须具备的要素以及通用性能问题解决的步骤，然后介绍 OPM 的适用领域，以及 OPM 的使用方式，最后给出一个实战案例来直观地演示 OPM 的强大功能。

目前常见的 DB2 应用架构如图 1 所示。DB2 应用的健康运行依赖于构建这些组件的健康运行，包括客户端，应用程序，应用程序服务器，数据库服务器和网络。

影响 DB2 应用性能的最关键因素是设计，然后才是运行。良好的设计是健康运行的基础。在良好设计的基础上，来看如何保持 DB2 应用健康运行才变的有意义。由木桶效应原理，以上每个组件都不能成为 DB2 应用的瓶颈，我们要确保 DB2 应用的整个工作负载处于一种平衡状态。

设计不在本文的讨论范围，本文要讨论的是 DB2 应用运行阶段的调优。应用运行一段时间，会出现各种问题，这个时候，用户首先要保持良好的心态和端正的态度，不要惊慌急于解决问题。

一般情况下，用户可以按照以下几个步骤解决问题：

1. 收集数据，明确问题症状

明确问题症状，是用户第一步要做的事情。常见的问题包括：系统宕机，系统不稳定，系统变慢，某些业务无法进行等。

2. 思考问题来源

当问题出现的时候，用户需要首先考虑以下几种常见的情况，来分析问题来源：

• 硬件配置改变了？
• 应用程序服务器或数据库服务器配置参数改变了？
• 用户数增加了？
• 数据量变大了？
• 又有新的应用程序部署到了本应用所在的服务器集群？
• 不小心启动了其他不相关的程序或进程？

3. 观察和定位

找到问题根源是一个复杂的过程。一般情况下，需要多次尝试。在每次尝试之前，我们都建议做一个基准，来比较前后结果。另外一个建议是：每次尝试都应控制在一定范围内， 一次更改一个参数或做一次调整。

4. 解决问题

解决方法有很多种，一定要找最适合的。有的时候仅仅需要改变系统的一个参数就行，或者导出很久不使用的历史数据；而另外一些时候，则需要购买新的硬件来支持增加的用户数量和增的的数据。

OPM 主要用来解决 DB2 应用运行阶段健康问题的。OPM 支持的监控领域包括除了客户端外的组成 DB2 应用的大部分层次，如应用程序服务器，DB2 数据库服务器及网络等。

OPM 能够监控到应用程序花费在应用程序服务器，网络以及 DB2 数据库服务器上的时间以及其他相关的信息，比如，应用程序所在的主机，连接时间，操作系统，数据库驱动程序名称及版本，Websphere 连接池大小及使用情况，发送到数据库服务器的 SQL 语句等。OPM 支持的应用程序包括构建在 WebSphere 上的应用，构建在 JDBC 上的应用，构建在 CLI 上的应用，以及 Cognos, SAP，DataStage，InfoSphere Warehouse 等专属应用

OPM 的另外一个强项还在于能够监控到数据库服务器内部的各种信息。比如内存，I/O，活动 SQL，锁定，日志，实用程序等。

此外，OPM 支持和 IBM Tivoli 监控软件集成，从而从更宏观领域监控企业应用。

使用 OPM 监控 DB2 应用的健康，一般有三种方式：问题驱动，在线分析，趋势预测。

1. 问题驱动

问题驱动，是当问题发生时，使用 OPM 来解决问题的一种方式。如图 2 所示，当问题发生时，一般用户会收到一封电邮。邮件里会指明什么时间发生了什么问题。然后用户根据该邮件再登录到 OPM 来发现和解决问题。

2. 在线分析

在线分析是指用户主动地使用 OPM 分析 DB2 应用及 DB2 数据库服务器的相关指标，来检查是否存在健康或性能问题。这可以通过查看运行情况摘要仪表板来实现。如图 3 所示，此仪表板将显示所有被监控应用和数据库的宏观信息。用户可以在此直观的发现问题，并展开到其他仪表板进行更详细的分析。

3. 趋势预测

对于长期健康运行的应用，数据库管理员应进行趋势分析，预测未来可出现的问题，将问题在发生之前解决。OPM 提供了数量众多的仪表板，每个仪表板集中展现应用程序或数据库的某一方面的信息。数据库管理员可以通过这些仪表板，对于一些随着时间变动的指标进行定期检测和趋势预测。最典型的例子如确保磁盘空间满之前，扩充新的磁盘。

下面我们将以具体案例来演示 OPM 提供的功能。

我们用来做示例的应用程序叫 DayTrader。DayTrader 是一个模拟在线股票交易的基准程序，可以用它来评估应用程序服务器的性能。Daytrader 由 IBM 开发，并于 2005 年捐给了 Apache Geronimo 开源组织。Daytrader 提供的功能包括：登录，查看资产，查询股票报价，买卖股票等。

在 DayTrader 配置界面，设置最多用户数为 2000 和最大报价数量为 200000，并保存设置。然后使 DayTrader 自动生成测试数据，并把 Daytrader 应用和数据库服务器加到 OPM 的监控中。最后使用 Rational Performance Tester 或者 Apache Jmeter 模拟 5 个用户访问 DayTrader 应用大约 20 分钟。

通知

当应用程序运行一小段时间后，设定的邮箱内会收到几封邮件。如图 4 所示。

邮件中所通知的警报信息包括缓冲池命中率过低，失败的事务数过高，当前等待的应用程序数过多等。

警报

打开 OPM 界面，根据邮件内容中提到的数据库连接和警报内容，在警报仪表板中找到它们，如图 5 所示。

单击失败的事务数警报，列表下面会列出该警报的详细信息，包括发生时间，结束时间等。由图 5 左下角失败的事务数趋势图，可以看到失败的事务数是随着时间上升的。

在警报仪表板，单击警报详细信息下面的工作负载仪表板链接，我们开始分析问题。

工作负载

工作负载仪表板包括四大块。如图 6 所显示的是排序相关的信息。从中我们可以看到排序数和每个事务的排序数都随着时间逐步上升。

如图 7 所显示的是吞吐量的相关信息。从中我们可以看到事务吞吐量和语句吞吐量随着时间逐步上升，并且每个访存行读取的行数平均达 8000 行每次。

接着看图 8，从中我们可以看出，从应用程序刚一运行，排序堆相关溢出就非常高，大约 40%。系统分配的排序内存也是逐步增加，从 0 至 900。

由于排序溢出比较严重，我们由其下面的内存仪表板链接到内存仪表板查看相关内存信息。

内存

在内存仪表板数据库全局内存视图，我们注意到缓冲池和程序包高速缓冲都被标为红色，如图 9 所示。这表明这两块内存区域的命中率都低于预期。鉴于在工作负载仪表板所看到的每个访存行读取的行数高达 8000 行，我们决定由缓冲池内存旁边的缓冲池和 I/O仪表板链接到缓冲池和 I/O 仪表板看一下。

缓冲池和 I/O

缓冲池和 I/O 仪表板可以显示关于缓冲池，表空间和表的相关信息。如图 10 所示默认显示的是缓冲池的相关信息。

在图 10 中，我们可以看到缓冲池命中用率低于预期 95%，仅为 74%。逻辑读取数和物理读取数值都比较大，分别是 55302 和 13914。这表明系统有频繁的 I/O 操作。在图 10 显示的下方区域，如图 11 所示，我们可以看到缓冲池大小，缓冲池命中率等相关信息。图中显示缓冲池大小是逐步上升但是利用率是逐步降低的，这表明系统需要从磁盘载入大量数据到内存，但是当前预分配给缓冲池的内存不够，导致命中率较低，于是系统自动主动的增加缓冲池大小。另外图中显示逻辑 I/O活动和物理 I/O活动都在随时间逐步增加。

选中图 10 中的热点缓冲池 IBMDEFAULTBP，单击显示所包含的对象按钮将会切换到表空间视图，如图 12 所示，和 IBMDEFAULTBP 关联的有 5 个表空间，其中热点表空间为 USERSPACE1 和 TEMPSPACE1。表空间 USERSPACE1 命中率为 81%。另外的数据表明大量的 I/O 操作发生在 USERSPACE1 表空间上，其中逻辑读取数高达 24130/ 分钟，而物理读取数高达 4442/ 分钟。与其对应的 TEMPSPACE1 具有非常类似的 I/O 信息。在前面查看工作负载仪表板的时候，我们知道系统的排序溢出率非常高，而 DB2 系统中排序溢出后，就会使用临时表空间存放数据，由此我们得到结论：TEMPSPACE1 就是排序溢出后所使用的临时表空间。

由图 12，选中 USERSPACE1，单击显示所包含的对象按钮将会切换到表视图。如图 13 所示的是创建在表空间 USERSPACE1 上的所有表。图中数据显示 QUOTEEJB 和 HOLDINGEJG 两个表都是热点表。大部分 I/O 操作都集中这两个表上面。

至此我们可以猜想，应用程序中可能有不恰当的 SQL 语句。该 SQL 语句访问这两个表，而该访问需要大量 I/O 操作，从而带来性能问题。所以，让我们到活动 SQL 仪表板查看一下是否存在这样的 SQL 语句。

活动 SQL

由 OPM 任务管理器菜单打开活动 SQL仪表板，如图 14 所示。图中，我们按耗用时间对 SQL 语句排序。图中所显示第一条 SQL 语句就是耗用时间最长的 SQL 语句。选中那个它，它的详细信息如图 15 所示。

点击 SQL 语句右下角的全部按钮，将显示该 SQL 的完整语句，如图 16 所示。

图 16 中，该 SQL 语句引用到上文我们定位到存在 I/O 问题的热点表 HOLDINGEJB 和 QUOTEEJB。所以，我们应该找到了问题所在：此 SQL 语句执行过程中需要 DB2 进行大量排序，从而引起大量 I/O 开销，再而导致系统性能下降，失败事务数上升。

OQT

OQT 即 IBM Optim Query Tuner。在活动 SQL 或者端到端仪表板，点击在 SQL 语句右下角的调整按钮，如果用户浏览器所在本机安装了 OQT，并且 OQT 已经启动的情况下，OPM 会将该 SQL 语句传递到 OQT 进行调整。

在 OQT 中，我们首先查看该 SQL 语句的访问计划。如图 17 所示，该 SQL 语句采用表扫描来访问表 QUOTEEJB 和 HOLDINGEJB，而不是采用索引扫描。而在 DayTrader 数据库中 QUOTEEJB 表拥有 200000 条记录，遍历这么多记录来找到少数记录势必带来很严重的 I/O 问题。

OQT

OQ 会根据问题给出一些建议，在本示例中，我们在 OQT 中采纳并应用 OQT 的建议，然后再次查看该 SQL 语句的访问计划，如图 18 所示，新的访问计划已经没有了表扫描，对表 QUOTEEJB 和 HOLDINGEJG 都变成了索引扫描。

运行负载

重新运行负载大约 20 分钟，然后我们到各个仪表板查看问题解决后的各种指标。

活动 SQL

活动 SQL 仪表板仅仅显示耗时比较长的 SQL。在该仪表板，如图 19 所示，我们已经看不到任何 SQL, 这意味着所有的 SQL 语句均能够在很短时间内完成。

缓冲池和 I/O

然后到缓冲池和 I/O 仪表板，在问题解决前中，缓冲池 IBMDEFAULTBP 的物理读取数高达 13914/ 分。而如图 20 所示，新的数值只有 2。这表明直接的磁盘操作已经大大降低。

然后查看缓冲池和 I/O 仪表板右下角的折线图，在图 21 中，缓冲池大小和缓冲池命中率均非常稳定，其中缓冲池命中率大约维持在 100% 左右，该值表明缓冲池命中率非常好。在逻辑与物流 I/O活动对比图中，我们可以看到逻辑 I/O 和物理 I/O 对比非常明显，逻辑 I/O 要远远大于物理 I/O，这表明系统已经在使用快速的内存来访问经常使用的数据，并且系统从磁盘调入缓冲池的算法运行的非常良好。

内存

再到内存仪表板，如图 22 所示，我们也看不到异常的缓冲池内存使用信息。

工作负载

由内存仪表板再切换到工作负载仪表板。在图 23 的排序视图，我们可以看到，整个应用程序的排序数非常小，维持在 6 左右，每个事务的排序数也非常低，几乎为 0。这表明系统已经采用索引扫描代替了原来的表扫描加排序。

关于吞吐量，在图 24 与上文的对比中，我们也可以发现应用程序事务吞吐量和语句吞吐量大大增加，而形成鲜明对比的是每个访存行读取的行数则显著下降。

关于排序溢出，如图 25 所示，排序堆相关溢出为 0，则再次证明了应用程序改用索引扫描代替了原来的全表扫描加排序。

本案例我们使用了 OPM 大部分仪表板来分析和定位问题，用户可以更近距离的体验 OPM 提供的功能。当然本案例只是为了演示 OPM 功能，所以带领用户走了很多仪表板，从不同视图展示同一个问题所带来的影响。而在实际产品环境中，并不需要使用那么多仪表板，用户可以直接由 1 到 2 个仪表板快速定位和发现问题。

通过案例我们还总结出一个经验：当应用程序刚部署后，一定要先热身，并更新访问计划后再正式上线，这样能够避免掉初期的性能问题。

数据库 OPM 提供了丰富的仪表板，帮助用户监控数据库应用的健康状况，从而及时发现和定位问题。根据 OPM 及时展示的信息和保存下来的历史数据，用户也可以进行趋势分析，从而预防未来将要发生的问题，保证应用的持久健康运行。

原文链接：http://www.ibm.com/developerworks/cn/data/library/techarticles/dm-1008zhanggm/index.html