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

  ● 第一步,问题监控

  ● 第二步,配置检查

  ● 第三步,设计检查

  ● 第四步,性能优化

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

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

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

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

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

  ● 系统监控

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

工具
平台
监控内容
Iostat
UnixLinux
磁盘
Vmstat/sar
UnixLinux
CPU、内存、磁盘
Perfmon
 windows
CPU、内存、磁盘
Nmon
Aix
CPU、内存、磁盘
Netstat
UnixLinux
网络
Top
Linux
CPU、内存
 
  ● 快照监控(snapshot monitoring)

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

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

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

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

  ● 事件监控(event monitoring)

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

  ● db2pd

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

  2、数据库配置优先原则

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

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

  ● 硬件配置

  对于系统性能,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的竞争能导致日志成为一个瓶颈,尤其是那些有大量行写入行为的系统。