-
在开辟进程的晚期作出的良多打算决意对 DB2 把持程序和数据库的功能有着伟大的影响。本文为在 z/OS 状况中失失更好的功能供应了一些普通性的指南和提议。
简介
本文的目的是为 IBM 业务伙伴供应关于 DB2 Universal Database (UDB) for z/OS（前面将简称为 DB2）状况中 DB2 数据库功能的严重信息。本文试图从多处网络材料，并尽可以有效地将它们表述出来。本文无意包罗很全面的范围，也不会包罗很深的细节。
我曾诡计评论斗嘴对 DB2 数据库的功能影响最大的一些要素。可是，并不是一切可以的气候都可以展望到，也不是一切潜伏的思量都能顾及到，更不消说在企望的范围内对它们中断描写了。我希望本文可感受差别状况下的 DB2 用户供应一个通用的指南，以资助他们失失最佳的 DB2 数据库功能。本文的目的是成为一个良好的起点，用以措置处罚任何给定安装状况下的数据库功能问题。
本文的范围是数据库打算功能。DB2 功能远不止这一部分，它一定要遭到数据库打算以外的良多要素的影响。比如，程序的编码逻辑和此中运用的现实的 SQL 语句，可以列为把持程序打算一类。DB2 体系功能可以包罗诸如安装选项、缓冲池大小设置、DB2 干系所在空间的调治优先级等等之类的要素。
本文的焦点是 DB2 数据库的打算。不外，无意辰这些功能要素种别之间的界限可以会有些模糊。比如，在某种安装状况下中断设置时，缓冲池大小的设置和数目的选择常常被以为是一项体系功能要素。可是，如果果将特定的表空间和索引指派给那些缓冲池，那么这些要素又可以看作是数据库打算一类的要素了。
在这里，我假定读者对 z/OS 状况中的 DB2 有一个根底的认识。本文的头几页将评论斗嘴功能经管的一些根底不雅点和准绳，以便中断"级别设置" 。我的提议有点综合的性质，是以不会总是具体地给出妙技性的描写和语法。读者如果想认识关于这些内容的更具体的信息，那么应该去阅读关于用户当地所安装的 DB2 版本的迩来的 IBM 文档。
本文的通用打算点是 DB2 for z/OS V7。固然 DB2 for z/OS V8 已经被宣布，而且也普遍可用（generally available ，GA），可是大部分 IBM 客户极有可以必要几个月的时分才华完成用于他们的斲丧体系的 DB2 V8 NFM （New Function Mode）。而且，这里还要思量此外一个要素。固然 DB2 的每个新版本在变得普遍可用之前，都已经在 IBM 及其客户状况下颠着末普遍的测试，可是干系于一个还没有推行的、没有普遍运用的版本而言，客户们常常关于基于起先版本的 DB2 的普通提议和秘诀更有决意信念（永劫间积累的经历验证了这一结论）。我将提到 DB2 V8 的一些新特征，从功能的角度来看，这些新功能可以会影响数据库打算。
免责声明：本文中所包罗的信息未经任何正式的 IBM 测试，而是以 AS IS 的体例宣布的。对这些信息的运用和此中任何妙技的完成，都由用户担负责任，并取决于用户的才略去评价它们和将它们整合到客户特有的操作状况。固然 IBM 关于每一项都中断了审查，以求特定状况下的正确性，但不克不及包管在其他状况下也能失失相同的或相似的结果。试图将这些妙技把持于他们自身状况的用户须自己担负风险。
功能准绳和体例学
何时思量功能
思量把持程序和数据库的功能特征的机会是在那些把持程序和数据库的初期打算阶段，也等于开辟进程的起头阶段。对 DB2 把持程序和数据库所需的资源中断公平的估量，这有助于用户在开辟进程的晚期便对打算和完成作出适当的决意。如果等到前期才来思量接见数据库的把持程序的功能，那么为了失失适当的照应时分和天生批措置处罚窗口而中断一些必须的修正时，就会更加难题，而且更加花消时分。
应该存眷些什么
当从功能的角度中断打算时，将大部分的精力集合在 严重DB2 数据和程序上，这种做法对照明智。在确定是什么把持程序或事宜组成这一严重的事变负载时，以下特征中的一条或几条将会适用：
1、它们代表了总体业务事变负载的很大的百分比。
2、它们有着关键照应时分需求。
3、它们包罗伟大的逻辑和/或数据接见需求。
4、它们接见少量的数据。
5、它们花消少量的资源。
6、与那些属于公司内部的把持程序相比，它们是间接与客户打交道的（经由过程 Web、ATM 等）。
数据库打算
数据库的打算有两个阶段：
1、逻辑数据库打算
2、物理数据库打算
数据库的逻辑模子仅仅是对用户的一切数据需求的一种默示，它将这些需求酿成一种范式。这种模子常常等于数据建模集会的输入或最终结果。该模子现实上很少被原原来当地完成。真实，该模子只是在思量怎样现实地机关数据和将数据存储在 DBMS 之前，对数据的一种志向化的见地。
在对数据库对象的架构中断了思量之后，逻辑模子就被转化为物理模子。在打算的这个阶段，就必要较为具体地思量数据接见需求和功能要素。在发作物理打算的这个进程当中，有两大体素，即表打算和索引打算。上面将较为具体地评论斗嘴这两个话题。
DB2 功能经管的体例
为了确保 DB2 把持程序具有合格的功能，未雨缱绻胜于亡羊补牢。在打算 DB2 数据库的晚期阶段就将功能要素思量出去，这一点很严重。然后，在项目尽可以早的时候，树立一套符合 service level agreement (SLA) 的功能"基准线"丈量体例，这样，便可以在展现的时候和把持程序被修正的时候，跟踪功能特征和趋势。同时还应该连续地监控 DB2 体系和把持程序，从而在大的问题完全爆发之前中断展望。
常常，良多客户只要到了把持程序开辟项目的最末尾段才起头担忧功能。可是常常没有什么好的理由必要等到事先才去思量功能。更好的做法是，在指定了用户界面和措置处罚逻辑之后，立即思量数据库打算的功能特征。比如，在创立最佳索引时，应该将 严重DB2 事变（请参阅前面的评论斗嘴）中 SQL 语句的谓词作为严重指南。
纵然您可以开辟一个有效的初期打算，跟着数据量的添加，可能在体系资源紧缺的时候，也仍有必要对把持程序和/或数据库作出修正。如果一个把持程序实行时的功能分歧格，较为可取的做法常常是添加更多的列到现有的索引中，可能为一个表添加新的索引，这种做法是首选。而变动表的打算，或修正用户需求，抑或修正反范例化（de-normalizing）表，都不是很有吸引力的选择。
认识 DB2 功能
Rules-of-thumb
Rules of thumb （经历规矩，也称 ROT）在诡计、监控和优化 DB2 功能的时候很有效。ROT 常常是基于夙昔的经历（比如在一段时分外调询接见到的均匀值）可能更伟至公式的简化。
记着这样一个究竟很严重，即 ROT 只关于大约的估量有效，而关于具体的分解用途不大。如果只是在某一类的文档中看到了一些 ROT，便欣然担负负责并作为正确的究竟来援用，那么就会有风险。在最好的状况下，这些 ROT 是一种估量，而在最坏的状况下，这些 ROT 关于特定的 DB2 状况可以不确立。
您应该为自己的状况分外开辟这些 ROT（可能对它们中断调治，以顺应自己的状况的特征）。应确保 ROT 与现实经历干系，而不是盲目地担负负责，这样才华对它们更有决意信念。一路头的时候，运用那些在您特定状况以外被运用过可能被开辟出来的 ROT，这种做法可以有效。可是，当对您自己 DB2 体系中的适当数据中断网络、分解和体例文档之后，应该对这些 ROT 加以验证和修正。IBM Redbooks 是关于 ROT 的一种很好的参考材料，这些 ROT 凡是作为提议被包罗在功能监控对象中。
另一方面的思量是，ROT 可以跟着时分的推移而 演化。硬件妙技的发展，软件编程妙技的进步，体系架构的转变，诸云云类的转变都可以使得 ROT 的平稳性降低，乃至变得有效。而使 ROT 跟着时分转变的最大要素梗概恰是 DB2 自身新版本的发行。
DB2 事变负载
磁盘 I/O 凡是是影响照应时分的最大要素，可是经由过程搜检 GETPAGE (GP) 乞请，更苟且认识底层的功能问题。当监控 DB2 勾当和分解呈文时，GETPAGE 的数目梗概是 DB2 总体事变负载的最好的指示器。
某个安装状况下的良多 DB2 事变都可以无贰言地归为以下几类：
事宜： 事宜是在事宜经管器（比如 CICS 和 IMS/TM）控制下运转的程序。此中的 SQL 常常对照伟大，可是事宜量对照重。事宜必须为用户供应极好的照应时分，这样把持程序才不致于要永劫间地等候它们所需的资源。常常，第一个调用事宜的用户将遭受读取索引和数据页的本钱。随后的用户则凡是可以发明有些资源已经在缓冲池中。
查询： 查询也是程序，凡是在必要决议诡计支撑时实行它。此中的 SQL 可以极端伟大，可是事变量凡是远不及事宜。查询的用户凡是要等上数分钟乃至数小时，这取决于为了发作用户所乞请的结果集，必要对若干好大都据中断搜索。查询凡是要惹起对整个表的扫描，而对结果排序是这种类型的事变负载的另一种稀有特征。
批措置处罚和适用程序： 批措置处罚和适用程序常常措置处罚少量的数据，而且凡是以一种陆续的体例措置处罚数据。这些程序在给定的 窗口中完成它们的措置处罚，这一点很严重。批措置处罚和适用程序常常是各种体系资源的斲丧大户，一旦它们挤在一同，凡是会使事变负载逐步上升。
范例化
范例化是分解把持程序所需的数据实体，然后将这些数据实体转化成一组打算良好的布局的一个花式化的进程。逻辑数据模子的普通打算目的是正确性、不异性、非冗余和伟大性。而且，关系现实的信条也要求数据库要颠末 范例化。
有一些依据陆续编号铺排的规矩（也叫 范式（form））可以用来很具体地界说范例化数据。大少数专家城市提议打算者只管固守前三条规矩，由此失失的数据就可以说是符合 第三范式。
而将一个表 反范例化（de-normalize）的意思是，违反该表之前固守的一种或多种范式，从而修正范例化的打算。这种反范例化的进程凡是是因为功能的缘由而中断的。在大少数以关系数据库为主题的书籍当中，都可以找到关于范例化的更具体的信息。
DB2 表空间范例
在一个界说好的 DB2 数据库中，现实的表必须在称作 表空间（table space）的 DB2 对象中创立。用户可以在 DB2 中界说 4 种差别的表空间：
伟大表空间：伟大表空间可以包罗一个以上的 DB2 表。这种表空间由页组成，每个页可以包罗该表空间中界说的任何表中的行。
分段表空间： 分段表空间可以包罗一个以上的 DB2 表。这种表空间由页组组成，页组被称作 段（segment）。每个段只能包罗该表空间中界说的一个表中的行。
分区表空间：分区表空间只能包罗一个表。依据 分区（partitioning）索引的键范围，这种表空间被分红数个分区。每个分区都被看作一个独立的实体，许可 SQL 和 DB2 适用程序对其中断并发措置处罚。
LOB 表空间： LOB 表空间只用于 LOB（大型对象）数据。LOB 包罗三种数据范例：BLOB（二进制大型对象）、CLOB（字符大型对象）和 DBCLOB（双字节字符大型对象）。
表空间与表打算方面的思量
记实大小和页宽
巩固长度的记实要优于可变长度的记实，因为 DB2 代码专门为措置处罚巩固长度的记实中断优化。如果记实是巩固长度的，那么就无需将其从存储它的初始页面转移到其他地方。而关于可变长度的记实，其长度可以会变得不再得目下当今始页，是以必须将其转移到其他页。之后，每当必要接见该记实时，就必须发作分外的页援用。DB2 UDB V8 中的一种新特征许可在必要的时候修正（ALTER）某一列的宽度，这样一来，纵然您不克不及确定未来数据长度的增长状况，也不再必要创立可变长度的记实。
一个页中所能存放的记实的数目也是值得思量的一个方面。DB2 为页宽供应了良多选项（4 KB、8 KB、16 KB 和 32 KB）。一路头的时候，可以选择默许选项（4 KB），如果行的长度很小，可能对数据的接见根底上是随机的，则更应该选择这一选项。不外，在有些状况下，则必要思量运用更大的页宽。如果一个表中各行的长度要大于 4 KB，那么就必要运用更大的页宽，因为 DB2 不支撑 跨页（spanned）记实。
还有一些状况下，关于一条巩固长度的记实，其总长度可以正好比 4 KB 的一半大一点点，这时一个页只能包容一笔记实。关于正好比页宽的 1/3、1/4 大一点点的记实，气候也是相似的。这种打算不单浪掷 DASD 空间，而且，关于良多 DB2 操作，还必要花消更多的资源。是以，关于这一类的记实，应该思量运用更大的页宽，这样浪掷的空间绝对要少一些。
其他可以的页宽是 8 KB、16 KB 和 32 KB。页宽不是在 CREATE TABLE 语句中间接指定的。相反，表的页宽是由相应的缓冲池的页宽来确定的，这个缓冲池也等于为包罗该表的表空间所指定的缓冲池。要认识更多细节，请参考 DB2 SQL Reference手册中的 CREATE TABLESPACE 语句。
反范例化方面的思量
逻辑数据模子是数据的 志向蓝图。物理数据模子才是对数据的 现实的完成。范例化只存眷数据的意义，而没有思量关于接见数据的把持程序的功能需求。完全范例化的数据库打算在功能方面要遭到质疑。
这种功能问题的最稀有的例子是 毗邻（join）操作。常常，范例化进程最终将干系的信息放入差别的表中。于是把持程序必要从多个这样的表中接见数据。关系数据库为 SQL 语句供应了从一个以上的表中接见信息的才略，这是经由过程 毗邻多个表来完成的。毗邻操作可以要花消少量的资源和时分，这取决于表的数目以及这些表各自的长度。
像 I/T 中的良多事变一样， 这里也可以思量一种权衡的体例。关于具有凡是被乞请的列的多个表，一种是复制此中的数据，一种是实行表毗邻，两者谁的本钱更高呢？在逻辑数据库打算进程中，您可以毫无保留地范例化数据模子，然后再加入必定水平的反范例化，作为潜伏的功能调优的一种选择。如果您简直诡计反范例化，那么必定要为此建造无缺文档：较具体地描写您所采纳的反范例化步调面前的缘由。
打算大型的表
接见极端大的 DB2 表时，相应地要花消良多的资源：CPU、内存 和 I/O。在打算大型表的时候，为了进步功能，用户可以做的最严重的两件事是：
1、完身分区。
2、创立有效的索引。
上面将更具体地评论斗嘴这两个话题。
运用分段的或分区的表空间
如果数据包罗 LOB，那么用户就必须创立 LOB 表空间。关于非 LOB 数据，普通必要在分区表空间和分段表空间之间中断选择，这很洪水平上取决于要存储的数据量，在必定长度上也取决于干系把持程序所需的数据接见范例。伟大表空间已经很少被举荐了。
上面列出了分段表空间干系于伟大表空间的一些功能上风：
关于包罗多个表的表空间，当 DB2 失失用于某一个表的锁时，这个锁不会影响对其他表的段的接见。
当 DB2 扫描一个表时，只是接见与那个表干系的段。而且，空段中的页不会被提取。
如果一个表被删除，在实行 COMMIT 之际，它的段就立即可感受其他表所用，而不必要实行 REORG 适用程序。
如果一个表中的一切行都被删除（即 mass delete），则在实行 COMMIT 之际，该表一切的段就立即可感受其他表所用，而不必要实行 REORG 适用程序。
mass delete 实行起来要高效得多，而且要写的日记信息也更少一些。
COPY 适用程序不会复制那些由 mass delete 操作或删除（DROP）一个表所形成的空页。
当表达到必定大小时，经由过程完身分区表空间可以进步易治理性和功能。如果预见到这样的增长，那么明智的做法是，在打算和创立表空间时将其界说为分区的。上面列出了分区表空间可以供应的一些潜伏的上风：
并行性：您可以运用 DB2 UDB 现在所运用的三种并行体例。查询并行（多条 I/O 途径）是在 DB2 V3 中引入的。Sysplex 查询并行（一个 DB2 数据共享组中的多用户和多使命）是在 DB2 UDB V5 中引入的。到现在，DB2 已失失极大的发展，并大大地加强了那些措置处罚分区表空间的 DB2 把持程序的并行措置处罚才略。经由过程添加必定的 CPU 时分，可以大大增加这些查询所需的时分。
对部分数据中断操作： 分区表空间许可 DB2 适用程序一次措置处罚一个分区的数据，这样其他使命或把持程序就可以并发地对其他分区中断接见。依据相似的体例，您可以将 mass UPDATE、DELETE 或 INSERT 操作拆成多个差别的使命。除了添加可用性以外，这种妙技还可感受增加完成这种 DB2 事变所需的时分供应潜力。
对频仍接见的数据有更快的接见速度： 如果分区索引可以将接见更频仍的行与表中其他的行分开绝间隔绝分手来，那么就可以将这些数据放入到它们公用的分区中，并运用更高速的 DASD 配备。
常常，表越大，就越有理由将其创立为分区的表。但无意辰为较小的表创立分区表空间也很有利。当将 查找（lookup）表与其他较大的分区的表相毗邻时，经由过程将查找表也中断分区，可以最大化并行度。
如果在毗邻谓词中运用分区键（partitioning key），最初还有一点思量必要顾及。必要按分区键中断毗邻的表应该有相同数目的分区，而且应该在相同的值上 断开。
数据紧缩
DB2 供应了紧缩一个表空间或分区中的数据的才略。这是经由过程在 CREATE TABLESPACE 语句中指定 COMPRESS YES 选项，然后对表空间实行 LOAD 或 REORG 适用程序来完成的。经由过程用较短的字符串改换凡是泛起的长字符串，可以紧缩数据。这时会树立一个字典，此中包罗了映射原始的长字符串与它们的改换值的信息。
在数据被存储之前紧缩数据，以及在从内部存储配备读出数据时将数据解压，这都必要运用必定的 CPU 资源。可是，数据紧缩也可感受功能带来长处，因为可以在更少的空间（包罗 DASD 紧张冲池中的空间）中存储更多的数据，与未紧缩的数据相比，这样可以增加同步读，增加 I/O 等。
在决意可否紧缩一个表空间或分区时，要思量上面一些事变：
行的长度： 行的长度越大（尤其是它靠近页宽时），紧缩的固守就越低。在 DB2 中，行不克不及跨页，您可以无法完成足够的紧缩来使一页可以包容多行。
表的长度： 关于更大的表空间，紧缩更为有效。关于极端小的表，紧缩字典的大小（8 KB 到 64 KB）有可以会抵消散落经由过程紧缩所浪掷出来的空间。
数据中的形式： 关于特定的表空间或分区，数据中反复泛起的形式的泛起频率将决意紧缩的结果。有少量反复字符串的数据有伟大的紧缩潜力。
对紧缩的估量： DB2 供应了一个独立的适用程序 DSN1COMP，经由过程实行该适用程序可以判定紧缩数据的结果。要认识关于运转该适用程序的更多信息，请参考 DB2 Utilities Guide and Reference 手册。
措置处罚本钱： 紧缩息争压数据时，要花消必定的 CPU 资源。与运用 DB2 软件仿照程序相比，运用 IBM 的同步数据紧缩硬件可以大大增加所花消的 CPU 资源（当 DB2 启动时，它将判定硬件紧缩特征可否可用）。
更好的字典： 当运用 LOAD 适用程序来树立紧缩字典时，DB2 运用所装载的前 n 行（此中 n 取决于数据的紧缩水平）来决意字典的内容。REORG 运用一种抽样妙技来树立字典。它不单运用所装载的前 n 行，而且还会对该适用程序实行期间剩下的 UNLOAD 阶段中的行中断抽样。是以，REORG 凡是可以发作更能代表整个表空间或分区中的数据的字典。
如果您的状况可以从紧缩中失失长处，常常我们提议紧缩那些 DB2 表空间和分区，因为因为更少空间包容更少数据所带来的功能上风简直总是大于紧缩息争压数据时所需的 CPU 资源花消。
装载大型的表
当措置处罚少量的数据时，一路头将数据装载到表中时可以会碰到功能问题。为了在装载进程中完成并行性，可以手动地创立多个 LOAD 使命，每个分区对应一个使命，可能，也可以在单个 LOAD 适用程序中装载多个分区。每个分区都展开在 I/O 子体系上，从而更易于达到最佳的并行度。
为了失失最佳功能，在 LOAD 语句中指定 SORTKEYS 参数也很严重。这将指示 DB2 将索引键传递给内存中的排序程序，而不是再次将这些键写到 DASD 上的排序事变文件中，然后从中读取这些键。SORTKEYS 还许可装载和排序之间的堆叠，因为排序是作为一个零丁的使命运转的。
上面给出了关于装载大型表的其他提议：
1、一次只 LOAD 一个表。
2、如果可以，为那些估量将历时最长的使命供应较高的优先级。
3、将事变分布在 sysplex 上。
将辅佐索引拆分红数块，以完成并行性（请参阅上面题为 PIECESIZE 的评论斗嘴）。
在起头装载数据时，指定 LOG NO （用以防御日记记实，以及浪掷日记记实所花消的少量资源），然后在成功装载数据之后运转一个映像拷贝。
空余空间方面的思量
分配空余空间的严重目的是使数据行的物理次第与群集索引不同，以增加频仍重组数据的必要。此外，对行的更好的群集会使读接见的速度更快，行拔出的速度也更快。可是，过多地分配空余空间可以会发作浪掷的 DASD 空间，招致每次 I/O 只能传输更少的数据，缓冲池的应用固守更低，而且要扫描更多的页。
表空间和索引中空余空间的分配是由 CREATE 或 ALTER TABLESPACE 以及 CREATE 或 ALTER INDEX 语句的 PCTFREE 和 FREEPAGE 选项确定的。
PCTFREE 讲述 DB2 在装载或重组数据时，表空间或索引中的每个页要留出若干好多百分比的空余空间。如果没有足够的空余空间来依据 适当的次第（也等于按群集次第）编写行或索引，那么 DB2 就必须将多出的数据放到另一个页上。当越来越多的记实被乱序存放时，功能就会泛起问题。
FREEPAGE 讲述 DB2 在装载或重组数据时，应该过多久就分配一整页的空余空间。比如，如果指定了 FREEPAGE 5，那么 DB2 将在用数据填充了 5 个页之后分配一页的空余空间。如果表行大于页宽的一半，则应该运用 FREEPAGE，因为在那样的状况下不克不及在一页上再 INSERT 一行。
可否界说带空余空间的表空间，以及分配若干好多的空余空间，这很洪水平上取决于表空间中表的 INSERT 特征（其次是 DELETE 勾当）。换句话说，这取决于将行添加到表中的频率，以及将行添加到表的什么地方。上面有 4 种类别：
只读表： 如果关于一个表没有使命更新勾当，那么可以将其界说为没有空余空间。而且，也没有任何必要去运转 REORG 适用程序。
随机拔出： 关于已经有良多行、而且 INSERT 勾当的级别很低，那么一路头可以运用默许的 PCTFREE（关于表空间，该值是 5，关于索引，该值是 10）。然后运用 RUNSTATS 监控数据丢失序的水平，再思量您企望运转 REORG 的频率，对 PCTFREE 中断必要的上下调整排解。关于 INSERT 勾当级别很高的表，可以必要运用大于默许值的 PCTFREE。关于起头为空可能只包罗很少行的表（比如在新数据库的铺排期间），可以必要指定一个较高的 PCTFREE，并时时地运转一下 REORG，直到这个表被填充好为止。
在表的末端拔出： 如果一个表中的行的长度不会增长，那么就无需分配空余空间，因为这些行是在表的末端拔出的。因为这些行是依据物理的群集次第来写的，是以不必要运转 REORG。可是，如果一个表包罗可更新的 VARCHAR 列，可能该表被紧缩，那么有可以行的长度会增长，从而招致某一行被转移到其他页上。您可以经由过程对表空间实行 RUNSTATS，然后搜寻 DB2 编目表 SYSIBM.SYSTABLEPART 的 NEARINDREF 和 FARINDREF 这两列来判定上述状况。如果表变得缺乏机关，那么为表空间指定一个 PCTFREE，并连续用 RUNSTATS 监控 地位不当（mislocated）的行。依据以后的数据以及您所查询接见到的趋势，对 REORG 的频率和 PCTFREE 的数字中断相应的调整排解。经由过程在 REORG TABLESPACE 中指定 INDREFLIMIT 和 REPORTONLY 选项，可以监控被更新的 DB2 表中地位不当的行的数目，以及隔多远会泛起这样的行。
在 热门（hot spot）中拔出 ：在这种状况下，表上的拔出勾当很频仍，而且集合在某一个地位（或几个地位），而不是在表的末端中断拔出。这一类状况可以是最难于措置处罚的。可以实行添加 PCTFREE 的值。如果拔出勾当勾留在主段（home segment）中，而且拔出的行不是很长，那么可以将数行存储在相同的页中。在此状况下，另一种可以思量的方案是运用 FREEPAGE。这时有必要慎密监控表变得无机关的速度，这样就可以在功能急剧下降之前运转 REORG。
索引打算方面的思量
索引也是一种 DB2 对象（一个零丁的 VSAM 数据集），它由一组排好序的键组成，这些键是从相应表中的一个列或多个列抽取出来的。良多 DB2 专门风称，只无为表空间树立适当的索引，才是使得接见该表空间中 DB2 数据的把持程序的功能达到最佳、最有效的结果。数年前，在 I/T 中 DASD 的本钱和空间是更严重的思量要素。跟着妙技的发展，经由过程添加更多的索引（或添加列到已有的索引中）来增加 I/O，以及由此花消的分外磁盘空间，这几年两者之间的权衡已经变得越来越有吸引力。索引所带来的严重功能长处是：
1、供应指向表中被乞请的数据行的间接指针。
2、如果结果集要求的次第与索引不同，则可以消除排序。
3、如果被乞请的列都包罗在索引项中，则可以防御不得不读数据行的状况。
分区索引
在 DB2 UDB V7 中创立分区的表空间时，DB2 依据 CREATE INDEX 语句的 PART 子句将数据分别到几个分区上。那样的索引就成为所谓的分区索引，而这种分区的体例就被称为 索引控制的分区（index-controlled partitioning）。关于分区索引，提议选择不大可以转变的键列。如果对那些列中断更新，则可以招致一行从一个分区转移到另一个分区，从而降低了功能。
DB2 V8 一个严重的特征是 表控制的分区（table-controlled partitioning）。这时，当创立分区的表时，分区的界限由 CREATE TABLE 语句决意，而不是由 CREATE INDEX 语句决意。关于索引控制的分区体例，分区的表、分区索引和群集这几个不雅点之间有点牵扯不清。而在表控制的分区体例中，这三个不雅点是各自独立的。这种添加的无邪性使您可以思量更多潜伏的打算方案，是以也添加了进步 DB2 数据库及其把持程序功能的机会。
何时树立索引
CREATE INDEX 语句运用户可以立即树立索引，可能将索引的树立推延到便当的时候。如果立即树立索引，则必要扫描表空间，这样要破费对照多的时分。经由过程指定 DEFER，则可以推延索引的创立。
只需有可以，应该在初次装载一个表之前创立其一切索引，因为 LOAD 适用程序树立索引的固守比 CREATE INDEX 进程要高。如果必要在一个已有的（而且被填充的）表上创立一个索引，那么可以运用 DEFER 子句。然后可以在晚些时候运用 REBUILD INDEX 适用程序，这个适用程序与 LOAD 适用程序一样，是更为有效的填充索引的体例。
PIECESIZE
DB2 UDB V5 中引入了一个新特征，这种特征使您可以将一个非分区索引（non-partitioning index，NPI）拆成 数块，然后控制将组成索引空间的多个数据集的大小。经由过程运用这些小块，可以使 NPI 的索引页漫步到多个数据集合。
经由过程在 CREATE 或 ALTER INDEX 语句中指定关键字 PIECESIZE，可以确定各块的大小。PIECESIZE 的值必须是 2 的幂，其大小可以介于 256 KB 到 64 GB 之间。关于通例表空间，PIECESIZE 的默许值是 2 GB，关于 LARGE 表空间，默许值是 4 GB。如果 NPI 极有可以明显增长，那么应选择一个更大的值。在为主空间和辅佐空间（CREATE INDEX 语句的 PRIQTY 和 SECQTY 选项）的分配确定值时，也应该留心 PIECESIZE 的值。
经由过程运用这个选项，可以促进并行性，从而进步 NPI 的扫描功能。另一个长处是可以增加在读或更新的措置处罚进程中对 I/O 的争用。经由过程指定一个较小的 PIECESIZE，可以创立更多的块，从而对块的铺排有更多的控制。将这些块放在差别的 I/O 途径中，可以增加接见 NPI 所需的 SQL 操作的争用。
志向的索引
经由过程搜寻把持程序中的 SQL 语句，可以树立一种想象起来很好的索引。
首先，在索引中包罗 WHERE 子句中的一切列，这样，就可以运用索引构成的屏蔽来拒绝结果集合分歧格的行。将这些列放在索引的起头部分。这样一来，当对 SQL 语句中断 EXPLAIN 时，就可以发作最大的 MATCHCOLS 值。
接上去，确保索引中这些列有适当的次第（依据 ORDER BY 子句），这样可以防御排序。在中断 EXPLAIN 时，经由过程搜寻 PLAN_TABLE 中一切差别的 SORT* 列，便可以确认这一点。
最初，如果可以的话，将 SELECT 中一切的列包罗到索引当中，这样就不必要接见表中的行。这样的索引项可以供应一切被乞请的数据。这在 EXPLAIN 中就默示为 INDEXONLY = Y。
在良多状况下，完成这一志向的代价太高，也不确切际，乃至是不可以的。关于一个索引中可以包罗的列数，以及整个索引项的长度，都有架构上的限制（固然这些限制已思量到相当大的索引项长度和无邪性）。而且，也要思量索引维护的本钱。固然树发奋向化的索引可以明显进步查询功能，可是每当对 DB2 数据库实行 SQL 写操作（INSERT、UPDATE 或 DELETE）时，上述志向化的索引城市有负面的影响。是以，您凡是可以选择完成只包罗在 WHERE 和 ORDER BY 子句中援用到的列的索引。
并行措置处罚方面的思量
这些年，DB2 经由过程完成各种并行措置处罚的体例，已经大猛进步了接见数据的功能。为了进步数据密集型只读查询的功能，DB2 V3 引入了查询 I/O 并行。在这种并行中，DB2 充分应用分区表空间促进的可用 I/O 带宽。经由过程这种体例，DB2 可感受单个 I/O 乞请启动多个并发的 I/O 乞请，并在多个数据分区上实行并行 I/O 措置处罚。这常常可以明显增加 I/O bound 查询所需的时分，而代价只是略微添加的 CPU 时分。
DB2 V4 引入了另一种并行妙技，这种妙技称作查询 CP 并行。这种体例将并行措置处罚扩展到进程密集型（process-intensive）查询中来。经由过程这种体例，一条查询可以使 DB2 天生多个使命，这些使命被并行地实行，以接见数据。分区表空间最能体现这种并行所带来的功能进步。
DB2 UDB V5 引入了 sysplex 查询并行，进一步扩展了并行措置处罚。CP 并行可以在 DB2 子体系中为一条查询运用多个使命，而 sysplex 查询并行这种体例使一个 DB2 数据共享组中的一切成员可以一同措置处罚一个查询。关于那些严重是只读体例的 I/O 密集型和措置处罚器密集型查询，都可以从这种并行中失失长处。
支撑并行接见
DB2 状况中对并行的支撑有一个度的问题。首先，在 DB2 子体系级，并行接见是在安装面板 DSNTIP4 上控制的。DSNTIP4 上的 MAX DEGREE 选项决意了最大并行度（并行使命的最大数目）。默许值是 0，这意味着关于 DB2 可以调用的并行度没有下限。我提议您先估量 z/OS 状况中的假造存储才略和范围性，这样 DB2 就不至于创立多于假造存储所能措置处罚的并行使命。
您可以经由过程 BIND PLAN 和 BIND PACKAGE 命令的 DEGREE 选项来控制 DB2 可否应用并行措置处罚。若指定 DEGREE(1)，默示抑制并行措置处罚，若指定 DEGREE(ANY)，则默示支撑并行措置处罚。为失失更大的无邪性，静态 SQL 许可经由过程 SET CURRENT DEGREE 语句在一个方案或包中变动这个选项，该语句可以控制公用存放器中的值。
当一个方案或包与 DEGREE(ANY) 捆绑在一同，可能 CURRENT DEGREE 存放器被设为 ANY 时，DB2 优化器将思量关于最有效的次第方案，并行可否可行。如果并行不可行，那么就选择次好的次第方案。
限制分区扫描
限制分区扫描许可 DB2 将数据扫描限制在一个分区表空间中。依据 SQL 谓词中的值，DB2 可以判定可以包罗 SQL 语句所乞请的表行的最低分区和最高分区，然后将数据扫描限制在这一范围内的分区中。为了运用这种妙技，SQL 必须供应分区索引的第一个键列上的一个谓词。
并行方面的提议
为了进一步促进并行措置处罚所能带来的功能进步，上面列出了一些必要思量的事变：
1、尽可以均匀地对表空间分区，因为数据不整齐会对并行度发作影响。普通来说，DB2 依据最大物理分区的大小将表空间分红逻辑上的几块。
2、为 DB2 把持程序的措置处罚分配尽可以多的中心措置处罚器（central processor，CP），以及尽可以多的 I/O 配备和途径。
3、关于 I/O 密集型查询，应确保分区的数目与可以接见该表空间的 I/O 途径的数目不同。
4、关于措置处罚器密集型查询，应确保分区的数目等于将被分配用来在数据共享组上措置处罚查询的 CP 的数目。
将用于表空间和索引的分区放在零丁的 DASD 卷中，而且，如果可以的话，要隔开控制单位，以增加 I/O 争用。
5、定时实行 RUNSTATS 适用程序，以失失分区级的统计信息。
6、监控假造缓冲池的阈值和运用状况，确保供应了足够的缓冲池空间来最大化并行度。
缓冲池方面的思量
缓冲池的严重性
良多专家将数据库缓冲池看作 DB2 状况中影响功能的最关键的资源。良多 DB2 的架商洽打算，其根底思惟都是尽可以地防御物理 I/O。
DB2 缓冲池由数个 插槽（slot）的陆续的内存组成。数据和索引页被从 DASD 中读出之后，便进入这些插槽，并留在此中，直到 DB2 缓冲区经管器确定那些插槽要用于其他数据。把持程序所乞请的数据呈现在内存中（而不是外貌的 DASD 上）的概率越大，总体功能就越好。现实上，这里的数据被反复运用，是以增加了把持程序对 I/O 的必要。
可否开释一个缓冲池槽，这是依据迩来被运用（LRU）准绳来决意的。DB2 维护两个 LRU 列表，一个用于被随机接见的页，另一个用于被次第接见的页。这样可以防御大范围的表扫描完全支配缓冲池，并恶劣地影响随机操作。经由过程运用差别的阈值，DB2 供应了改进缓冲池功能的无邪性。在 DB2 SQL Reference 手册的第 2.7.4 节中对这些阈值中断了较为具体的评论斗嘴。
为缓冲池设置适当的大小
缓冲池大小的指定要取决于可用存储（包罗中心存储和扩展存储）的容量。我提议首先分解缓冲池的分配，然后逐步添加缓冲池的大小，直到经由过程添加分配的空间已无法添加更多的吞吐量，可能直到 MVS 换页率已难于担负负责为止。为完成这一点，要使 DASD I/O 的数目连续下降，并不停添加 VPSIZE，直到换页的本钱超出跨越了经由过程增加 I/O 所带来的长处为止。
早些时候，GETPAGES 的数目被以为可以是对 DB2 正在运转的事变量的最好襟怀。缓冲池的目的是增加 I/O（异步读常常表达必要中断预取，从功能角度来看，这样做常常是值得的。另一方面，同步读凡是必要对 DASD 中断随机 I/O，因为被乞请的页不在缓冲池中）。管帐报表显示对应于每个缓冲池的 GETPAGES 和同步读的数目。一个被普遍担负负责的 ROT 声称，如果 GETPAGES 对同步读的比率小于 10:1，那么应该估量对更大缓冲池的必要。
多缓冲池设置
如果操作体系许可为 DB2 缓冲池分配相当大的内存，那么运用多缓冲池的设置很可以可以进步特定把持程序或数据库的功能。可是，必要清楚的是，如有了多个缓冲池，那么对这些缓冲池运用固守的监控就变得更加严重。
上面给出了关于分配多个缓冲池的普通提议：
1、将表空间与和它们干系的索引分放赴任别的缓冲池中，以增加索引 I/O。
2、将有差别数据接见形式的数据不同放赴任别的缓冲池中。批措置处罚和查询把持程序常常要中断少量的次第措置处罚，而用于 OLTP 的数据接见常常更具有随机性。这为应用各种阈值措置处罚缓冲池中某些范例的数据接见供应了一种体例。
3、为独立的把持程序供应一个零丁的缓冲池。这就为慎密监控把持程序的功能问题或测试新的把持程序供应了一种体例。
4、如果排序的功能在您的状况中很严重，那么必要为事变文件创立一个零丁的缓冲池。
5、关于绝对较小但更新频仍的表，经由过程一个足够大的零丁的缓冲池，也答应以同时增加读和写的 I/O。
6、为只读表（小的援用表）供应零丁的缓冲池可以进步功能。
截止语
思量周详的数据库打算可以供应伟大的功能收益，可是这必须在把持程序开辟进程的晚期便起头入手。从晚期的 DB2 起头，明智的开辟人员就已经运用了前面提到的良多准绳，这些准绳直到现在也仍然确立。可是，DB2 结果的加强、其他范围中硬件和软件妙技的转变将影响以后和未来的把持程序，知道这一点至关严重。当数据库功能成为开辟进程中的焦点时，您的数据库打算使得为 DB2 把持程序供应最佳功能有了更大的可以性。
来自: 新客网(www.xker.com) 详文参考：http://www.xker.com/page/e2007/1012/35911.html
版权声明：
原创作品，许可转载，转载时请务必以超链接体例标明文章 原始因由 、作者信息和本声明。不然将追查功令责任。