基本性能调整方法

基本性能调整方法

基本性能调整

Roger Sanders 著

笑熬浆糊 译

原文出处：《DB2 Magazine》 Quarter 3, 2003 · Vol. 8, Issue 3

英文原文（由于文章翻译未经授权，请在转载时保留原文链接）

你的平台--明确的指明从DB2 UDB中可以取得很好的性能

DB2 UDB 8。1 FOR LINUX、 UNIX、WINDOWS 的版本可以存在与简单的单一的系统上，也可以在存在与在各种平台上运行的、复杂的客户-服务器环境里。但是不论是什么环境，用户总是倾向于关心这样一个问题：数据库应用程序的性能。那么什么是性能，怎么样才能改善它？

简单地说，性能就是反映计算机系统执行一项指定的任务时候的具体表现。它主要用于测量系统响应时间、计算能力和可用性。 每一个度量都可能受几个因素影响，包括硬件、系统(和数据库) 配置、类型和同时工作的用户数量，以及每一个用户应用程序的负载。

如果系统执行效率低，你通常可以有几个调整的方法可供选择。由于有不同的选择，你总是倾向于选择一种被组织化的，简明的方式，在心里有一个具体的目标；并且那个目标应该是现实的，定量的，而且还是可以测量的; 否则，性能调整将会变成为一个hit-or-miss exercise.（注：原文如此，我不知道该怎么解释所以保留原文）

那么， DBA 应该从哪里开始呢? 通过对一个数据库的观察，性能问题比较典型的出现从在下列的一个或更多因素的不足上:

• 系统(环境) 配置
• 实例配置
• 数据库配置
• 数据库设计
• 应用程序设计。

关注你上述的每个要素的最初的调整效果，让他们在每一个因素下逐步的运转，直到得到你所期望的那些性能。 在这一章节中，我将描述怎么检查Linux 、Unix ，和windows平台系统环境配置。 在后续章节将覆盖到剩余的部分。 在具体介绍之前，虽然，我将介绍一些适合于所有平台的相关的调整指南。

一般性的调整规则

如果在你开始之前你能够关注一下这些指南，那么你将要调整的项目将会是更加容易和更可能会成功。

1. 检查已知的硬件和软件问题。 一些性能问题可能通过简单地更新软件补丁包或者升级硬件来改正。 既然有可能通过一个简单的service pack来解决问题那为何要浪费时间和精力去检查调整系统中的其它部分呢？也就是说，在你决定升级硬件之前请确定你已经了解问题的所在。在你发现系统实际上需要更多内存之前去盲目的增加其它网络接口卡将会付出昂贵的代价，它实际上是不会对改进性能有任何作用的。

2. 基于整个系统考虑。 通常，如果没有在这个系统的至少一个部件上起作用的话,你就不能调整这个系统的任何一方面。 例如，如果你为DB2 数据库管理器的后台进程预留出很大一块内存空间，那么你不会有足够的剩余空间去执行你的存储过程。所以，在你做改变之前，应该整体去考虑这些改变将会对系统造成什么样的影响。

3. 根据不同的级别去做测量和重新配置。不要在一次调整当中改变一个系统级别以上。 即使你确定你的计划是有益的，你将不得不评估每一个改变会对性能改善的结果产生多大的贡献。 如果你做错了，性能则有降无升，这样你就无法知道是哪项变动使它产生了负面的影响。在数据库服务器环境里，以下是可以作为独立考虑的级别： 硬件、操作系统、通信软件、数据库、SQL 语句以及应用程序。

4. 每次改变一件事。 因为同样原因你应该每次只调整一个系统级别，当你调整每一个系统级别你应该每次只改变一个要素(注册表变量、实例配置变量、数据库配置变量、等等)。

5. 在开始之前请将你的跟踪和反馈程序放置就位。性能的调整不是一门具体的学科。 你做的一些变动将会损害而不是有助于性能。 如果这样情况发生，如果你有办法撤销每一次所作的变动你就可以花费较少时间设法使系统回到修改之前的状态。 我喜欢使用shell 脚本程序或批处理文件去作变动。 那样，我将能存放一条命令（能返回一个等同与原始状态的配置值），并把它作为注释行直接放在赋予配置参量新值的命令之上。 然后，如果我需要取消变动，我把这行明令取消注释，而把引起变动的命令注释掉并且重新运行这个脚本或批处理文件，这样就可以了。如果你被一些改变强行退出,请准备好向每一个 必要的改变重新应用。

6. 不要因为觉得调整的好处而刻意去做调整。所执行的调整必须能解决一个明确的问题

。如果你的调整策略与让你试图解决问题的根源没有直接的关系的话，你将收获甚微或者一无所获直到问题的根源被最终解决。从某个角度而言,这样的行为确实为后来的调整工作带来更多的麻烦。

7. 谨记回报递减规律。 记住, 最高效的性能调整结果的收益通常来自你最初的努力。 随后调整将会导致逐步减小的收益和需要付出更多的努力。

调整的DB2 UDB 系统配置

当DB2 UDB安装后DB2 UDB会使用一套注册变量来配置系统。 其中一些变量对于性能起着关键性的作用; 而其他一些的影响则是微乎其微,甚至毫无作用。 接下来我将说明哪些注册变量能在每一个操作系统的平台上产生重大的影响。

切记，对这些变量的改动将会影响整个系统，因此在改变注册变量的时候要特别当心。

对于所有平台

以下变量的推荐适用于Linux 、Unix 和Windows平台。

DB2_APM_PERFORMANCE OFF是该注册变量的缺省值。这个参数指定是否能够在存取计划管理器（APM）中作出相应的调整，这样做就可以对SQL高速缓冲存储器的动作产生影响。它还阐述了全局性的SQL高速缓冲存储器是否能在没有使用任何包锁定的情况下工作，这是由阻止高速缓冲包从不被注意的与之无关的地方进入的内部系统锁机制所决定。

在nonproduction 环境里，这变量只能被设置为ON。 当设置成ON的时候，你可以看到Out of package cache的错误信息，并且内存使用率将会增加。 预编译、绑定和重新绑定（PRECOMPILE, BIND, and REBIND） 操作无法进行，也不能将这些包无效或者无法执行。

DB2_AVOID_PREFETCH 该变量指定在灾难性恢复期间是否执行预存取（prefetching） 。 缺省值是OFF ; 如果设置成ON，prefetching将不执行。

DB2BPVARS 支持DB2BPVARS的参数明确指出了在调整缓冲池（buffer pools）时使用的包含参数值的那个文件的位置，参数包括:

NO_NT_SCATTER

NT_SCATTER_DMSFILE

NT_SCATTER_DMSDEVICE

NT_SCATTER_SMS

NUMPREFETCHQUEUES

PREFETCHQUEUESIZE

对于每个带_SCATTER的参数，缺省值是 0 (或OFF )， 允许的取值是：0 (或OFF) 和 1 (ON)。 对于NUMPREFETCHQUEUES参数，缺省值是1； 参数值的范围是 1 到NUM_IOSERVERS。 对于 PREFETCHQUEUESIZE参数，缺省值是都是最大值： 100 或 2 * NUM_IOSERVERS。范围是 1 到32,767。

每一个_SCATTER参数都用于打开或关闭各自的表空间容器的scatter read（或者关闭所有容器的scatter read）。其他的参数则可用于提高缓冲池数据的预存取（prefetching）。

注: 当使用Windows操作系统并且DB2NTNOCACHE参数被设置成ON，那么带_SCATTER的参数只能被设置成ON。

DB2CHKPTR 该变量指定是否执行输入指针检查； 缺省值是OFF。

DB2_ENABLE_BUFPD 缺省值是OFF，它指明是否DB2 将使用中间缓冲去改进查询的性能。

DB2_EXTENDED_OPTIMIZATION 该变量指定查询优化器是否使用优化扩展去改进查询性能；缺省值是OFF。

DB2MAXFSCRSEARCH 该变量可能被设置成-1，或者是从 1 到33554的任何一个，为了在当增加一条纪录到一个表中的时候指定搜索可用空间控制纪录的数量。他允许你去平衡空间再使用的插入速度（小的数值使插入速度最优化,大的数值使空间再使用成为最优化）。 如果被设置成 -1，DB2 数据库管理器将搜寻所有可用空间控制纪录。缺省值是5。

DB2MEMMAXFREE 该变量指定每个DB2 代理将保留可以用内存的数量; 取值范围从0 到2.0e+32 字节。 缺省是8,388,608 个字节。

DB2_OVERRIDE_BPF 该变量可以被设置为整数个4K页，它指定将被创建在数据库北激活时或首次建立一个连接时的缓冲池的大小（在页面里）。当由于内存限制的发生导致出现故障时，DB2_OVERRIDE_BPF这个参数是非常有用的。这样内存限制可能出现在由于真正的内存不足（很少发生）或由于尝试用DB2 数据库管理器对缓冲池分配过大或者使用不恰当的配置的时候。缺省值是空。

DB2PRIORITIES 该变量的取值是与平台相关的。 DB2PRIORITIES 控制着DB2 进程和线程优先权。

DB2_SORT_AFTER_TQ DB2_SORT_AFTER_TQ 指定了在分区数据库环境下当接收端要求数据排序并且接收的节点数与发送的相等时DB2 优化器与引导表队列怎样协同工作。当设置成NO (缺省值) ，DB2 优化器倾向于在传送端进行排序并且在接收端进行合并行。当设置为YES，当所有行接收完成后，优化器在接收端传输未排序的行并将其排序。

DB2_STPROC_LOOKUP_FIRST 该变量指定DB2 UDB 服务器是否在察看sqllib/function目录 和 sqllib/function/unfenced目录之前执行对所有DARI（数据库应用程序远程接口，存储过程的过时术语）和存储过程的编目查找。缺省值是OFF。

DB2_HASH_JOIN YES 或者 NO 的取值指明是否在编译一个存取计划（access plan）的时候可以使用hash join。缺省值是NO。

DB2_PARALLEL_IO 可能的取值包括 * 和 NULL（缺省值），指定是否DB2在从表空间容器中读写数据时候使用并行I/O。

However, because of the one-page container tag, the extents will not line up with the RAID stripes. It may be necessary to access more physical disks than would be optimal during an I/O request unless this registry variable is set to ON.

DB2_STRIPED_CONTAINERS 该变量设置成ON或者NULL（缺省）指定表空间容器ID 标签是否采用部份或全部的RAID 磁盘数据条。 当使用RAID 设备，表空间创建的时候采用与RAID 数据块大小相等的或者是数倍的大小的数据条的扩展尺寸。然而，由于页容器标记的存在，扩展部分不能按照RAID数据条进行排列。访问更多物理硬盘比在I/O请求的过程中进行优化显得更有必要，除非该变量被设置为ON。

对于UNIX平台

以下变量适用于Unix 平台（AIX、HP-UX或者其他一些被提到的）。

DB2MEMDISCLAIM 该变量指明AIX操作系统是否应该停止页面内存使之不再占据任何的实际的存储空间。设置DB2MEMDISCLAIM为YES（缺省）指明在程序关闭的时候DB2 UDB释放部分或者全部内存，这取决于由DB2MEMMAXFREE注册变量所决定的值。如果DB2MEMMAXFREE为空，程序关闭的时候所有内存将被释放。如果DB2MEMMAXFREE被赋值，仅有部分的（最高到DB2MEMMAXFREE所设定得值）内存释放。程序终结时，释放保证了内存能被其他的进程所使用。

DB2_MMAP_READ 它与DB2_MMAP_WRITE一起使用，缺省值 YES 允许DB2 for AIX 使用mmap 作为I/O 一个交错法。 在多数环境中，mmap在使用的时候应该避免当多个进程对同一文件的不同扇区执行写入操作造成的操作系统锁定的情况。

DB2_MMAP_WRITE 它与DB2_MMAP_READ一起使用，缺省值是YES； 在这个时候他允许DB2 for AIX使用mmap 作为一个I/O的预备的方法。

DB2_PINNED_BP 这个AIX 和HP-UX平台上的变量指定是否数据库使用的全局内存 (包括缓冲池的内存) 将被保留在系统主存储器以获得更加稳定的数据库性能。

对于Windows平台

以下变量适用于Windows NT 操作环境。

DB2NTMEMSIZE Windows NT 要求, 所有共用存储器片段在初始化时都被储存在动态连接程序库，以保证程序运行的整个过程中均有匹配地址。必要的话，在Windows NT下可不考虑DB2的缺省值；但是，在多数情况下，缺省值应当足够使用。缺省值如下：

DBMS: 16,777,216;

FCM: 22,020,096;

DBAT: 33,554,432;

APLD: 16,777,216.

DB2NTNOCACHE