【51CTO综述】IBM 为社区提供了DB2 免费版本 DB2 Express-C，它提供了与 DB2 Express Edition 相同的核心数据特性，为构建和部署应用程序奠定了坚实的基础。
DB2 性能优化是一件较为复杂的综合性的工作 , 需要对问题的根源作全方位的探索和思考。同时也需要较深厚的数据库管理经验与优化知识。这对于初学者来说可能有些勉为其难。但是在很多情况下，随着 DB2 数据库中的数据量的不断增长或者用户数的激增，数据库系统的性能会显著下降，而此时快速定位性能上的瓶颈则至关重要。下面简要地介绍一下 DB2 的调优的一些因素和工具，以及一些原理，使初学者对性能优化能够有一个大致的了解。
DB2 的性能优化可以从三个方面分析：内存，CPU 和 I/O 。
内存因素
在内存方面，主要是考虑缓冲池 (BUFFERPOOL) 的使用。缓冲池是一片用来缓冲从磁盘上读取的数据和索引的内存区域，这些数据和索引信息在缓冲池中进行运算后最终还要写回磁盘。缓冲池的页面大小有四种 (4K,8K,16K,32K)，分别对应四种不同页面大小的表空间。缓冲池的大小决定了能够从磁盘上缓冲数据的容量大小。当然缓冲池也不是越大越好，缓冲池过大可能会导致连接数据库的时间过长，因为在连接数据库时要为数据库的缓冲池分配内存空间。可以通过计算缓冲池的命中率来评估缓冲池的使用效率：缓冲池命中率 =(1-(( 数据物理读 + 索引物理读 )/( 数据逻辑读 + 索引逻辑读 ))) *100%，缓冲池命中率越大说明缓冲池的使用效率高。缓冲池命中率太小说明缓冲池太小应当调大。其中的数据物理读，索引物理读以及数据逻辑读和索引逻辑读都可以从缓冲池的快照中获取。
在内存方面要考虑的另外几个重要因素是排序堆 (SORTHEAP)，锁列表 (LOCKLIST), 日志缓冲区 (LOGBUFSZ) 。排序堆在查询结果带有排序选项而没有相关索引对应时将会被使用，排序堆太小会产生排序溢出 (Overflowed), 那些在排序堆中装不下的排序数据将会溢出到一个临时表中，这会使性能下降。与 SORTHEAP 参数相关的是 SHEAPTHRES_SHR 和 SHEAPTHRES，SHEAPTHRES_SHR 限制了一个数据库中共享排序的***内存，SHEAPTHRES 限制了私有排序的***内存。 LOCKLIST 指的是一个数据库中用来存放锁的内存空间，当这个参数设得过小会导致在锁用光这部分资源后导致锁升级(即多个行锁转化为一个表锁来释放出更多的资源)。这会导致系统的并行性下降，很多应用连接出现挂起，使得系统的性能衰退。所以尽可能调大 LOCKLIST 参数，这里需要指出 LOCKLIST 指的并不是锁的个数，而是以数据库页为单位的一片内存区域(在 32 位系统中每个锁需要 96 个字节，锁上加锁的话每个锁则需 48 个字节。在 64 位系统中每个锁需要 128 个字节，锁上加锁的话每个锁则需 64 个字节)。与 LOCKLIST 参数对应的是 MAXLOCKS 参数，MAXLOCKS 定义的是一个百分数，它指定了一个应用程序所能占用的***的锁空间占 LOCKLIST 的比例。日志缓冲区 (LOGBUFSZ) 指的是日志在写到磁盘以前用于缓冲的一片内存空间，这样可以减少写日志带来的过多的 I/O 。
从版本 9 以后 DB2 推出了一个新特性自调节内存管理器 (STMM: Self Tuning Memory Manager), 这个特性使得很多内存参数如前面所述的 SORTHEAP，LOCKLIST，LOGBUFSZ 等进行自动调节，当数据库参数 SELF_TUNING_MEM 设为 ON, 这些参数设为 AUTOMATIC 即可以进行自动调整。这样可以节省很多人工调整的时间。
CPU 因素
关于 CPU 因素首先是考虑 DB2 优化器 (OPTIMIZER) 对访问计划 (ACCESS PLAN) 的分析与优化。一般来说，一条 SQL 在执行时首先会被解析，然后进行语义分析，进而重写 SQL, 优化器会对重写过的 SQL 进行基于成本的分析最终选择最有效的访问计划。最终生成可执行代码(执行计划)来执行这条语句。查询访问计划的工具有很多，既有图形化工具 Visual Explain，也有命令 db2exfmt 来格式化解释表 (Explain tables) 中的数据生成 ACCESS PLAN 。还有命令 db2expln 查询 ACCESS PLAN 。
在 DB2 里的优化级别分为九级，缺省是第五级，级别越高优化器分析得程度越深。这个级别有数据库配置参数 DFT_QUERYOPT 决定。并不是级别设得越高性能越好，因为对于一些较为简单的 SQL 语句，如果优化级别过高那么花在优化 SQL 上的时间就会过长，而执行时间相对来说很短，有些得不偿失。在选择访问计划时，索引扫描的效率往往会比表扫描要高，所以索引的优化也是值得注意的。正确的建立索引会使查询性能大幅度的提高。
在 DB2 中连接 (JOIN) 分为三种：嵌套循环连接 (nest-loop join), 合并连接 (merge-join), 散列表连接 (hash-join) 。一般来说效率***的是嵌套循环连接，这种连接采用的是笛卡儿集，进行多次循环遍历得到结果。而合并连接和散列表连接只进行一次循环遍历，相对来说效率较高。其中散列表连接可以采用多个等式做为条件而合并连接只能采用单个等式作为条件。但是在有索引扫描的情况下嵌套循环连接效率则更高。当优化级别等于零时，连接只能采用嵌套循环连接， 当优化级别大于等于 1 时，连接可以采用合并连接。当优化级别大于 5 时连接可以采用散列表连接。散列表连接要求 SORTHEAP 比较大，因为要为生成散列表准备空间。
在考虑 CPU 因素时还要考虑 CPUSPEED 这个参数，这个参数标明了 CPU 的运行速度，它会帮助优化器评估***的访问计划。一般来说这个参数设为 -1，优化器将自动计算 CPU 的速度。另外运用多分区的特性可以把一个数据库分布到多台机器上，这样可以充分利用多台机器的 CPU 的资源对应用程序的事务进行并行处理，从而提高数据库的性能。
I/O 因素
关于 I/O 因素要考虑以下几个方面：首先是磁盘的 I/O, 为了能够***化磁盘的 I/O 可以把数据，索引以及日志分别放在不同的硬盘上。因为在一个事务中数据和索引可能需要同时访问，而在事务提交时，数据和日志要同时写入磁盘，而且有可能索引也要同步维护，所以将它们放在不同的硬盘上可以使它们的读写并行运行，从而不致使磁盘成为瓶颈。同时选择数据库管理表空间 (DMS) 要比系统管理表空间 (SMS) 性能要好，因为读写 SMS 需要经过操作系统的 cache 再到缓冲池，而可以采用裸设备的 DMS 则不需要。但是 DMS 相对 SMS 来说维护起来较麻烦。
其次要考虑的是日志文件的大小，当数据库在写事务日志时当一个日志文件写满后会转向另外一个日志文件，这种日志文件的切换会造成操作系统上的开销。所以应当尽量将日志文件大小(LOGFILSIZ)设得大一些，这样可以减少日志文件切换的次数。但是日志文件过大难免会造成一些空间的浪费。
同时也要考虑到隔离级别的因素，在 DB2 中隔离级别分成 4 级：可重复的读，读稳定性，游标稳定性和未提交的读。这四种级别逐个降低。越高的隔离级别越能保证数据完整性，但却会降低并发性，所以应当综合权衡后做出决定。隔离级别可以通过如下命令来改变：
CHANGE ISOLATION TO=CS|RR|RS|UR
在连接方面还要考虑到代理和连接的关系，这也会影响到数据库的并发性，具体信息可以参考资源部分。
***要考虑的还是关于多分区的特性。在多分区数据库中，一个请求首先传到协调分区，然后由协调分区将请求细分成多个部分发送到其他分区，这样数据可以在各个分区进行并行读写，实现 I/O ***化。
性能优化相关工具
在 DB2 中有很多和性能优化相关的工具和命令，下面简单地介绍几种：
- SNAPSHOT : 这是 DB2 获取数据库信息快照的一种方法。它能够获取在数据库中关于缓冲池，锁，排序以及 SQL 等等信息。 DBA 可以通过获取这些信息来对数据库中的各组件进行评估来分析问题的瓶颈。
- DB2PD : 这个命令是用来分析数据库的当前状态，它带有很多参数。可以用来分析应用程序，代理，内存块，缓冲池，日志及锁状态等信息。
- RUNSTATS : 这个命令是用来收集数据库中数据的***统计信息，并更新到系统表中。更新统计信息将会促使优化器选择更加符合实际的高效的访问计划，从而提高工作效率。
- REORG : 这个命令用来重新整理数据库中数据和索引的碎片，使其在物理上可以得以按一定规则排列，这样可以加快检索的速度。
- DB2DART : 这个命令是一个数据库的分析和报告工具，它用来检查表空间，索引以及数据库结构的正确性，分析在性能问题上的一些原因。
- DB2SUPPORT : 这个命令用来收集 DB2 和操作系统的所有相关信息并生成一个压缩文件，可传送给优化人员进行分析。
还有一些 DB2 中其他的文件可以用来分析性能问题，比如说诊断日志，追踪文件等。一些第三方的工具也可供参考，如“ tivoli monitor for db2 ”， QUEST 等等。
其他性能因素
XML 的优化： 在 DB2 V9 以后引入了纯 XML 的数据类型，这是一种层次型数据类型。这和传统的关系型数据类型不一样，在 V9 以前 DB2 存储 XML 数据使用 CLOB 数据类型，应用程序在存取 XML 数据的时候必须先要解析 XML 再使用其数据。而在纯 XML 类型中，可以直接读取其中的元素，这样性能会有较大的提高。另外针对纯 XML 还有 XML 的索引，也会增大存取的性能。
操作系统： 数据库存在于操作系统之上，操作系统的性能将直接影响到数据库的运行效率，因此优化操作系统也是优化数据库的一个重要过程。在操作系统级别上可以对内存进行优化，比如说对系统共享内存，信号量以及虚拟内存的设置等等都可以影响到数据库的性能。同时在磁盘的分布上也会影响到数据库 I/O 效率。
网络： 网络将会影响到数据库的 I/O 性能，当数据通过网络在客户端和服务器端进行传送时，网络上出现瓶颈会导致数据库 I/O 性能显著下降。所以选择优良的网络设备以及配置良好的网络环境对数据库性能相当重要。同时也要考虑到防火墙的因素，有时防火墙会阻挡来自某些 IP 的数据包。
编者介绍
李越 (liyyue@cn.ibm.com), 软件工程师, IBM
李越 IBM 中国软件开发中心 WebSphere Federation Server 测试部门软件工程师。曾在 developerWorks 中国发表过有关优化 DB2 的代理和连接的文章。
王飞鹏, 软件工程师, WSO2 Inc
王飞鹏来自 IBM 中国 Avalanche 团队，目前从事 Oracle/Teradata 数据库迁移到 DB2 数据库的售前咨询和客户支持工作；有为电信、地铁、中央部委实施数据库、数据仓库的成功经验；是 DB2 性能优化、Oracle 迁移到 DB2、DB2 9.7训练营、IBM Information Server 训练营、DB2 大学生训练营的培训讲师；拥有软件专利3项，著有《DB2设计与性能优化-原理、方法和实践》一书。
狄浩, 软件工程师, WSO2 Inc
狄浩，IBM 中国软件开发中心软件工程师，主要从事 IBM CM 内容管理产品的相关工作，最近对 DB2 的性能调优比较感兴趣。
张蓉蓉 (rrzhang@cn.ibm.com), 软件工程师, WSO2 Inc
