步骤 5：为联邦者认证创建用户映射
联邦者想从远程数据库获取数据。它需要象任何其它客户机程序那样进行认证。“用户映射（User Mapping）”提供了建立数据请求凭证的机制。
将本地 db2 用户标识映射到远程服务器上的用户标识。下面这个示例从本地标识“LURIE”映射到远程“Informix”标识。
CREATE USER MAPPING FOR "LURIE" SERVER "rcfliif" OPTIONS( REMOTE_AUTHID 'informix', REMOTE_PASSWORD 'useyourown');
DB2 控制中心还提供了用户映射的 GUI 定义方式。如图 4 所示：
图 4. 使用控制中心映射用户标识步骤 6：表别名 － 访问远程表的“门票”
到目前为止我们已经实现了以下内容：
- 包装器：定义了服务器类型并标识了访问它的二进制文件。
- 服务器：定义了远程服务器和数据库在该服务器上的位置。
- 用户映射：定义了到远程服务器的认证。
现在我们就只需要一些表了！
通过别名（nickname）将每张表定义到 Federator。一旦定义了别名，我们就可以象使用本地表名那样使用它。下面的示例说明了属于远程服务器“rcfliif”上用户“lurie”的远程表“card1”被定义成别名“rc9_card1”。
create nickname rc9_card1 for "rcfliif"."lurie"."card1";
恭喜恭喜！有了合适的别名，我们现在就可以做一些“激动人心”的事情了，比如：
select * from rc9_card1;
表名可以提供有用的标识。这个命名约定相当简单。“rc”是关系连接（Relational Connect）的缩写。“9”表示远程服务器是 Informix V9。最后的“card1”是表名。这张表有几个不同基数的生成列。请参阅 附录 B，以获取用于创建表的源代码。
我相信现在 GUI 迷正翘首企盼有一个抓屏，我绝不会让你们失望的。首先是一个过滤器对话框样本，它将表限制为用候选的别名表示（ 图 5）：
图 5. 过滤表过滤处理之后显示了一个表的列表（ 图 6）。在本例中只有一张表满足了过滤器条件。
图 6. 满足过滤器条件的表
单击 OK ，然后会出现 图 7，这是一个数据样本，来自新建别名所代表的表。
图 7. 满足过滤器条件的表联邦连接
配置服务器联邦之后该进行某项测试了。我所使用的环境如 图 8所示。创建该环境的 SQL 列在 附录 A中。
我们要研究的第一个查询将使用远程 IDS9 服务器中的两张表：“rc9_card1”和“rc9_card2”。然后我们将使用具体化数据高速缓存方面的一些先进技术对四张远程表进行最优化。
图 8. 我的测试环境在何处执行连接？
由联邦者基于成本的优化器选择在何处处理表连接。这个选择是影响联邦性能最重要的几个方面之一。优化器可以选择将 SQL 发送到远程服务器并使用远程引擎来连接表。这就是所谓的 下推操作（pushdown）。另外，联邦者可以从远程服务器检索各行，并且可以使用联邦者连接引擎执行连接。
让我们进行查询：
select a.c3, a.c10, sum(a.c100 ) as sum_c100, sum(a.c1000) as sum_c1000 from rc9_card1 a, rc9_card2 b where a.superkey = b.superkey group by a.c3, a.c10;
图 9演示了从远程服务器抽取各行然后在联邦者引擎中处理它们的说明计划。这个连接的总成本超过 4500 万 timeron。
图 9. 在不使用下推操作的情况下进行联邦连接的计划确定在何处执行连接为最佳方案时要考虑几个重要因素：
- 联邦者 CPU 的相对速度与被联邦者 CPU 的相对速度的对比
- I/O 子系统的相对速度和吞吐量
- 网络速度
- 被联邦者数据库的功能
控制中心中的 Create Server 配置显示了许多可以根据服务器相对速度进行调优的参数（ 图 10）。
图 10. 使用控制中心调优某个特定被联邦者所使用的性能参数根据经验，下推操作很有用，当被联邦者数据库能挣脱繁重的文件包束缚时，应当尽可能多地进行下推操作。对于薄弱的远程数据源（比如平面文件集），最好（有时候是 必须）通过检索所有行并连接到联邦者服务器进行连接。
进行下推操作后，查询计划看起来大不一样，如 图 11所示。与不进行下推操作的情况相比，总成本（timeron）大大降低了。
优化器实际上非常深入地考虑了在何处进行连接。我努力使这项工作尽可能简单。不要过分担心弄不懂分布式连接理论 － 有太多有趣的联邦技术的应用，以至于很难详述该理论。联邦服务器和远程服务器的最新统计将改进该查询计划。
图 11. 下推操作连接执行得快得多更快的联邦连接 － 具体化查询表
连接两张表最快的方法是根本就不连接它们。事务处理委员会（Transaction Processing Council，TPC）的 TPC-D 基准测试（现已撤销）最后证明：如果在汇总表中预先计算查询答案，那么该查询会运行得比较快。
如何才能将这种汇总表加速技术应用到联邦环境呢？要真正充分利用汇总表，必须尽可能随时使用它们。一个月一次的数据汇总可以满足一个月、一个季度或一年一次聚集级别的查询。但是优化器必须智能到能够重写查询，以便对汇总表进行操作而不是寻找详细情况。我们将测试这项功能。
将汇总表添加到联邦者的方式与非联邦环境非常相似。在 DB2 V8 中这些表被称为具体化查询表（MQT）。联邦者的一个强大功能就是在别名（远程）表上创建 MQT。
添加具体化查询表
MQT 包含了一条 SELECT 语句，用于定义该如何汇总数据。实现 MQT 的 SQL 如下所示：
--create a materialized query table or MQT -- this will allow the optimizer to rewrite SQL -- and not access the remote servers drop table card_mqt; create summary table card_mqt as ( select a.c3, a.c10, sum(a.c100 ) as sum_c100, sum(a.c1000) as sum_c1000 from rc9_card1 a, rc9_card2 b, rc8_card1 c, rc8_card2 d where a.superkey = b.superkey and b.superkey = c.superkey and c.superkey = d.superkey group by a.c3, a.c10 ) data initially deferred refresh deferred; -- populate the MQT with data refresh table card_mqt; -- VERY IMPORTANT - tell the optimizer the MQT -- alive and well and open for business set current refresh age=any;
那么 MQT 提供了多大的改进呢？
首先考虑跨两个不同服务器的四表查询。不进行下推操作的查询成本最高。查询 SQL 如下：
