——内存管理

介绍

想要通过DB2 LUW使你的应用系统得到最佳的性能，不仅要确定你的SQL是适当且高效的，还要确定DB2实例本身是已经经过适当的调优。正确的SQL代码在整体性能表现中是最基本的，但如果内存分配的不够或是数据库设计缺陷那么SQL语句也不能被正确执行。大多数人们容易犯同一个错误，就是他们仅仅是在努力的调优SQL却忘记了顾全大局。把你的DB2作为一个整体的系统去考虑，包括内存，物理的设计和SQL事务等等与之相关的一切。这样才能使你的性能得到改善。

如需免费开源工具，可下载Hyperic HQ 可将空DB2 7.x,8.x,9.x..

监控并调优一个DB2实例需要一定的时间和技能。许多LUW被安装是没有得到专家对环境的调整。然而，IBM的自动调整工具可以实现自动调优内存，自动维护，这使得DB2非常可靠且无须人为干涉，减轻了数据库管理员的工作。 

 这篇文章中，给出了一些DB2 LUW的内存核心结构和性能是如何衰竭的总体看法。然后讨论了一些新的可以帮助你减少工作量即可对DB2实例进行监控和维护的方法。 

内存管理

最小化物理I/O是性能调优中最重要的：恰当的分配内存对性能调优是非常有必要的。因为DB2的环境是会随着数据量，事务量，用户数等的变化而改变的。内存的使用必须被周期性的监控：你不能用"设置了它并忘记了它"的态度对待内存。这部分将描述DB2的内存是如何影响整体性能，还阐述了如何监视并调优的方法。 

1.DB2内存模型

  下图描述了DB2的内存模型

2.Catalog I/O

Catalog I/O可以分为Catalog Cache和Package Cache：

• Catalog Cache主要是用在程序准备过程中，所以在很多程序准备阶段的开发环境中对它的监视非常重要。当Catalog 从SYSTABLES中获得对象信息，从SYSDBAUTH检查授权并实行的时候，Catalog Cache的I/O是最小的。从DB2 LUW v9.5开始，Catalog Cache有了一个新的组件，叫做Statistics Cache；是为了统计对象的事实信息。
• Package Cache是用来载入包和缓存动态SQL。

Catalog I/O可以分为Catalog Cache和Package Cache：

性能影响

不适当的Catalog Cache会导致编译和检查数据库以及执行权限时间的增加。如果你的环境是静态的或没有应用开发，你可以考虑减少Catalog Cache的内存分配，将更多的内存分配到其他的地方如Buffer Pools。但如果是事实的统计系统则需要增大Catalog Cache的分配。

不适当的Package Cache会减速动态SQL的执行，也会延长载入包的时间。

如何监控

快照监控器（本文稍候说明）会在缓存溢出的区域以红色表明。

• Catalog cache hit ratio 80-90%
  ■ Catalog cache lookups
    ☆Cat_cache_lookups
  ■ Catalog cache inserts
    ☆ Cat_cache_inserts
  ■ Catalog cache overflows
    ☆ Cat_cache_inserts
• Package cache hit ratio
• Package cache overflows
  ■ Pkg_cache_num_overflows
• Package cache lookups
  ■ Pkg_cache_lookups
• Package cache inserts
  ■ Pkg_cache_inserts
• Package cache high water mark
  ■ pkg_cache_size_top 

3.排序

有效的排序可用提高SQL性能。可以避免物理磁盘的I/O。

4.如何监控

由于排序的重要性，需要监控Sort Heap并设置阀值。如果产生溢出，则会导致一个无效的排序代替有效的排序。无效排序意味着没有足够的内存用来保存排序结果集，所以当内存不足时则需要暂用数据库的临时表用来维持排序结果集的正确。

• Sort heap overflow
  ■ Sortheap
• Sort heap threshold
  ■ Sheapthres 

5.缓存器

缓存器在DB2中是一个虚拟存储区域，为了在查询中避免物理I/O。目标是在内存中尽可能多的保存被频繁访问的数据。

缓存器在DB2中是非常重要的一块内存区域；恰当的调整，会使性能得到很大的改善。

LUW数据库中，至少需要一个缓存器。一个默认的缓存器（IBMDEFAULTBP）在建立数据库的同时被自动创建。一连串的隐式的Page大小为4K, 8K, 16K, 32K的缓存器同时被创建，以防在内存不足的时候无法使用，或者因为其他的一些原因导致缓存器无法使用。这些隐式的缓存器在系统目录或缓存器系统文件中是看不到的。

性能影响

不恰当的或无效的配置缓存器会增大物理I/O导致降低整体性能。在LUW环境中，性能会急剧下降如果DB2需要使用隐式缓存池。如果出现了这样的情况，警告信息将会写到管理日至中。

有效的使用缓存器

缓存器的调整常常需要反复测试。最佳的设置与数据库类型和事务相关。但通常，需要按如下列表分别配置：

• System catalog
• Sequentially scanned tables
• Temporary tablespaces
• Small tables that are updated frequently
• Small, read-only tables
• Large tables with random access

如何监控

如果想要监控缓存器的命中率。额外的页表示缓存器不够大导致页常常被更新。监视缓存器的关键是通过一段时间的监控去修改配置。

• Overall hit ratio
  ■ Total # data/IX reads by BP
• Data hit rate
• Index hit rate
• Asynchronous page cleaners
• Num_iocleaners 

6.锁

锁列表

锁列表控制着大量可用于管理由于应用并发所产生的锁的内存。每个DB2 LUW只有一个锁列表。与锁列表相关的是最大锁，是由于应用运行时所需的增加的锁占锁列表的百分比。

性能影响

当用于锁列表的内存不够时，锁会逐渐增加并从一个行级锁逐渐转为表级锁。这会导致应用的并发减少，出现锁等待现象甚至死锁。使整体性能下降。

性能影响

当用于锁列表的内存不够时，锁会逐渐增加并从一个行级锁逐渐转为表级锁。这会导致应用的并发减少，出现锁等待现象甚至死锁。使整体性能下降。

监控什么

主要监控的是锁的增加。如果频繁发生锁增加，则你需要调整锁列表与最大锁的值。锁列表的值应该随着应用数的增加而增加。

应用中并发最大应用数的定义：

• Lock list
  ■ Locklist
• Maximum locks
  ■ Maxlocks
• Lock escalations
  ■ lock_escals

锁调优

 以下是一些减少锁发生的建议：

• 尽快提交更新事件
• 在应用执行大量更新的时候考虑使用 LOCK TABLE
• 使用OR STABILITY

（北京铸锐数码科技有限公司 www.InnovateDigital.com）