DB2性能优化（2）：解决性能问题的四步骤

对一个方法系统来说，首先要考虑的就是策略问题。我们在性能优化实践中总结的优化策略共分为四步：

l  第一步，问题监控

l  第二步，配置检查

l  第三步，设计检查

l  第四步，性能优化

这样一来解决所有数据库性能问题的步骤都得到了统一，即按照上述顺序检查，各个问题的区别只是检查的结果有所不同。例如有些问题在第二步就查出问题了，有些没有而是在第三步查出问题，但最终都是通过第四步完成优化的。

另外，我们在为金融电信行业客户讲解PAT优化策略时，同时提出了下述四项指导原则，取得了非常好的实践效果。这四项指导原则是对上述优化策略的有益补充：

1.         数据库性能问题监控针对性原则

       在定位应用或系统瓶颈时，需要对数据库进行监控，要针对业务分析和系统分析后的性能问题进行针对性的监控，这是提高优化速度的关键所在。在本书的第7章有数据库监控的详细介绍。

       通常DBA安装好DB2数据库后，DB2可以自动检测资源并做相应配置。但是    我们还是必须弄清楚系统运行情况，弄清楚DB2对资源的使用情况，例如内存使用情     况，CPU占用情况，I/O吞吐量以及网络吞吐等。换句话说，对DB2数据库进行有效   监控，当系统变慢或出现资源瓶颈后能快速找到线索并定位，是确保数据库系统稳       定、可控运行的必要条件。那么如何去监控DB2数据库所在平台？如何监控DB2？  这可以利用操作系统和DB2本身提供的一些工具来实现。下面就从几个方面来阐述。

l  系统监控

       DB2服务器支持在多平台运行, 通常情况下，很多系统具有类似的架构，所以所使用的工具在不同的平台上可能略有不同，但本质原理是一致的。例如使用vmstat工具对磁盘、内存、CPU监控；使用iostat工具对I/O、内存监控等。一些常见的系统监控工具见下表所示。

工具	平台	监控内容
Iostat	Unix、Linux	磁盘
Vmstat/sar	Unix、Linux	CPU、内存、磁盘
Perfmon	Windows	CPU、内存、磁盘
Nmon	Aix	CPU、内存、磁盘
Netstat	Unix、Linux	网络
Top	Linux	CPU、内存

 

l  快照监控（snapshot monitoring）

       你可以使用快照监控工具捕获数据库、已连接上的应用在任何指定时间的信息。通常快照用来诊断数据库系统的状态，有助于观察运行趋势以及预见潜在问题。快照数据可以通过下面的方式获得。

1）get snapshot命令：格式化文本输出，可以捕获当前数据库管理器、数据库、缓冲池、表和表空间等快照信息。

2）管理视图（Administrative Views）：提供了基于SQL的接口来访问快照信息，但不适用于跨分区查询。

3）表函数（Table Functions）：比管理视图更加灵活，更适合于跨分区或者指定分区快照信息收集。

l  事件监控（event monitoring）

           事件监控用来收集当指定事件发生时数据库和已连接上的应用的快照信息，例如    语句、锁等。事件监控器使用DDL语句来操作，其状态可以是激活或者去激活。只有      状态是激活时，才启动信息收集。

l  db2pd

       最方便的性能监控工具就是db2pd了。db2pd的最大优点是信息获取非常快，并   且不需要消耗数据库引擎资源。

2.         数据库配置优先原则

       在进行系统分析确定性能问题的根源时，要优先检查数据库配置，这包括DB参数、DBM参数以及DB2环境变量等。如果发现是配置的问题，那么就可以优先通过调整配置来低成本地解决问题。配置的目标是能够使得数据服务器得以高性能运行，以提高投资回报率。

              从实际生产环境的例子来看，大多数DB2 系统都经过了性能的演变。为了达到良好性能，不论出于硬件还是软件的观点，我们都需要从软硬件配置方面来保障。因此，在前期花些时间去考虑基本的配置指导方针和建立健全系统监控这样的做法，将使你对处理许多可能出现的典型性能问题，有充分的准备。

l  硬件配置

       对于系统性能，CPU 的能力是各项配置中一个最主要的独立变量。因为所有其它的硬件配置取决于它。例如一个新系统需要多处理 50% 的用户请求，每个用户运行的SQL的复杂度类似现有系统，那么就可以合理地假设需要增加超过50%的CPU能力。一旦我们对 CPU 需求有了很好的认识并正确选型，那么硬件配置的其它方面例如内存、磁盘等就能基于CPU的处理能力完成选择。

       在一个数据库系统中，内存的主要作用是避免 I/O，归结为一点，拥有更多内存的系统能工作得更好。幸运的是，在过去几年中内存的成本已经有了显著的下降，并且系统拥有几十到上百 GB 的内存已经不再罕见了。通常，对于大多数应用程序每个处理器内核拥有 4 到 8GB 内存是比较合适的。

       虽然 CPU 的发展在过去十年在速度上有了惊人的增长，然而磁盘的发展相对落后。尽管磁盘的寻道时间和数据传输速率已经有了相当程度的提高，但是仍然无法跟上 CPU 的速度。因此为了达到系统总体性能需求，使用多个磁盘比之前任何时候都要重要，尤其是对于那些需要驱动繁重随机磁盘 I/O 的系统。很多时候，诱惑来自于使用最低的磁盘数目来存放所有的数据，然而这通常会导致较差的性能。在使用 RAID 存储的情况，凭经验估计合理的配置是每个处理器内核最少10到20个磁盘。

       为 DB2 事务日志分配专门的非共享的磁盘是很好的实践。这是由于日志的 I/O 特性与 DB2 容器有很大的不同。日志 I/O 与其它类型的 I/O 的竞争能导致日志成为一个瓶颈，尤其是那些有大量行写入行为的系统。

l  操作系统配置

       DB2数据库通常运行在包括AIX、Solaris、HP-UX、Linux等多平台上。为了取得比较好的性能，对于不同的平台需要做不同的参数调整。对于AIX平台，需要调整AIO、VMO等和CPU、磁盘有关参数的默认值；对于Linux平台，需要调整和共享内存有关的一些内核参数；对于Solaris或 HP-UX 上运行的 DB2，根据系统的大小，利用 db2osconf 工具来检测和推荐内核参数。关于操作系统配置的具体技术细节，可以参考本书第7章DB2配置优化与监控的相关部分。

l  DB2注册变量、DBM和DB参数配置

       在DB2数据库中，有DB2注册变量、实例级别配置参数（DBM CFG）和数据库级别配置参数（DB CFG）。通过对这些参数进行手工或者自动（DB2 AUTOCONFIGURE）调整，可以提升数据库性能。关于DB2参数的具体技术细节，可以参考本书第7章的相关部分。

l  负载管理配置

DB2工作负载管理是为了满足不同应用程序的业务优先权，并通过为不同的业务优先权定义的 DB2 服务类很好地反映出来。负载管理的基本概念包括工作负载、服务类、阈值、工作活动集和监控。DB2 工作负载作为主要控制点，基于工作提交者源，并通过连接属性将工作路由到服务类。DB2 服务类是所有进行中的工作活动的主要资源控制点。DB2 阈值基于预测性和响应性元素，为发生在数据库或服务类中的所有活动提供数据库行为控制。关于DB2工作负载管理的细节描述，读者可以参考本书第6章DB2工作负载设计。总结来看，DB2工作负载管理具有下述的几大优点：

l  提供稳定，可预测的执行环境

l  对监控活动任务提供轻量化及细粒度的解决方案

l  更好的资源管理

l  更好的请求管理

l  提高性能优化专家对数据库系统的高级分析能力

3.         数据库设计高质量原则

       考虑周详的数据库设计使得为DB2应用或系统提供最佳性能提供了保证，这需要在应用系统的早期就开始加以注意。因为数据库系统设计开发阶段是DB2应用优化的最佳阶段，也是主动优化阶段，能达到以最小成本获得最大性能增益的目的。凡是在DB2数据库设计开发阶段，创建一个设计优良的数据库，可以获得最小的系统开销，能从根本上大大提高应用系统的整体性能，这对于以后的数据库性能调整和优化都有很大的益处。

       从数据库设计实现过程来看，首先需要明确性能需求，做好性能规划，随后从业务角度做好逻辑设计，最后完成数据库物理设计。系统上线进入运行维护阶段出现性能问题时，如果确认是设计上的问题，就尽量通过调整设计来解决。具体设计细节参考本书第3、4、5章的相关设计部分。

4.         数据库优化平衡性原则

       同时，根据成本效益分析（Cost-Benefit Analysis）模型，我们不能片面追求优化的高性能，因为到了最后，取得的性能是和所要付出的成本强关联的。在当前范围内，只要能满足性能需求即可。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/25714482/viewspace-721241/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/25714482/viewspace-721241/