|
体系架构的限制 DPF已经突破了一些DB2的体系架构的限制。例如，在DB2中表的最大容量是64GB以4KB的页面大小（虽然32KB的页面大小可以支持到512GB）。DB2中表和表空间大小限制是建立在每个分区的基础上。因此，在多个分区中对一个数据库进行分区可以让你通过你所在系统环境的分区数量的系数来增加表的最大容量。例如，把一个数据库分区成横跨四个结点系统就可以支持最大（以32KB页面大小） 的2408 GB的表。
在一个没有分区的环境中内存也会成为一个瓶颈。32 位版本的DB2 ESE 限制了每台DB2服务器共享内存。（这个限制将随运行DB2的操作系统的不同而不同，同时一些供应商也提供一些基本内存模的扩展。）共享内存支持内存密集型的数据库资源譬如缓冲池、高速缓冲区和堆。在一个DPF的环境里，每一个数据库分区管理和拥有它自己的资源，因此您可以通过分区你的数据库来克服这些限制。你甚至可以在大型的SMP箱中区运行逻辑数据库分区，充分利用在一台单独SMP 服务器中的大内存资源。
数据装载 在DB2 ESE v8.1中，如果对目标表分区，那么装载工具会自动并行的分离和装载数据。它使用智能的缺省值去分离和装载数据；它也可以被优化用于一些环境。
在一个分区数据库中，您可以使用装载工具同时向相应的数据库分区装载数据。图4显示装载工具是使用专用的媒体阅读器将数据分离和装载到表中（并行状态下）。装载工具对于装载时间提供了类似于线性的可扩展性。
图4 利用DPF加速表的装载
![""](/Article/UploadFiles/200904/2009042223220960.gif")
DB2 v8的装载工具比以前版本的装载工具更快、更加可利用。如果你在DB2 v8中执行一个装载的操作，DB2不再是将被装载的那个表所在的表空间所有表锁定在它之中（与DB2 v7的情况一样）。现在甚至还有一种被称之为在线装载，它在装载的时候允许对表进行读操作。考虑对于以前DB2版本的，仍然支持autoloader脚本。
是否有可能装载时间重要但查询的性能并不重要的？这两个问题其实并不互相排斥；可是，在许多商业流程中装载时间是一个重要因素。实际上，这有时还是决定因素。如果是在那种情况下，那么使用DPF是相当有用的。 例如，电信公司（telco）的欺诈侦查单元在一个指定的时间间隔中装载大量的数据以求快速准确的监测出呼叫模式下反常现象有可能是潜在欺诈信号。数据库必须迅速发现这些反常现象，因此数据需要迅速和频繁地进入数据仓库。在电信公司，这个过程每小时被重复甚至在更大的公司每十五分钟就要重复。 这些需求要求一个可扩展并且高效率的基础设施来运行类似查询的工作。
维护 数据库分区可以明显的加速维护。将数据库分散于多台数据库分区服务器上可以加速数据库的维护，因为每一项操作都是运行在分区管理的数据子集上的。
虽然在DB2中索引创建是并行的，你可以通过对数据库进行分区来进一步减少总的时间。在所有分区上利用小数据集并行创建索引是允许并行的。 记住，DB2 抽象了表面现象下的运行；多个表可以表现成一个表的形式。
RUNSTATS工具也可以从分成中受益。这个工具更新关于表的物理特性和它相关的索引统计数据。在决定数据访问路径时优化器使用这些统计数据。 RUNSTATS是CPU密集的，需要数据的排序和聚合。你可以使用DPF的选项来减少该工具所占用的时间。使用DPF，RUNSTATS检查在一个数据库分区上的数据而不是整个表。在DB2 v8中，RUNSTATS取样选项可以进一步减少工具的的执行时间（不管有或没有DPF）。
同样，将数据散布于多个分区有助于表重组（REORG），它是I/O 密集的并且需要随机抓取（特别是在离线状态下）。每个数据库分区可以重组它拥有的数据同时分配为每一个处理器更多驱动来重组数据。这些操作也可以并行操作以缩短需要的整体时间。在DB2 v8，你可以在各个分区或者在数据库分区的子集上来执行REORG。你也可以停止、暂停、检查状态和恢复。
这些例子仅仅是一些能从DPF得到好处的维护操作。
并行插入/删除 在数据库分区中只有SQL语句是并行操作。如果数据库环境使用SQL来进行大容量的插入和删除处理，通过在数据库分区上的并行处理插入和删除语句，多数据库分区可以增加事务处理的吞吐量。这样的好处还可以应用于从一张表中选择数据并且插入另外一张表的技术。
滚动窗口需求 当查询窗口必须保持在打开状态的时候，分区通常会被用于满足滚动窗口的需求（每天插入和删除行）。为每一个处理器定义一个数据库分区将增加新数据插入表中的吞吐量。在数据库分区中并发执行插入或删除数据流很有道理（例如使用一个关键范围）。多数据库分区使为存储大量插入和删除操作的数据库的locklist分配足够的内存成为可能。
数据库分区同时也允许横跨数据库分区并行进行索引维护操作（在插入和删除时）
备份与恢复 多个数据库服务器之间的分区数据库可以才很大程度上减少备份数据库所使用的备份总时间。根据你的环境，在决定是否对数据库进行分区时这也许是一种重要决定因素。
DB2通过为每一个表空间分配一个独立的进程或者线程来进行并行备份和恢复。 在一个分区的备份中，每一个分区被单独的进行备份。并行执行这些备份操作将会缩短备份整个数据库所耗费的时间。
一个分区数据库环境也可以加速前滚和重新开始（崩溃）恢复。用DPF，一些必须前滚的日志具体到了每一个数据库分区；数据库分区服务器间平衡的分离和征服战略（divide-and-conquer strategy）加速了这个过程。同时如果一个特定的数据库分区不需要前滚的话，那么它将在崩溃恢复中被忽略。
记录一些需要考虑的事情 在一个高度活跃的系统中，数据库日志的性能很可能制约系统的能力。在一个分区的数据库环境，每个分区都有它自己的一组日志。当系统需要执行高强度的插入、更新或者删除活动时，多个数据库分区可能改善性能，因为日志被并行的写入每个分区中，并且在每个分区较少的记录日志。
做出选择
分区还是不分区? 从根本上来讲，DB2就是DB2。不管你没有对你的数据库进行分区对于界面、功能、工具和你使用的技能都没有任何的影响。这事实上是依靠你的应用程序和环境。使用我们建议的标准，你可以发现问题的答案。
关于作者
Dwaine R. Snow 是DB2 UDB 分区数据库的产品经理，做为加拿大IBM的DB2UDB的资讯顾问工作多年，提供数据库和应用程序策划和设计、项目策划和实施、复杂在线事务处理和决策支持系统设计、性能调整以及系统集成的现场指导。你可以通过mrdb2@yahoo.com与他联系
Paul C. Zikopoulos在IBM数据管理软件小组有七年的DB2工作经验并且写了许多文章。他参与写作了几本书，包括DB2: The Complete Reference （Osborne McGraw-Hill, 2002），和 DB2 Fundamentals Certification for Dummies（Wiley, 2002）。Paul是DB2认证高级技术专家（DRDA和Cluster/EEE领域）和DB2认证解决方案专家（商业智能和数据库管理领域）。你可以通过paulz_ibm@msn.com 与他联系。
上一页 [1] [2]
没有相关教程
| 
注：本站部分文章源于互联网，版权归原作者所有！如有侵权，请原作者与本站联系，本站将立即删除！ 本站文章除特别注明外均可转载，但需注明出处！ [MinTao学以致用网] 
