最简略而最见成效的——Bufferpool

缓冲池是内存中的一块存储区域，用于暂时读入和更改数据库页(包含表行或索引项)。缓冲池的用处是为了进步数据库体系的功用。从内存拜访数据要比从磁盘拜访数据快得多。因而，数据库办理器需求从磁盘读取或写入磁盘的次数越少，功用就越好。对一个或多个缓冲池进行装备之所以是调优的最重要方面，是因为衔接至数据库的运用程序的大多数数据(不包含大目标和长字段数据)操作都在缓冲池中进行。

缺省状况下，运用程序运用缓冲池 IBMDEFAULTBP，它是在创立数据库时创立的。当 SYSCAT.BUFFERPOOLS 目录表中该缓冲池的 NPAGES 值为 -1 时，DB2 数据库装备参数 BUFFPAGE 操控着缓冲池的巨细。不然会疏忽 BUFFPAGE 参数，并且用 NPAGES 参数所指定的页数创立缓冲池。

主张关于仅运用一个缓冲池的运用程序，将 NPAGES 更改成 -1，这样 BUFFPAGE 就能够操控该缓冲池的巨细。这使得更新和陈述缓冲池巨细以及其它 DB2 数据库装备参数变得愈加便利。

保证能够运用数据库装备中的 BUFFPAGE 参数来操控缓冲池巨细之后，将该参数设置成适宜的值。依据数据库的巨细和运用程序的性质将该参数设置成一个合理的大值，这种做法很安全。一般，该参数的缺省值十分小，或许满意不了要求。

DB2 "get snapshot for all bufferpools"

在数据库快照或缓冲池快照的快照输出中，查找下列"logical reads"和"physical reads"，这样就能够核算出缓冲池命中率，它能够协助调优缓冲池:

缓冲池命中率标明数据库办理器不需求从磁盘装入页(即该页现已在缓冲池中)就能处理页恳求的时刻百分比。缓冲池的命中率越高，运用磁盘 I/O 的频率就越低。按如下核算缓冲池命中率:

(1 - ((buffer pool data physical reads + buffer pool index physical reads) /

　　(buffer pool data logical reads + pool index logical reads))

　　) * 100%

这个核算考虑了缓冲池高速缓存的悉数页(索引和数据)。抱负状况下，该比率应当超越 95%，并尽或许挨近 100%。要进步缓冲池命中率，请测验下面这些办法:

1. 增加缓冲池巨细。

2. 考虑分配多个缓冲池，假如或许的话，为每个经常被拜访的大表所属的表空间分配一个缓冲池，为一组小表分配一个缓冲池，然后测验一下运用不同巨细的缓冲池以查看哪种组合会供给***功用。

3. 假如已分配的内存不能协助进步功用，那么请避免给缓冲池分配过多的内存。应当依据取自测验环境的快照信息来决议缓冲池的巨细。

4. 太小的缓冲池会产生过多的、不必要的物理 I/O。太大的缓冲池使体系处在操作体系页面调度的危险中并耗费不必要的 CPU 周期来办理过度分配的内存。正好适宜的缓冲池巨细就在"太小"和"太大"之间的某个平衡点上。恰当的巨细存在于报答即将开端削减的点上。

取得***功用的——SQL

一条糟糕的 SQL 句子会完全损坏悉数。一个相对简略的 SQL 句子也能够搞糟一个调整得很好的数据库和机器。关于许多这些句子，天底下(或在文件中)没有 DB2 UDB 装备参数能够纠正因过错的 SQL 句子导致的高本钱的状况。

更糟糕的是，DBA 常常遭到种种捆绑:不能更改 SQL(或许是因为它是运用程序供货商供给的)。这给 DBA 只留下三条路可走：

1. 更改或增加索引

2. 更改群集

3. 更改目录核算信息

强健的运用程序由不计其数条不同的 SQL 句子组成。这些句子履行的频率随运用程序的功用和日常的业务需求的不同而不同。SQL 句子的实际本钱是它履行一次的本钱乘以它履行的次数。

每个DBA 所面对的严峻的使命是，辨认具有***"实际本钱"的句子的应战，并且削减这些句子的本钱。

经过本机 DB2 Explain 实用程序、一些第三方供货商供给的东西或 DB2 UDB SQL Event Monitor 数据，能够核算出履行一次 SQL 句子所用的资源本钱。可是句子履行频率只能经过细心和耗时地剖析 DB2 UDB SQL Event Monitor 的数据来了解。

***功用不只需求扫除高本钱 SQL 句子，并且需求保证相应的物理根底结构是恰当的。当悉数的调理旋钮都设置得适可而止、内存被有效地分配到池和堆并且 I/O 均匀地分配到各个磁盘时，才可得到***功用。

不行遗失的——Lock

这些与锁相关的操控都是数据库装备参数:

LOCKLIST 标明分配给锁列表的存储容量。每个数据库都有一个锁列表，锁列表包含了并发衔接到该数据库的悉数运用程序所持有的锁。确认是数据库办理器用来操控多个运用程序并发拜访数据库中数据的机制。行和表都能够被确认。依据目标是否还持有其它锁，每把锁需求 32 个或 64 个字节的锁列表：

1. 需求 64 个字节来持有某个目标上的锁，在这个目标上，没有持有其它锁。

2. 需求 32 个字节来记载某个目标上的锁，在这个目标上，现已持有一个锁。

MAXLOCKS 界说了运用程序持有的锁列表的百分比，在数据库办理器履行锁晋级之前有必要填充该锁列表。当一个运用程序所运用的锁列表百分比到达 MAXLOCKS 时，数据库办理器会晋级这些锁，这意味着用表锁替代行锁，然后削减列表中锁的数量。当任何一个运用程序所持有的锁数量到达整个锁列表巨细的这个百分比时，对该运用程序所持有的锁进行锁晋级。假如锁列表用完了空间，那么也会产生锁晋级。数据库办理器经过查看运用程序的锁列表并查找行锁最多的表，来决议对哪些锁进行晋级。假如用一个表锁替换这些行锁，将不再见超出 MAXLOCKS 值，那么锁晋级就会中止。不然，锁晋级就会一向进行，直到所持有的锁列表百分比低于 MAXLOCKS。MAXLOCKS 参数乘以 MAXAPPLS 参数不能小于 100。

尽管晋级进程自身并不必花许多时刻，可是确认整个表(相关于确认单个行)下降了并发性，并且数据库的全体功用或许会因为对受锁晋级影响的表的后续拜访而下降。

LOCKTIMEOUT 的缺省值是 -1，这意味着将没有锁超时(对 OLTP 运用程序，这种状况或许会是灾难性的)。许多 DB2 用户用 LOCKTIMEOUT = -1。将 LOCKTIMEOUT 设置为很短的时刻值，例如 10 或 15 秒。在锁上等候过长时刻会在锁上产生雪崩效应。

首要，用以下指令查看 LOCKTIMEOUT 的值：

db2 "get db cfg for DBNAME"

并查找包含以下文本的行：

Lock timeout (sec) (LOCKTIMEOUT) = -1

假如值是 -1，考虑运用以下指令将它更改为 15 秒(一定要首要问询运用程序开发者或供货商以保证运用程序能够处理锁超时)：

db2 "update db cfg for DBNAME using LOCKTIMEOUT 15"

一起应该监督锁等候的数量、锁等候时刻和正在运用锁列表内存(lock list memory)的量。请宣布以下指令：

db2 "get snapshot for database on DBNAME"

假如 Lock list memory in use (Bytes) 超越所界说 LOCKLIST 巨细的 50%，那么在 LOCKLIST 数据库装备中增加 4k 页的数量。

#p#

掩盖问题的—SORTHEAP

SORTHEAP 是一个数据库装备参数，它界说了私有排序所运用的私有内存页的***数目，或同享排序所运用的同享内存页的***数目。假如排序是私有排序，那么该参数影响署理程序私有内存。假如排序是同享排序，那么该参数影响数据库的同享内存。

每个排序都有独自的由数据库办理器按需分配的排序堆。在排序堆中对数据进行排序。假如由优化器来辅导排序堆巨细的分配，那么用优化器供给的信息来分配的排序堆的巨细要小于由该参数所指定的排序堆巨细。

SHEAPTHRES 是一个数据库办理器装备参数。私有和同享排序所运用内存的来历不一样。同享排序内存区的巨细是在***次衔接到数据库时依据 SHEAPTHRES 值以静态方法预先确认的。私有排序内存区的巨细是不受约束的。关于私有排序和同享排序，运用 SHEAPTHRES 参数的方法不同:

关于私有排序，SHEAPTHRES 是对私有排序在任何给定的时刻能够耗费的悉数内存的实例级"软"约束。当实例的总私有排序内存耗费量到达这一约束时，为其它进入的私有排序恳求而分配的内存会大大削减。

关于同享排序，SHEAPTHRES 是对同享排序在任何给定的时刻能够耗费的悉数内存的数据库级"硬"约束。当到达这一约束时，不允许有其它同享排序内存恳求，直到总的同享内存耗费量回落到 SHEAPTHRES 所指定的约束以下。

运用排序堆的操作示例包含内存中表的散列衔接和操作。阈值的显式界说避免数据库办理器将过多数量的内存用于很多排序。

主张

◆ 运用数据库体系监督器来盯梢排序活动。

◆ 运用适宜的索引使排序堆的运用降到***。

◆ 当需求频频进行大型排序时，增加 SORTHEAP 的值。

◆ 假如增加 SORTHEAP，请确认是否还需求调整数据库办理器装备文件中的 SHEAPTHRES 参数。

◆ 优化器用排序堆巨细来确认存取途径。在更改该参数后请考虑从头绑定运用程序(运用 REBIND PACKAGE 指令)。

◆ 抱负状况下，应当将排序堆阈值(SHEAPTHRES)参数合理地设置为在数据库办理器实例中设置的 SORTHEAP 参数***值的倍数。该参数至少应当是实例中任何数据库所界说的*** SORTHEAP 的两倍。

怎么更改这些参数

要更改 SORTHEAP 和 SHEAPTHRES 的值，请运转以下指令:

-- SORTHEAP should be changed for individual database --

　　db2 "update db cfg for DB_NAME using SORTHEAP a_value"

　　-- SHEAPTHRES is a database manager parameter --

　　db2 "update dbm cfg using SHEAPTHRES b_value"

研讨过程

OLTP 运用程序不应该履行大型排序。大型排序在 CPU 和 I/O 资源方面的本钱太高了。一般，SORTHEAP 巨细的缺省值(256 个 4KB 页)就足够了。事实上，关于高并发性 OLTP，或许期望下降这个缺省值。当需求进一步研讨时，能够宣布下面这条指令:

db2 "update monitor switches using sort on"

然后，让运用程序运转一会，然后输入:

db2 "get snapshot for database on DBNAME"

依据该输出，能够核算每个业务的排序数目，并能够核算溢出了可用于排序的内存的那部分排序的百分比。

db2 "get db cfg for DBNAME"1

db2 "get db cfg for DBNAME"2

db2 "get db cfg for DBNAME"3

db2 "get db cfg for DBNAME"4

经历:假如 db2 "get db cfg for DBNAME"1 大于 5，它或许标明每个业务的排序太多。假如 PercentSortOverflow 大于 3%，那么或许产生了严峻的、未曾预料到的大型排序。产生这种状况时，增加 SORTHEAP 只会躲藏功用问题 - 却无法批改它。这个问题的正确解决计划是经过增加正确的索引改善有问题的 SQL 句子的存取计划。

【修改引荐】

1. DB2数据库移植常见问题全面解析
2. DB2业务日志运用详解
3. 怎么树立DB2服务器报表并在前端Access显现