SORTHEAP (DB)
这个参数指定为私有排序 使用的最大私有内存页数，或者指定为共享排序使用的最大共享内存页数。每个排序都有一个独立的排序堆，这是由数据库管理器在需要的时候分配的。
通常大家都理解得很好的是，当一个排序所需的内存量超过了 SORTHEAP 时，就会发生 排序溢出。然而理解得不够好的一点是，如果统计信息已过时，或者数据有偏差，并且没有收集到发布统计信息，这时一旦 DB2 请求一个太小的堆，而实际的排序操作超出了所请求的量，就会发生溢出。因此，使统计信息保持时新十分重要。此外，应确保排序 不是一个丢失的索引的结果。
对于 OLTP，一开始最好是设为 128，对于 OLAP，则设置在 4096 - 8192 之间。如果有很多的 "Sort overflows" （两位数）那么很可能需要增加 SORTHEAP。如果 "Number of hash join overflows" 不为 0，则按照 256 逐次增加 SORTHEAP，直到它为 0。如果 "Number of small hash join overflows" 不为 0，则按 10% 的速度增加 SORTHEAP，直到小散列连接溢出数为 0。
CHNGPGS_THRESH (DB)
使用这个参数来指定缓冲池中被更改页面所占的百分比，此时将启动异步的页面清除器将更改写入到磁盘，以便在缓冲池中为新的数据空出空间。在只读环境下，不使用页面清除器。在 OLTP 中，使用 20-40 这样的一个值应该可以提高性能（在更新活动庞大的情况下使用 20），因为使这个值更低一些将使 I/O Cleaners 在从脏缓冲池页面写出数据时更具有侵略性，但是每次做的工作却变少了。如果没有很多的 INSERT 或 UPDATE，则对于 OLTP 和 OLAP 来说，缺省的 60 应该就比较好了。
如果 "Dirty page steal cleaner triggers"是一个两位数，则试着降低之。如果 "Buffer pool data writes"较高，而 "Asynchronous pool data page writes"较低，则试着降低这个参数。
从 FixPak 4 起，有另一种页面清除算法，这种算法可以提高特定缓冲池的性能。您需要令概要注册表变量 DB2_USER_ALTERNATE_PAGE_CLEANING=YES，这样忽略 CHNGPGS_THRESH。确保 NUM_IOSERVERS 至少为 3，否则它会拖新算法的后腿。
NUM_IOCLEANERS (DB)
这个参数指定一个数据库的异步页面清除器的数量，异步页面清除器将更改后的页面从缓冲池写到磁盘。一开始将这个参数设为等于系统中 CPU 的数量。当触发了 I/O Cleaners 时，它们会同时启动，因此您不希望有那么多的清除器，以致影响性能和阻塞其他处理过程。
如果 Asynchronous Write Percentage (AWP) 是 90% 或更高，则减少 NUM_IOCLEANERS，如果 Asynchronous Write Percentage (AWP) 小于 90%，则增加 NUM_IOCLEANERS。
AWP = (( "Asynchronous pool data page writes"+ "Asynchronous pool index page writes") * 100) / ( "Buffer pool data writes"+ "Buffer pool index writes")
NUM_IOSERVERS (DB)
I/O 服务器用于执行预取操作，而此参数则指定一个数据库的 I/O 服务器的最多数量。非预取 I/O 是从数据库代理调度的，因此不受此参数的约束。一开始将该参数设置为等于数据库所跨的物理磁盘数（即使是一个磁盘阵列中的许多磁盘或者一个逻辑卷中的许多磁盘） + 1 或 2，但是不大于 CPU 的 # 的 4-6 倍。
如果您很快看到 "Time waited for prefetch (ms)"，那么您或许想添加一个 IO Server，以查看性能是否有提高。
MAXFILOP (DB)
这个参数指定每个数据库代理所能打开的最大文件数。如果打开一个文件时被打开的文件数超出了这个值，则要关闭该代理正在使用的一些文件。过度的打开和关闭都会降低性能。SMS 表空间和 DMS 表空间文件容器都是视作文件来对待的。通常 SMS 使用的文件要更多一些。
增加该参数的值，直到 "Database files closed"为 0。
LOGPRIMARY、LOGSECOND 和 LOGFILSZ (DB)
LOGPRIMARY 指定要预先分配空间的主日志文件的数量，而 LOGSECOND 是按照需要来分配空间的。LOGFILSIZ 定义每个日志文件的大小。
如果 "Secondary logs allocated currently"的值很大，那么就可能需要增加 LOGFILSIZ 或 LOGPRIMARY （但是要确保 LOGPRIMARY + LOGSECOND 不超过 256）。还可以使用 "Maximum total log space used (Bytes)"来帮助指出对日志文件空间（主日志 + 从日志）的依赖性。
日志文件的大小对灾难恢复有一定的影响，因为在灾难恢复中要使用日志发送（log shipping）。日志文件比较大时，性能会更好些，但是可能潜在地增加丢失事务的程度。当主系统崩溃时，最近的日志文件及其事务可能无法发送到从系统，因为在失败之前没有关闭该文件。日志文件越大，随着日志文件的丢失，丢失事务的程度也越大。
LOGBUFSZ (DB)
这个参数允许指定用作在将日志记录写到磁盘之前的缓冲区的数据库堆（DBHEAP）的数量。当提交一个事务或者日志缓冲区已满的时候，就要将日志记录写入磁盘。对日志记录进行缓冲将导致将日志记录写入磁盘的活动不那么频繁，但每次要写的日志记录会更多。对于 OLTP，一开始以至少 256 页为佳，对于 OLAP，则以 128 页为佳。如果常常看到多于一对的 "Log pages read"，那么可能需要增加这个值。如果发生了回滚，也可能要读取日志页。
如果在试图增加 LOGBUFSZ 时收到一个错误，那么可以按相同数量增加 DBHEAP，然后再次尝试。
PKGCACHESZ (DB)
这个包缓存用作静态和动态 SQL 语句的缓存部分。缓冲包允许数据库管理器减少内部开销，因为它消除了在重新装载一个包时访问系统编目的需要；或者，对于动态 SQL，消除了重新编译的需要。
PKGCACHESZ 应该大于 "Package cache high water mark (Bytes)"。如果 "Package cache overflows"不为 0，那么可以尝试通过增加 PKGCACHESZ 来使这个计数器变为 0。
Package Cache Hit Ratio (PCHR) 应该尽可能接近 100%（而不从缓冲池中获取所需的内存）。用下面的公式来计算：
PCHR = (1-( "Package cache inserts"/ "Package cache lookups"))*100
CATALOGCACHE_SZ (DB)
这个参数用于缓存系统编目信息，例如 SYSTABLE、授权和 SYSROUTINES 信息。缓存编目信息十分重要，尤其是在使用 DPF 的情况下更是如此，因为不必为获得先前已经检索过的信息而访问系统编目（编目分区），从而减少了内部开销。
不断增加该值，直到对于 OLTP 的 Catalog Cache Hit Ratio (CCHR) 达到 95% 或更好的值：
CCHR = (1-( "Catalog cache inserts"/ "Catalog cache lookups"))*100
如果 "Catalog cache overflows"的值大于 0，也要增加该参数的值。还可以使用 "Catalog cache high water mark (Bytes)"来确定编目缓存曾消耗过的最多内存。如果 High water mark 等于允许的 Maximum 大小，那么就需要增加编目缓存堆的大小。
实验： DBM 和 DB 配置
下面的参数可能带来额外的性能。然而，快照中的特定监视器并不是直接报告出它们的影响。相反，可能需要一次更改一个参数，然后测量应用程序的总体性能。最好的测量方法是从几个快照中检查更改前后 SQL 的执行次数。
INTRA_PARALLEL (DBM)
该参数指定数据库管理器是否可以使用内部分区并行性（intra-partition parallelism）。缺省值 NO 对于并发连接较多的情况（主要是 OLTP）最好，而 YES 对于并发连接较少的情况以及复杂 SQL （OLAP/DSS）来说最好。混合的工作负载通常可以得益于 NO。
当启用该参数时，就会导致从共享内存中分配排序内存。此外，如果并发程度显著增加的话，还可能导致过多的系统开销。如果系统是非 OLTP 的，则 CPU 数对分区数的比例是 4:1，而 CPU 负载运行的平均百分比是 50%，INTRA_PARALLEL 很可能会提高性能。
DFT_QUERYOPT (DB)
用于指定在编译 SQL 查询时所使用的缺省优化级别。对于混合的 OLTP/OLAP，使用 5 或 3 作为缺省值，对于 OLTP，使用一个更低的级别，而对于 OLAP，则使用一个更高的级别。对于简单的 SELECTS 或短的运行时查询（通常只需花不到 1 秒钟就可以完成），使用 1 或 0 也许比较合适。如果有很多的表，有很多相同列上的连接谓词，那么尝试级别 1 或 2。对于超过 30 秒钟才能完成的长时间运行的查询，或者如果要插入一个 UNION ALL VIEW（这是在 FixPak4 中加进来的），那么可以尝试使用级别 7。在大多数环境下都应该避免使用级别 9。
UTIL_HEAP_SZ (DB)
该参数指定 BACKUP、RESTORE 和 LOAD 实用程序可以同时使用的最大内存数。如果正在使用 LOAD，那么对于每个 CPU 将 UTIL_HEAP_SZ 设置成至少 10000 页。
NEWLOGPATH (DB)
该参数指定最长 242 个字节的一个字符串，用于更改日志文件写和存储的位置。这可以指向一个全限定路径名，或者指向元设备。将日志路径更改到一个独立的本地高速磁盘（只用于日志记录）可以显著地提高性能。
进一步的 SQL 分析
Design Advisor
如果有一个针对特定问题的查询或者一组查询，那么可以将该工作负载输入到 DB2 Design Advisor (db2advis) 中，由它去推荐一组有效的索引。如果不知道 SQL，也可以
使用快照捕获动态 SQL。
用一个语句事件监视器收集在一段时间内发出的所有 SQL。
从 SYSCAT.STATEMENTS 编目视图中提取静态 SQL。
语句事件监视器的使用将在本节稍后一点讨论。
可以从 DB2 Control Center 使用 Design Advisor，或者从 CLP 命令行使用该工具。下面讨论这两种界面。
使用 DB2