神马文学网分区的威力(翻译)
来源：百度文库 编辑：神马文学网 时间：2024/04/25 00:34:09
[日期：2005-07-08]来源：CSDN 作者：[字体：大中小]
分区的威力
Dwaine R. Snow and Paul C. Zikopoulos 著
笑熬浆糊 译
原文出处：《DB2 Magazine》 Quarter 2, 2003 · Vol. 8, Issue 2
英文原文（由于文章翻译未经授权，请在转载时保留原文链接）
人们对分区有很多的误解。多伦多实验室的专家们对这个有用的功能进行了正名。
DB2 数据库分区的往往是存在很多误区。对于Linux、Unix以及Windows平台上的DB2 UDB 8.1 版本所做的变动有助于简化DB2 分区。我们将解释这些变动，澄清一些分区的神话，以及说明您应该考虑分区的时机和理由。
DB2 UDB 8.1 For Linux \Unix\Windows将DB2产品家族中以前称之为DB2 UDB 企业版和企业扩展版的产品整合成为一个单独的产品中。这个 新的DB2 企业服务器版(ESE) 包含了数据库分区的功能(从前是作为单独提供的产品) ，作为一个计费的项目，现在被称为数据库分区功能(注：直译——database partitioning feature DPF)。当DB2的用户们发现自己需要开始分区时，那么他们可以马上开始而不需要其他一些额外的代码—— 他们仅仅需要DPF的许可协议。
DPF的真相
关于数据库分区的神话在DB2中随处可见（参见表1）。对于分区基础的快速概揽将帮助你区别真伪并且做出适当的分区决策。
表1 : 围绕DB2 数据分区的神话和事实
无论是否有DPF，DB2都支持并行查询处理。图1展示了安装在一个4路SMP（对称多处理）服务器DB2 ESE。在这个假设中。一个独立的查询可以自动使用这个服务器上所有的CPU和物理磁盘。对于依靠需要数据的子集进行处理的子代理提供分区内部的并行机制。DB2 使用I/O的预存取把从磁盘发送的数据反馈到这些子代理当中。这种并行机制对用户、应用程序以及DBA都是透明可见的。
图 1：不带有DPF的DB2 ESE的并行机制
DPF选项增加了在一组机器中或逻辑上位于某个SMP服务器中的数据库进行分区的能力。依靠DPF，一幅数据库图像可以跨越多台机器（存储），并且它对于用户和应用程序来说仍然还是一幅完整数据库图像。
考虑四路的SMP服务器组的情况。 (在这篇文章里，我们将使用术语数据库分区组而不是集群，因为集群通常是指高可靠性的故障转移配置或者用于衡量系统的分区组。) 使用DPF，在图1中所讨论到的并行操作可以扩展到横跨多台SMP 机器(参见图2)。这样的好处就是有一个双并行操作。 你可以跨越多台机器或者逻辑数据库分区来平衡这些并行操作。这样的处理被称之为分区之间的并行机制。
图2 : 横跨多台机器的使用DPF的并行机制
分区之间的并行机制通常在多台服务器执行，但越来越多的用户现在都一些大型的SMP箱中进行该操作(参见图3)。
图3 : 单独的SMP服务器中的拥有DPF的DB2 ESE.
什么时候（为什么）需要进行分区
那么，你应该去做分区吗？在以下的情况下你应该考虑分区：
· 你的服务器拥有大量可用内存。即使DB2 v8有64位支持，多分区已经被证明可以提供比单独的SMP 并行机制更多的内存的有效使用和更多的线性可扩展性。
· 系统将包括多台服务器，或有超过6 到12 个的CPU。
· 数据库工具的操作速度是你的业务操作的关键所在。
· 为装载数据或提取，转换，负荷处理操作提供的批处理窗口数量是有限的。
· 数据仓库的滚动窗口数据更新的需求使并行SQL处理和其他日志空间成为根本。
分区在这些情况下显得特别有意义。 但是分区所提供的一些其它的好处使得它变得更有魅力。这些好处有：
查询的可扩展性 使用DPF的一个最明显的理由就是它可以增加查询工作量和insert, update，和 delete 操作的性能。把一个单独的大型数据库分区为很多定数量的较小的数据库以加速这些操作因为每一个数据库分区都拥有它们自己的一套数据。
比如说你想要扫描一个包含100 million行数据的表。对于一个单独的数据库分区而言，这次扫瞄会要求独立的数据库管理器去搜索所有100 million个纪录。如果你把你的数据库系统分区为使用50 台数据库分区服务器并且将这100 million条记录均匀的分配到他们之间的话，那么每一个数据库分区上的数据库管理器仅仅需要扫描2 million行。如果每一个扫描都在同一个时间并且以相同的速度执行的话，那么扫瞄完成的时间大约是前者的2%。
DPF提供类似于线性可扩展性和使用工具来完成基础设施构建。这样它可以根据需要增加容量而不需要新技术或者单独安装
DB2 优化器是基于并行机制。换句话说，它保留了如何在系统中对于底层数据进行分区的信息。使用这些信息，优化器考虑不同的查询执行策略和一个低成本的选择。当在比较不同的执行策略时，它会考虑到不同的操作的内在的并行机制和在数据库分区之间传递消息的开销。
在大量数据或者处理器和分区的数量增加的时候，DB2可提供类似线性的可扩展性。但是，分区可能提供的最大好处的机会取决于它所相关的工作量、最大容量表的大小以及其它一些因素。一般情况下，我们推荐：每个CPU上面的原始数据（仅是表的大小）的数量应该基于在被使用服务器上的CPU的功率。比如说pSeries p690-class CPU，我们会建议每个处理器150-200GB。而对于使用Linux或者Windows的xSeries-class CPU（或任何Intel或AMD的机器），我们会推荐每处理器75-150GB。记住，这些只是一般情况下的推荐，在实际情况下会有一些不同的。
体系架构的限制 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加速表的装载
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 与他联系。
_xyz
分区的威力
Dwaine R. Snow and Paul C. Zikopoulos 著
笑熬浆糊 译
原文出处：《DB2 Magazine》 Quarter 2, 2003 · Vol. 8, Issue 2
英文原文（由于文章翻译未经授权，请在转载时保留原文链接）
人们对分区有很多的误解。多伦多实验室的专家们对这个有用的功能进行了正名。
DB2 数据库分区的往往是存在很多误区。对于Linux、Unix以及Windows平台上的DB2 UDB 8.1 版本所做的变动有助于简化DB2 分区。我们将解释这些变动，澄清一些分区的神话，以及说明您应该考虑分区的时机和理由。
DB2 UDB 8.1 For Linux \Unix\Windows将DB2产品家族中以前称之为DB2 UDB 企业版和企业扩展版的产品整合成为一个单独的产品中。这个 新的DB2 企业服务器版(ESE) 包含了数据库分区的功能(从前是作为单独提供的产品) ，作为一个计费的项目，现在被称为数据库分区功能(注：直译——database partitioning feature DPF)。当DB2的用户们发现自己需要开始分区时，那么他们可以马上开始而不需要其他一些额外的代码—— 他们仅仅需要DPF的许可协议。
DPF的真相
关于数据库分区的神话在DB2中随处可见（参见表1）。对于分区基础的快速概揽将帮助你区别真伪并且做出适当的分区决策。
表1 : 围绕DB2 数据分区的神话和事实
无论是否有DPF，DB2都支持并行查询处理。图1展示了安装在一个4路SMP（对称多处理）服务器DB2 ESE。在这个假设中。一个独立的查询可以自动使用这个服务器上所有的CPU和物理磁盘。对于依靠需要数据的子集进行处理的子代理提供分区内部的并行机制。DB2 使用I/O的预存取把从磁盘发送的数据反馈到这些子代理当中。这种并行机制对用户、应用程序以及DBA都是透明可见的。
图 1：不带有DPF的DB2 ESE的并行机制
DPF选项增加了在一组机器中或逻辑上位于某个SMP服务器中的数据库进行分区的能力。依靠DPF，一幅数据库图像可以跨越多台机器（存储），并且它对于用户和应用程序来说仍然还是一幅完整数据库图像。
考虑四路的SMP服务器组的情况。 (在这篇文章里，我们将使用术语数据库分区组而不是集群，因为集群通常是指高可靠性的故障转移配置或者用于衡量系统的分区组。) 使用DPF，在图1中所讨论到的并行操作可以扩展到横跨多台SMP 机器(参见图2)。这样的好处就是有一个双并行操作。 你可以跨越多台机器或者逻辑数据库分区来平衡这些并行操作。这样的处理被称之为分区之间的并行机制。
图2 : 横跨多台机器的使用DPF的并行机制
分区之间的并行机制通常在多台服务器执行，但越来越多的用户现在都一些大型的SMP箱中进行该操作(参见图3)。
图3 : 单独的SMP服务器中的拥有DPF的DB2 ESE.
什么时候（为什么）需要进行分区
那么，你应该去做分区吗？在以下的情况下你应该考虑分区：
· 你的服务器拥有大量可用内存。即使DB2 v8有64位支持，多分区已经被证明可以提供比单独的SMP 并行机制更多的内存的有效使用和更多的线性可扩展性。
· 系统将包括多台服务器，或有超过6 到12 个的CPU。
· 数据库工具的操作速度是你的业务操作的关键所在。
· 为装载数据或提取，转换，负荷处理操作提供的批处理窗口数量是有限的。
· 数据仓库的滚动窗口数据更新的需求使并行SQL处理和其他日志空间成为根本。
分区在这些情况下显得特别有意义。 但是分区所提供的一些其它的好处使得它变得更有魅力。这些好处有：
查询的可扩展性 使用DPF的一个最明显的理由就是它可以增加查询工作量和insert, update，和 delete 操作的性能。把一个单独的大型数据库分区为很多定数量的较小的数据库以加速这些操作因为每一个数据库分区都拥有它们自己的一套数据。
比如说你想要扫描一个包含100 million行数据的表。对于一个单独的数据库分区而言，这次扫瞄会要求独立的数据库管理器去搜索所有100 million个纪录。如果你把你的数据库系统分区为使用50 台数据库分区服务器并且将这100 million条记录均匀的分配到他们之间的话，那么每一个数据库分区上的数据库管理器仅仅需要扫描2 million行。如果每一个扫描都在同一个时间并且以相同的速度执行的话，那么扫瞄完成的时间大约是前者的2%。
DPF提供类似于线性可扩展性和使用工具来完成基础设施构建。这样它可以根据需要增加容量而不需要新技术或者单独安装
DB2 优化器是基于并行机制。换句话说，它保留了如何在系统中对于底层数据进行分区的信息。使用这些信息，优化器考虑不同的查询执行策略和一个低成本的选择。当在比较不同的执行策略时，它会考虑到不同的操作的内在的并行机制和在数据库分区之间传递消息的开销。
在大量数据或者处理器和分区的数量增加的时候，DB2可提供类似线性的可扩展性。但是，分区可能提供的最大好处的机会取决于它所相关的工作量、最大容量表的大小以及其它一些因素。一般情况下，我们推荐：每个CPU上面的原始数据（仅是表的大小）的数量应该基于在被使用服务器上的CPU的功率。比如说pSeries p690-class CPU，我们会建议每个处理器150-200GB。而对于使用Linux或者Windows的xSeries-class CPU（或任何Intel或AMD的机器），我们会推荐每处理器75-150GB。记住，这些只是一般情况下的推荐，在实际情况下会有一些不同的。
体系架构的限制 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加速表的装载
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 与他联系。
_xyz