张荷芳 和 徐彦丽
2012 年 11 月 08 日发布
免费下载：IBM? DB2? Express-C 10.1 免费版 或者 DB2? 10.1 for Linux?, UNIX?, and Windows? 试用版下载更多的 IBM 软件试用版，并加入 IBM 软件下载与技术交流群组，参与在线交流。
计算机、网络、传感技术等各项信息技术的发展，使得我们生活的环境变成了今天这个由数据统治的世界，每天都有大量纷繁复杂的数据、信息充斥耳边。据称现在只需两天就能创造出自文明诞生以来到 2003 年所产生的数据总量。而企业数据也以 55% 的速率逐年增长。这些大量的交易数据、交互数据中并不是 100% 都是有意义的，但我们又不得不去接收它们。这是因为数据当中隐含着有价值的信息，并且这些信息都是有时效的，需要及时进行整合、分析、再创造，然后才能更好地与用户交互，实现在合适的时间、通过合适的途径、销售合适的产品，最终实现企业利润增长。数据复制产品正是这一数据处理过程中最关键的一环，它能够将接收到的数据分发到各个场所，用于及时整合数据，产生实时报表，或者为实时统计提供输入。
数据集中 / 分发经典场景
对于集团型企业，例如银行、电信、保险等，通常包含多个子系统，每个系统对应一项或多项业务，而业务终端也往往部署在各个省市地区。某个地区的某个子系统里数据在一定时间内只能代表该地区的业务特征。因此，业务的广泛性和区域性使得企业不能对内部的数据进行全盘规划和统一，这大大影响了企业对业务的分析决策。具体影响有：
关键数据不唯一，集团无法判断数据的准确性，需要花费更多的人工和资源验证并纠正数据，因此不能对分公司或子公司的数据进行及时分析，从而进行全盘分析和规划；分公司或子公司间数据无交互或交互较少，各自为政，数据无共享，造成各分公司或子公司间不能有效借鉴或沿用有价值或有代表性的决策和方案，集团范围内数据管理困难，数据丢失的风险性较高。
没有统一的关键数据管理会造成集团范围内不能实时监控并及时分配关键资源，不能及时获取各地数据掌握全局趋势，也往往会造成决策失误。这些问题严重的话会造成企业无法弥补的损失。因此企业通常会建立数据中心、部署一套数据集中 / 分发方案以保证各地各项业务数据的统一。典型场景如图 1 所示，在集团所在地或附近建立中心服务器，在各分公司或子公司部署分级服务器。中心服务器与分级服务器间通过网络实时通信，分发或集中数据。各分级服务期间根据需要也可进行通信。
图 1. 数据集中 / 分发场景
点击查看大图
数据集中 / 分发对数据冲突和负载均衡的要求
数据的集中和分发根据实际情况要求和设计考虑的角度的不同，具体实现起来方案有很多。有些由中心服务器承担主要业务输入，有些反之，有些根据具体情况不同，对不同的业务指定不同的主承受服务器。但究其本质是如何保证事务的原子性和数据在各个副本中的一致性。这方面从技术发展历程来看，早期主要通过两阶段提交协议实现原子性，通过两阶段锁或时间戳模型实现副本的一致性。这种模式即为通常所说的同步复制过程，涉及到各副本与提交事务的节点间的互相确认过程，因此具有一定的性能影响。后来为提高吞吐率，缩短响应时间，对一致性级别进行了放松，出现了异步复制，面对不同的目的，出现了不同的异步复制协议。目前企业中使用的复制产品大多为异步复制。这种方案不能像同步复制那样实现完全实时复制，必然会出现一定的延时，虽然这种延时通过各种技术手段可以控制在秒级，甚至更小，但对于在每个副本都能操作数据的系统中，还是有可能出现数据冲突。
数据冲突简单地说，是因为某一行数据在不同地点被不同的应用同时进行了修改。这种修改具体表现有插入、更新、删除。举例来说，有表（列 1，列 2，列 3），其中列 1 是表的主键，该表同时部署在两地的 Server A 和 Server B 中。最普遍的冲突情况是，A 和 B 同时有应用对该表插入了具有相关关键字的数据，该事务在本地服务器上能执行成功，但当数据变化传递到对方时，会发现以这个关键字值标记的行已存在，冲突发生；另一种普遍的冲突是，A 和 B 同时修改了相同关键字行的非关键字列，这样当变化传递到对方时，冲突发生。无论具体冲突是什么情况，在异步复制中都无法完全避免，因此在设计方案时必须要有在发生数据冲突时，一些有效的冲突解决方案，这样才能最终保证数据的一致。
由于业务的多样性，由单个服务器承受所有的业务具有很高的风险性，当出现断电等意外，或者更大的自然灾害时，损失是无法挽回的。因此设计数据集中 / 分发方案时需要考虑如何实现负载均衡。从全局来看，需要合理分配各项业务的连接；从具体业务来看，需要合理均衡读连接和写连接，特别对于具有大用户量的业务，用户对系统响应一般都具有较高的期望，用户量也往往跟系统响应时间负相关，而受限于服务器以及数据库系统的处理能力，单个表是很难满足大量同时的读写连接的。
IBM InfoSphere Replication Server 产品中的 SQL 复制框架最早可以追溯到 1994 年 IBM DB2 发布的 DataPropagator Relational（DPropR）的第一个版本。因此，相较于 2004 年推出的 Q 复制框架，SQL 复制功能的客户基础较深厚，事实证明它在实现数据集中 / 分发方面具有较好的优势和稳定性。本节将带领读者简单回顾一下多向 SQL 复制的实现。
多向 SQL 复制基本原理
目前 SQL 复制支持用户副本（User copy）、时间点（Point-in-time）、基本聚集（Base aggregate）、更改聚集（Change aggregate）、CCD（Consist-change data）、副本（Replica）。 本文提到的多向 SQL 复制基于副本类型构建，也称为 Update-anywhere 复制。
此类型支持从源或者目标都能更新数据。相较于其他 SQL 复制类型，仅有此类型允许目标表的数据更新复制回充当主表的源表。但这种类型的复制中，必然会发生用户同时操作源表和目标表的同一行数据的情况，即发生数据冲突。Replication Server 为此定义了数据冲突检测和解决的方案，即以主表，即源表中的数据为主。如果数据与主表中的记录发生任何冲突，那么该更新将被拒绝。因此在该类型方案中，必然有一个数据库充当主数据库。另外，此类型不支持非 DB2 目标数据库。
Update-anywhere 在数据集中 / 分发场景中的应用可以有两种方案，其原理如图 2 所示。
图 2. 多向 SQL 复制实现数据集中 / 分发
点击查看大图
方案一中中心服务器上只运行 SQL Capture 程序，各分级服务器上既要运行 SQL Capture 程序又要运行 SQL Apply 程序。各分级服务器上的 SQL Apply 间或地连接到中心服务器下载中心服务器的数据变化或上传本地的更新，每个分级服务器上的变化通过中心服务器传播到其他分级服务器。方案二与方案一的不同之处在于，各级服务器上不运行 SQL Apply 程序，而是在中心服务器上运行 SQL Apply 程序。该 SQL Apply 程序将数据发布到所有的远程分级服务器上。
多向 SQL 复制对数据冲突和负载均衡的支持
上一节中回顾的两套多向 SQL 复制方案中，在任何一个服务器上都能执行数据更改相关的操作，并且能够保证数据在任一服务器上的变化都能最终体现在所有服务器上，延迟的数量级可以控制在分钟。尽管如此，SQL 复制因为总是需要通过 SQL Apply 程序周期性地上传下载数据，仍然有较大发生数据冲突的可能。对于冲突检测解决，SQL Apply 程序具体相应的实现。它在应用数据变化前，会先检测数据冲突，即，读取中心服务器上主表的 CD 表和各分级服务器上副表的 CD 表，比较关键字的值，如果同一关键字出现在两个或以上的 CD 表中，说明冲突发生。对于冲突，SQL Apply 程序会回滚副表上的事务，采用主表上的数据变化。即主表为胜。尽管有相应的数据冲突检测解决方案，可以看出，这是有一定代价的，一些有意义的副表上的变化可能会因此丢失。在设计方案时需综合考虑用户对数据丢失的承受度，并且从业务流程上尽量避免冲突的发生。
因为数据在任一服务器上都是相同的，并且允许在任一服务器上操作数据，在使用该方案时，就可以根据具体情况从业务流程上分配各项业务连接达到负载均衡的目的，但从具体操作层面，即是读连接还是写连接，该配置中并没有特别地区分，在应付那种大量读和大量写的情况时，可能会有潜在的性能问题。
基于对以上问题的探索，InfoSphere Replication Server 和 InfoSphere Federation Server 合作提出了一个基于 Cache Table 的数据复制方案，为用户提供了另一种实现数据集中 / 分发的思路。
在现实应用中，我们一般单独使用 InfoSphere Replication Server 或者 InfoSphere Federation Server，虽然 Replication Server 在对远程数据源的支持方面要基于 Federation Server，但是真正在外部把这两种产品结合起来实现数据集中 / 分发的并不常见。本节中我们即将介绍这种把 Replication Server 和 Federation Server 结合实现数据集中 / 分发的解决方案，包括 Federation Server 的 Cache Table 及特点、此种解决方案的基本原理、类型和配置要求。
Cache Table 介绍
在介绍 Cache Table 之前，我们先了解一个基本概念——物化查询表。MQT（物化查询表）是基于查询结果定义的一个表，是提高查询性能的有效手段，广泛应用于数据仓库和大数据量的报表查询系统中。与视图类似，MQT 中包含的数据来自 MQT 定义所基于的一个或多个表，且视图和 MQT 都是基于一个查询来定义的。每当视图被引用时，视图所基于的查询便会运行，读取基表数据。MQT 则不同，它会将查询结果存储为本地数据，因此用户可以直接引用 MQT 中的这些数据而无需读取基表数据。因此，MQT 可以看作是一种物化的视图。
由于 MQT 本身的特点，它可以显著提高查询的性能，尤其是提高复杂查询的性能。如果优化器确定查询或查询的一部分可以用一个 MQT 来解决，那么查询就可以被重写以便利用 MQT。MQT 可以在创建表时定义，可以定义为由系统维护或由用户维护。
在 Federation Server 中，基于 nickname 的 MQT 称之为 Cache Table。它物化了一个涉及一个或多个 nickname 的查询的预先计算的结果。nickname 所对应的源表可以是远程数据库中的表，所以 Cache Table 作为一个逻辑的表对象 , 可以用来缓存远程数据源的数据 , 将远程数据源的数据缓冲到本地的 Federation Server 中。通过把数据存储在本地而不是直接访问远程数据源数据，能够大大提高查询性能。Cache Table 是用户维护的 MQT 的特殊子类型，其中的数据是通过使用 Replication Server 进行填充的，并且可以定义是完全填充还是部分填充。Replication Server 的复制技术能够保证数据在远程数据源和本地 MQT 间的实时性和一致性。
当在本地服务器上创建并填充好 MQT 之后，只要 MQT 匹配查询的一部分或所有部分，任意后续的对远程源表的查询就可以由该 MQT 来满足。如此就能发挥 MQT 高速缓存数据，优化查询的效用，大大改善数据库管理系统中的查询性能。Cache Table 的具体作用体现在：
联邦查询一般在远程系统上执行部分（或整个）查询，并通过网络将即时结果返回给 Federation Server。由于网络的延迟，以联邦模式运行查询一般比只访问本地数据的相同查询要慢一些。Cache Table 使得远程数据本地可用，因此省去了通过网络到远程数据源的时间延迟；如果需要从中获得查询数据的一个远程数据库管理系统不可用，那么查询的访问计划决定使用 Cache Table 而非远程数据来满足查询时，查询将仍然能够产生结果。图 3. Cache Table 架构
点击查看大图
在了解了 Cache Table 的基本概念和主要作用之后，我们来了解一下 Cache Table 的框架结构。图 3 是 Cache Table 的基本架构，主要包括以下几个部分：
Federation Server 的昵称 (nickname)，这个昵称的列定义要与远程数据源一致；基于 nickname 的一个或多个 MQT，这个 MQT 的类型是 FEDERATED_TOOL，并且包含一些使用率最高的数据；MQT 的复制计划 (Replication)，源表为远程数据表，目标表为基于 nickname 的 MQT，此复制计划填充 MQT 并使得 MQT 与远程数据表同步，用户可以定义这些复制计划。
使用 Cache Table 需要注意以下几点：
Cache Table 只能使用 DB2 控制中心来建立和设置；Cache Table 名字与昵称名字相同，并且只能基于一个数据源表；如果数据能够从 MQT 里面抽取 , 在 Cache Table 被激活后，查询优化器可以直接查询 Cache Table，而不需要去查询远程数据源表；Cache Table 是一种用户维护的 MQT，所以不支持使用 REFRESH TABLE 语句，而是通过 Replication Server 来填充和更新数据；Cache Table 支持多种数据源，包括 DB2 家族 , Oracle, Informix, SQL Server 和 Sybase；Cache Table 支持多种平台，这一特性与 DB2 相同，包括 WINDOWS、UNIX、LINUXAMD、LINUX390、LINUXPPC64、SUN 及 HP。
基于 Cache Table 的单向 SQL 复制基本原理
由于 Cache Table 是基于 nickname 的 MQT，并且通过 Replication Server 能保证数据在远程表或 nickname 中发生变化时，远程源表、nickname、MQT 中的数据保持一致，同时 Cache Table 还具有提高查询性能的效用，因此基于 Cache Table 的单向 SQL 复制是一种可行的数据集中 / 分发方案。本节将首先介绍基于 Cache Table 的单向 SQL 复制的基本原理，然后讨论该方案在数据冲突和均衡负载方面的支持。图 4 为基于 Cache Table 的单向 SQL 复制的原理图。
图 4. 基于 Cache Table 的单向 SQL 复制原理图
点击查看大图
如图 4 所示，整个方案包括三个部分：中心服务器上的数据源表；在各分级服务器上创建的基于源表的 Cache Table（包括源表的 nickname，以及基于 nickname 的 MQT）；中心服务器上的源表到各分级服务器上的 MQT 的复制计划，目前支持使用 Replication Server 的 SQL 复制。对于修改操作，用户可以在中心服务器的源表上进行，也可以在各分级服务器的 nickname 上进行。而对于读操作，在源表、nickname、MQT 都能进行。
即使修改操作发生在不同的地点，都能保证数据的一致性：
用户修改中心服务器上的数据源表，源表数据发生改变；这时根据 Federation Server 昵称的功能，各分级服务器上的 nickname 会随着源表的变化相应改变。另一方面，源表的数据变化被中心服务器上的 SQL Capture 程序（如果是非 DB2 数据源，则是 Capture 触发器）捕获到，放入 CD 表中；各分级服务器上的 SQL Apply 程序通过读取 CD 表中的数据变化记录，将该变化应用到分级服务器上的 Cache Table 里的 MQT。这样用户无论是查询 nickname 还是 MQT 都能得到最新的数据，最终达到数据的一致性；用户操作 nickname，昵称的数据发生变化，根据 Federation Server 昵称的功能，中心服务器上的源表的数据也会相应发生变化；源表数据变化被运行在中心服务器上的 SQL Capture 程序（如果是非 DB2 数据源，则是 Capture 触发器）捕获后放入 CD 表，再经过分级服务器上的 SQL Apply 传递到 Cache Table，填充 MQT，这样 MQT 也发生了同样的数据变化，最终达到数据的一致性。
从上述说明可以看出 , 不论用户是在中心服务器上还是在分级服务器上进行数据操作 , 都能保证数据在各地的一致性 , 同时由于数据缓存在本地 MQT 中，分级服务器上对源表的查询可以得到大大的改进，用户也完全可以根据需求定义业务流程，均衡增删改操作和查询，从而促进系统负载的平衡。
进一步推广这种方案。在客观场景中，中心服务器与各分级服务器间可以涉及到多个数据库厂商提供的不同数据库产品，比如同时存在三种数据库：DB2, Oracle 和 Informix，由于不同数据库系统的不同，需要考虑数据库之间兼容性的问题。而 Federation Server 作为数据互操作的产品，正是强于解决此类场景。它可以通过为不同数据库表建立 nickname，最终实现对不同数据库进行操作，从而达到不同数据源之间的数据集成。
基于 Cache Table 的单向 SQL 复制对数据冲突和负载均衡的支持
在上一节介绍基于 Cache Table 的单向 SQL 复制原理时，就可以清晰地看出，对于增删改这样的写操作，无论用户是在中心服务器上操作源表，还是在任一分级服务器上操作 nickname，实际上都是直接操作源表，因此对于写操作用户，他无论在何时何地，看到的数据都是最新的，数据冲突的可能被下放到数据库层面，转化为数据库并发处理，因此从系统层面来看，无需准备数据冲突检测和解决方案。对于查询这样的读操作，只需要注意 MQT 上的数据是否是最新的，因为其中数据是通过单向 SQL 复制来传递的，具有一定的延时性，但这种延时也同样可以控制在分钟。因此，相比之前回顾的多向 SQL 复制方案，本方案大大避免了数据冲突，不存在数据丢失。
与多向 SQL 复制方案相同，因为数据在任一服务器上都是相同的，并且允许在任一服务器上操作数据，本方案也可以根据具体情况从业务流程上分配各项业务连接达到负载均衡的目的。但在操作层面，本方案则显示出了优势。MQT 本身对查询性能的促进作用在考虑方案的负载均衡能力时可以被大大利用，特别对于那种分级服务器中读操作量远远大于写操作量的客户场景，可以将查询操作定向到 MQT 上，变远程访问为本地访问，一方面降低系统负载，另一方面则大大提高了用户响应速度，在某些情况下，甚至可以在同一个分级服务器上建立多个 MQT，或者根据需要定义面对不同需求的 MQT。
所以，基于 Cache Table 的单向 SQL 复制可以说是 InfoSphere Replication Server 和 InfoSphere Federation Server 为更好地帮助用户实现数据集成，保证数据的一致性和完整性，做出的尝试，具有一定的特点，用户可以根据具体情况考虑该方案的使用。
基于 Cache Table 的单向 SQL 复制配置需求
由于 Cache table 的特殊性及这种解决方案组成部分的复杂行，所以此种解决方案需要一些特殊的配置需求，主要表现为以下几个方面：
Cache Table 包含基于 nickname 的 MQT，其中 nickname 是 Federation Server 的基础对象。要使用 Federation Server 功能，数据库则需打开 Federation Server 的开关参数 FEDERATED，并设置为 YES。具体命令是“db2 update dbm cfg using federated yes”。上文中我们已经提到 Cache Table 支持多种数据源，对不同数据源，配置要求也有不同：当 DB2 LUW 作为数据源时 , 由于复制计划需要历史日志信息，所以 DB2 需要设置为归档日志模式，从而保证复制的准确性。当使用其他支持的非 DB2 家族数据源时，需要设置相应的满足 Federation Server 要求的客户端配置变量，具体可以参见 Federation Server 信息中心的数据源配置一节。值得说明的是，当 INFORMIX 作为数据源时 , 除了 Federation Server 需要设置的变量外，还需要安装并设置 INFORMIX 客户端 Informix Client Software Development Kit (SDK)。若数据源不在本地 , 根据 Federation Server 的特性，需要 catalog 远程数据库，并且 catalog 的名字必须与远程数据库名字相同。若能操作远程数据源，用户必须有在远程数据源操作相应数据库对象的权限。要确保用户权限合适，必须创建使用 Federation Server 的 user mapping 功能建立本地用户到远程数据源用户权限的映射。
前文我们已经分析了此方案的原理、类型和主要特点，本节用一个实例具体介绍该方案的实现过程，为简化介绍，这里我们只涉及一个中心服务器和一个分级服务器。对于更多分级服务器的情况，读者可以很容易地相应扩展。
环境准备
我们将要实现如图５所示的一个基于 Cache Table 的单向 SQL 复制实例。
首先做好系统和软件准备：
准备一台中心服务器，一台分级服务器，本例中中心服务器名为 ServerA，分级服务器名为 ServerB；在中心服务器和分级服务器上安装 DB2；在中心服务器上安装 Replication Server；在分级服务器上安装 Replication Server 和 Federation Server。图 5. 基于 Cache Table 的单向 SQL 复制实例
点击查看大图
然后我们将创建数据库相关对象：
中心服务器上数据库。本例中数据库名为 DB_A；源表。本例中表名为 CUSTOMER_T；分级服务器上数据库。本例中数据库名为 DB_B；Cache Table。本例中 nickname 名为 CUSTOMER_N，MQT 名为 CUSTOMER_N_MQT；中心服务器和分级服务器间源表的登台表。本例中表名为 CDCUSTOMER_T；源表和 Cache Table 间的单向 SQL 复制。
实现步骤
实现图５的实例需要经历以下步骤：
在中心服务器上创建一个数据库 DB_A，在分级服务器上创建一个数据库 DB_B；在中心服务器上的数据库创建源表 CUSTOMER_T；在中心服务器上配置日志归档模式，在分级服务器上配置 Federation 特性；在分级服务器上创建 Federation Server 包装器 wrapper；在分级服务器上定义 Federation 服务器和用户映射；在分级服务器上创建远程源表的 nickname CUSTOMER_N；在分级服务器上创建基于 nickname CUSTOMER_N 的 MQT CUSTOMER_N_MQT；创建源表和 MQT 间的 SQL 复制，包括控制表，预定集，SQL 预定；设置 MQT 数据初始化方式；启动中心服务器上的 SQL Capture 程序和分级服务器上的 SQL Apply 程序，从而启动 SQL 复制。图 ６ . 基于 Cache Table 的单向 SQL 复制实例实现步骤
点击查看大图
具体过程
步骤 1. 创建中心数据库 DB_A 和分级数据库 DB_B
清单 1. 创建数据库
-- 在中心服务器 ServerA 上创建中心数据库 DB_A --
create db DB_A;
-- 在分级服务器 ServerB 上创建中心数据库 DB_B --
create db DB_B;
步骤 2. 在中心数据库 DB_A 创建源表 CUSTOMER_T
清单 2. 创建源表
-- 在中心数据库 DB_A 创建源表 CUSTOMER_T --
connect to DB_A;
create table Customer_T(ID int unique not null, NAME char(20));
步骤 3. 配置中心数据库 DB_A 日志归档模式，分级数据库 DB_B Federation 特性
清单 3. 配置数据库
-- 中心数据库 DB_A 日志归档模式 --
update db cfg for DB_A using LOGARCHMETH1 LOGRETAIN;
backup db DB_A to .;
db2stop force;
db2start;
-- 分级数据库 DB_B Federation 特性 --
update dbm cfg using federated yes；
db2stop force;
db2start;
步骤 4. 在分级数据库 DB_B 上创建 wrapper
Federation Server 对象包括包装器、服务器、用户映射、昵称等，这些对象可以通过控制中心也可以通过命令行方式创建，本例中我们将以命令行方式创建 Federation Server 对象。
清单 4. 创建 wrapper
-- 分级数据库 DB_B 上创建 wrapper--
uncatalog node ServerA;
catalog tcpip node ServerA remote
uncatalog db DB_A;
catalog db DB_A as DB_A at node ServerA;
Connect to DB_B;
create wrapper drda;
步骤 5. 在分级数据库 DB_B 上创建 Federation Server 服务器和用户映射
清单 5. 创建服务器和用户映射
-- 分级数据库 DB_B 上创建服务器和用户映射 --
Connect to DB_B;
create server s1 type db2/udb version
authorization "
options (node ‘ServerA‘, dbname ‘DB_A‘, password ‘Y‘, pushdown ‘Y‘);
create user mapping for user server s1
options ( REMOTE_AUTHID ‘
步骤 6. 在分级数据库 DB_B 上创建源表的 nickname CUSTOMER_N
清单 6. 创建 nickname
-- 分级数据库 DB_B 上创建 nickname--
Connect to DB_B;
CREATE NICKNAME CUSTOMER_N FOR s1."
步骤 7. 在分级数据库 DB_B 上创建源表的 Cache Table
使用命令 db2cc 打开 DB2 控制中心，All Databases->DB_B->Cache Ojects，右键新建 Cache Tables，在选择 Nickname 时选择 CUSTOMER_N，由于 Cache table 一次只能基于一个数据源，所以只能选择一个 nickname，如图 7。
图 7. 选择 nickname
点击查看大图
然后创建基于 nickname 的 MQT。在此步可以设定是完全 MQT 或者部分 MQT。完全 MQT 是基于整个远程表，当设置了查询条件后，就是部分 MQT，是基于部分查询。本例中我们不设置查询条件即使用完全 MQT。如图 8。
图 8. 设置基于 nickname 的 MQT
点击查看大图
接着设置授权信息，给出源表即主数据库的用户名和密码，如图 9。
图 9. 设置复制计划的授权
点击查看大图
步骤 8. 配置 SQL 复制
复制计划可以根据具体需要设置 Capture、Apply 及运行周期，本例中我们设置复制时间为连续，其他设置默认。如图 10。
图 10. 设置复制计划 Capture, Apply, Schedule
点击查看大图
步骤 9. 配置查询优化器如何使用 MQT
本例中允许查询优化器使用 MQT。这样，若远程数据源不可用，查询优化器会直接访问基于 nickname 的 MQT，用户依然可以得到查询结果，这种方式需要设置两个优化器参数：DFT_MTTB_TYPES 和 DFT_QUERYOPT（具体参数说明和要求可参见 InfoSphere Federation Server 信息中心），此例中我们选择 FEDERATED_TOOL，其他选项默认。如图 11。
图 11. 选择 MQT 类型
点击查看大图
步骤 10. 启动 SQL 复制
启动本例中的 SQL 复制需要启动中心服务器上的 SQL Capture 程序和分级服务器上的 SQL Apply 程序。该操作可以通过 Replication Center 完成，也可以通过命令。
清单 7. 启动 SQL 复制
-- 中心数据库 DB_A 上启动 SQL Capture--
asncap capture_server=DB_A
-- 分级数据库 DB_B 上启动 SQL Apply--
asnapply control_server=DB_B apply_qual=
配置完成并启动后，可以操作中心数据库上的源表，或分级数据库上的 nickname 来验证数据在各个地方的一致性：
在中心数据库端，对源表执行插入操作。然后查看源表、分级服务器上 nickname 以及 MQT 中的数据；在分级数据库端，对 nickname 执行插入操作。然后查看中心数据库中的源表、分级服务器上 nickname 以及 MQT 中的数据。
读者可以容易看到，不论用户是在中心服务器上还是在分级服务器上进行数据操作 , 都能保证数据在各地的一致性。需要值得注意的是，由于 Cache Table 仅能通过控制中心来创建，所以本方案仅支持具有控制中心的 DB2 版本，读者可以根据实际应用来选择。
本文首先提出了现实中数据集中 / 分发方案对数据冲突和负载均衡的需求，而后回顾了多向 SQL 复制对数据集中 / 分发的实现，在此基础上介绍了基于 Cache Table 的单项 SQL 复制。该方案围绕数据冲突和负载均衡，提出了一些新的思路和方法，不仅能够保证数据一致性，还能避免数据冲突，并且由于数据缓存在本地 MQT 中，分级服务器上对源表的查询可以得到大大的改进，用户也可以自定义业务流程，均衡增删改操作和查询，从而促进系统负载的平衡。因此，用户可以根据具体情况，考虑该方案的使用，或与其他方案结合使用。
相关主题在
DB2 V10.1 Query performance enhancements进一步了解 DB2 V10.1 对查询性能的优化。在 IBM DB2 10.1 for Linux, UNIX and Windows 信息中心：获得 DB2、InfoSphere Replication Server, InfoSphere Federation Server 更多有关信息。在 developerWorks 中国网站 Information Management 专区，获取提高您 IBM Information Management 产品技能所需的资源。随时关注 developerWorks 技术活动 和 网络广播，包括各种 IBM 产品和 IT 行业主题。以最适合您的方式 IBM 产品评估试用版软件：下载产品试用版、在线试用产品、在云环境中使用产品，或者在 IBM SOA 人员沙箱 中花几小时。