基本功用调整

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_OPTIMIZATI