|
基本性能调整
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
[1] [2] [3] 下一页
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
