![关闭 [x]](http://dw1.s81c.com/i/c.gif){kind=small}
InfoSphere Federation Server 适用场景
IFS(InfoSphere Federation Serve) 提供了一个虚拟的数据集成平台，用户可以像访问单个数据库一样访问和操作一组不同的数据源；用户不用关心数据的位置，格式及语义；不用创建新的数据库，也不必破坏已有的数据；访问方式可以使用标准 SQL，或者任何支持 JDBC/ODBC 的工具。
IFS 采用了虚拟的数据集成方法，避免了把大量数据物理集成到同一数据库中，也就避免了物理迁移的代价，以及物理迁移会丧失数据实时性的缺点。
IFS 广泛应用在以下场景：
- 获取数据量不大并且给数据源带来的压力较小。这种场景下，查询本身返回的数据量不大，或大数据量查询次数很少
- 远程数据变化频繁
- 不物理移动数据
- 由于安全或权限限制无法移动数据
- 需要移动的数据量太大或很多无用数据或只需要访问临时数据
- 应用对数据实时性要求很高
- 需要访问远程的特殊函数
- 通过函数模版及函数映射下推操作
- 需要频繁的读写操作
InfoSphere Federation Server 常用架构
作者对现有 IFS 的应用场景中的架构进行分析，归纳总结，提炼出 6 种常用的 IFS 架构（IFS 的使用并不局限于这 6 种），本节将逐一给予分析。
- 架构 1：集成异构数据源
- 架构 2：对 portal 应用提供针对多数据源的统一数据接口
- 架构 3：扩展数据仓库操作范围
- 架构 4：在 DB2 及非 DB2 数据库间进行数据迁移
- 架构 5: 加快数据仓库模型设计
- 架构 6：为 ETL 提供预处理
很多企业有各种不同的数据源需要集成，特别是大企业，历史悠久的企业，由于历史、地理、合并、收购等各种原因存在各种不同的异构数据源，需要统一集成以供进一步的开发利用。IFS 在数据源的集成过程中充当了重要的角色。
IFS 在本架构中解决了用户以下问题：
- 用单一的 API 集成多个数据源，复杂并且成本高
- 访问非传统的数据源的性价比很低
- 需要熟练掌握各个不同数据源的技能，这种人员缺乏
IFS 给用户带来的价值：
- 减少了集成的代码工作量
- 使用已有的 SQL 工具访问所有数据
- 减少了应用程序的维护成本，只需要熟悉 DB2 和 SQL
该架构中体现出 IFS 的功能：
- 数据集成提供了对多个异构数据源的虚拟访问，就像访问单个数据库一样
- 这种虚拟化是透明的，最终的用户并不知道他们正在从不同的数据源访问数据，屏蔽了语义和地理上的差别
- 不需要改变已有的环境和已有的数据源
- 实时数据访问
- 没有冗余的数据备份
- 可以从不同的数据源连结不同类型的数据
另外，IFS 和 InfoShpere Classic Federation Server 一起可以将集成数据源的范围扩展到主机上的数据，比如 DB2 for Z/OS, VSAM, IMS, Software AG Adabas, CA-Datacom, CA-IDMS 等。
图 1. 架构 1：集成异构数据源
架构 2：对 portal 应用提供针对多数据源的统一数据接口
Portal 应用的底层可能需要多个异构数据源，分别将每个数据源集成到 portal 应用中从编程上来说是非常复杂的，开发和维护成本都很高。如果将 portal 应用建立在 IFS 之上，IFS 完成各个数据源的集成，可以屏蔽数据源集成的逻辑和细节，减少点对点的连接，减少客户端软件的维护成本。IFS 可以大量减少手工代码量，并且获得专家级的性能调优。
IFS 在本架构中解决了用户以下问题：
- 要屏蔽各个数据源之间的不同
- 面临部署新应用的时间压力
- 当要有新的数据源要加入时，需要能很快的扩展能力
IFS 给用户带来的价值：
- 在一个虚拟数据库上展现所有的数据源
- 在应用程序中，可以用 SQL 访问所有相关的数据源
- 很容易集成新的数据源，只需要创建新的 wrapper
该架构中体现出 IFS 的功能：
- 加速应用程序的开发
- 节省了人力成本，减低了运营成本：像单个数据源一样开发 / 部署应用程序；不用关心各个数据源之间的细节；只需要一个 DBA
- 不改变基于各个数据源的应用程序
- 实时的查询结果
- 可扩展性：很容易集成更多的数据源
图 2. 架构 2：对 portal 应用提供针对多数据源的统一数据接口
用户需要基于数据仓库的数据进行分析，包括实时数据和非关系型数据。但是由于各种原因，有些数据可能会保留在数据仓库之外，比如 license restriction, 实时数据，数据量巨大且不稳定的数据，有特殊要求的数据，安全性要求很高的数据（例如工资表），还没有来得及放入数据仓库中的数据（例如来自被合并或者被收购公司的数据，数据集市的合并）。非关系型数据源包括文本文档，来自 web 的数据，电子资产等。
通过引入 IFS，可以把位于不同位置，异构的数据源进行集成，扩充了数据仓库的范围，更好的满足了用户对实时性的需求。
IFS 在本架构中解决了用户以下问题：
- 从多个数据和内容库中集成信息生成复杂的报表
- 组合历史信息和实时信息进行分析
- 快速部署涉及到存储在已有数据仓库之外的数据（如遗留数据源）的新应用
- 考虑到数据移动的成本，不想把所有的数据都移植到数据仓库中
IFS 给用户带来的价值：
- 基于多个数据源的数据，可以更好的作出决策
- 提供各个数据源的实时数据
- 利用已存在的数据仓库可以提高投资回报率
- 能够透明访问不同物理位置的数据
该架构中体现出 IFS 的功能：
- 不必移动数据源的所有数据
- 组合运营数据和历史数据：运营数据要求很高的实时性
- 提供 BI 所需要的更多数据源，当前的数据仓库或者 ETL 工具支持的数据源是有限的
- 只需考虑安装 IFS 的 license 费用，不必关心集成数据源的个数，降低了成本
图 3. 架构 3：扩展数据仓库操作范围
异构数据库之间的数据迁移是个很复杂的问题。虽然 IFS 的主要目的是为了集成异构数据源，但是在实际应用中，IFS 也可以在不影响已有系统的前提下将数据在 DB2 和非 DB2 的数据库之间进行数据迁移。当从非 DB2 数据库迁移到 DB2 数据库时，可以在 DB2 数据库中在未完成物理数据迁移之前通过 IFS 创建 nickname 来调试新应用程序。当从 DB2 数据库迁移到非 DB2 数据库时，可以通过 IFS 创建 nickname 保证即使一部分数据已经完成物理迁移的情况下原始 DB2 应用程序仍可以继续运行。如图 4.
IFS 在本架构中解决了用户以下问题：
- 由于涉及到不同的类型、功能和语义映射，数据迁移是个复杂的工作
- 数据迁移需求很长的周期，同时原始的应用程序在迁移过程中依然要求能够工作
IFS 给用户带来的价值：
- IFS 提供的目标和源之间的映射减少了工作量，加速了迁移的进程
- 通过 nickname 的使用，原始的应用程序仍然能够工作
IFS 的功能：
- 通过 nickname，类型映射，函数映射，提供系统无缝数据迁移
- 不改变已存在的数据源和应用程序
图 4. 架构 4：在 DB2 及非 DB2 数据库间进行数据迁移
部署数据仓库的过程不是一个线性的过程。用户最终需要的数据元素和模型的确定是个典型的迭代过程。从用户开始使用数据就会频繁地改进数据模型，而频繁的改动会带来大量的工作量。通过 IFS，用户可以就像所有数据都来自数据仓库一样访问所有的数据元素。而 IT 部门只需要定义或者更新联邦视图，并不需要为了扩展数据而改变 ETL 或者复制过程。这样就极大的降低了数据模型修改的工作量，从而加速数据仓库模型的设计。
IFS 在本架构中解决了用户以下问题：
- 数据仓库的建模是一个很长的过程，需要在 IT 部门和用户之间来回若干次的迭代反馈
- 数据需求的改变伴随整个定义阶段并持续演绎直到初期的部署阶段
- 希望快速将客户所需的数据提供给他们，以减少投资回报的时间
IFS 给用户带来的价值：
- 快速适应数据模型的变化
- 在需求改变时提供给用户真实的数据访问，以使得用户能更快地定义最终的数据需求
- 增加数据仓库的投资回报率
- 通过最小化数据移动过程中的变化降低成本
该架构中体现出 IFS 的功能：
- 部署数据仓库的过程不是线性的。决定最终用户需要的数据元素和模式是一个典型的迭代过程
- IFS 能快速地打造数据模式的原型系统。用户能很快地开始工作，IT 部门也可以很快的适应数据的变化，以加速整个数据仓库的设计过程
- 另外，IFS+Replication 对于来自数据源的、及时的、”trickle-feeding”的数据仓库十分有效。
图 5. 架构 5: 加快数据仓库模型设计
IFS 在本架构中解决了用户以下问题：
- 集成更多的数据源
- 最小化数据处理的执行时间
- 当有 2 个以及以上的数据源时，开发者不得不考虑一个最佳方案。
IFS 给用户带来的价值：
- IFS 作为 ETL 的数据预处理器，通过过滤、集成或者连结减少不需要的数据
- IFS 提供基于代价的优化器，能自动选择最佳的方案
该架构中体现出 IFS 的功能：
- T-ETL 意味着很多 ETL 的工作在提取数据 (Extract) 前已经进行了前期的转化（transformation），例如过滤和聚集数据，这样能够较早地减少冗余数据的流入。带有任务（如连结，合并，过滤和聚集）的数据合并（consolidation）场景几乎都可以从 T-ETL 的处理中获益。但是常规 T-ETL 的限制是，源对象必须存在同一个数据源上，而这点极大的限制了常规 T-ETL 方案的适用范围。
- IFS 消除了这个限制，而且将最初的转化阶段扩展到 IFS 所支持的异构数据源。从而带来了以下好处：
- ETL 工具最初不得不检索的数据集的大小被减少了
- 由于 DB2 优化器的强大功能，IFS 能够更广泛地利用优化技术，相对于在 ETL 内部执行初始阶段的工作，执行时间被减少，从而降低整个工作的执行时间和资源消耗。
图 6. 架构 5: 加快数据仓库模型设计
InfoSphere Federation Server 安装与配置
下面是 IFS 安装可以参考的相关资料：
系统需求：
http://www-01.ibm.com/software/data/infosphere/federation-server/requirements.html
硬件及软件需求：
安装指南：
图 7 展示了 IFS 安装的基本步骤：
图 7. IFS 安装步骤
在 Windows 系统中，用户首先通过 administrator 登陆并解压缩安装文件。然后运行 IFS 安装包中的 iisetup.exe 来通过 GUI 方式进行安装或者运行"iisetup.exe – options responsefile.rsp – silent"通过 silent 方式安装。
在 Unix 或 Linux 系统中，用户首先通过 root 或 non-root 用户登陆并解压缩安装文件。然后运行 IFS 安装包中的 ./iisetup 来通过 GUI 方式进行安装或者运行"./iisetup – options responsefile.rsp – silent"通过 silent 方式安装。
在安装的过程中，当到图 7 所示的步骤时，用户可以选择要安装及配置的数据源和对应的 wrapper。
图 8. 选择安装的 wrapper
安装完 IFS 后，通过以下步骤对系统进行配置：
- 配置节点及数据库
- 设置数据源所需的环境变量及配置文件
- 通过数据源提供的客户端测试与数据源的连通性
- 创建 wrapper
- 创建 server
- 创建 user mapping
- 通过 IFS 测试与数据源的连通性（之所以分开两次测试数据源的连通性，是希望在发生连接问题时分清是否与 IFS 相关）
- 创建昵称
在 IFS 的安装与配置过程中，有以下几点需要用户加以注意：
- IFS 的物理位置
由于 IFS 并不在本地数据库存储数据，当用户通过 SQL 获取数据时，IFS 需要与数据源进行交互，从而获取到用户需要的数据。所以大数据量的网络通信可能成为 IFS 应用的性能瓶颈。在资源充足的前提下，将 IFS 与其中一个数据源安装在同一台物理机器上将有助于提高系统性能。特别是如果 IFS 与该数据源有频繁的数据交互，这种配置的性能优势会更明显。
- IFS 的 code page
当 IFS 与数据源的 code page 不一致时，在获取数据的过程中会进行 code page 的转换，从而降低性能。在可能的情况下，用户最好将数据源与 IFS 的 code page 设置一致，从而避免引入 code page 转换的代价。
- 选择 MPP 还是 Serial 模式
根据应用场景，用户需要确定使用模式。IFS 支持 Serial, SMP 和 MPP。如果用户选择 MPP，最好同时选择 Fenced 模式。因为 IFS 只有在 Fenced 模式下，才能够针对从数据源获取到的数据利用 MPP 的并行性来提高性能。下面的链接包含了 IFS 并行性支持的具体信息。
在介绍性能调优的方法之前先介绍一下数据库性能模型的基本原理。在数据库性能模型中可以将消耗大概归结为以下三部分：
- CPU 计算
- 硬盘 I/O
- 网络通信
在 DB2 LUW Serial 及 SMP 模式中，CPU 计算及硬盘 I/O 会作为性能模型中重点考虑的因素。而且往往硬盘 I/O 比较容易成为性能瓶颈。而在 DB2 LUW MPP 模式中，性能模型则需要考虑节点间网络通信带来的消耗。这种消耗通常发生在各节点之间需要交互数据的时候。所以在 MPP 模式中需要考虑如何配置各节点的数据及合理创建表结构性从而减少网络通信带来的消耗。
而在 IFS 中，本地联邦数据库并不存储数据。所有的数据都要从数据源获取。这样网络通信的消耗就成为 IFS 性能模型中需要重点考虑的地方。而第 3 节中提到的将 IFS 与数据源配置在同一物理机器上从而提高性能就基于此。如果 IFS 与数据源无法配置在同一物理机器上，也应该尽量保证 IFS 与数据源间网络通信的速度足够快，因为这往往是 IFS 应用场景中的性能瓶颈。图 9 给出了 IFS 性能模型中要考虑的因素。其中蓝色字体的部分是与 DB2 相同的部分，红色字体的部分是 IFS 所特有的因素。
图 9. IFS 性能影响因素
在 IFS 性能调优的过程中需要考虑以下部分：
- 数据源与 IFS 间的数据通信量，这包含：
- 每次操作从数据源到 IFS 的数据量
- 数据源与 IFS 的交互次数
- IFS 所选择的执行计划
- 数据源所选择的执行计划
- IFS 及数据源所在物理机器的配置及网络速度
有一点经常引起用户混淆的就是 IFS 所选择的执行计划与数据源所选择的执行计划。用户通过 DB2 的执行计划生成工具 (db2expln/db2exfmt) 可以看到 IFS 所选的执行计划。其中 SHIP 操作符是本地执行计划与远程执行计划的分界点。在 SHIP 之上的部分是 IFS 本地的执行计划，而 IFS 会严格按照该计划执行。而 SHIP 之下的部分，是 IFS 按照 DB2 的性能模型估算的执行计划。但这不能确保数据源本身也会选择同样的执行计划。换句话说，数据源最终的执行计划有可能与用户看到的 IFS 选择的执行计划不同。这是由于各种数据源有不同的性能模型。当数据源与 DB2 越相似，则生成的计划越精确。
而 IFS 性能调优的重点就是降低数据源与 IFS 间的数据通信量。因为这往往是 IFS 应用场景中的性能瓶颈。本文后面的内容也将侧重于如何降低通信量。而 IFS 与数据源的执行计划调优可以参考 DB2 和具体数据源的性能调优手册。
数据源与 IFS 间的数据通信量取决于数据在各数据源上的分布情况以及多大程度地将谓词下推到远程数据源执行。其中前者可以调整的余地很小，而后者则可以通过各种方法进行优化。下面首先介绍 IFS 下推算法的原理。
由于 IFS 提供数据集成平台，它需要对用户屏蔽数据源的语法、语义及地理位置的差异。这就使得它必须遵守统一的语法和语义，而这就是 DB2 的语法和语义。而为了做到这一点，IFS 必须保证无论 SQL 是在本地执行还是下推到数据源执行，最终返回给用户的结果必须相同。而且在结果一致的前提下选择性能最优的执行计划。由于有上面的需求，就要求 IFS 必须知道以下信息来选择最终的执行计划：
- 数据源是否有支持相应操作的能力
- 数据源相应操作的语义是否与 DB2 一致
- 下推操作是否能够带来性能的提高
而 IFS 的性能调优也是基于上述原理展开。下面将具体介绍经常用到的方法及技术。
在 IFS 中如何确定数据源是否有支持相应操作的能力及相应操作的语义是否与 DB2 一致，这是通过设置 Server, nickname 和 column 选项来完成的。目前 IFS 中有超过两百个选项来标识数据源与 IFS 的异同。而处于不同级别的选项其影响范围也不一样。Server 级别的选项将会影响所有涉及到该 server 下 nickname 的 sql。而 nickname 级别的选项只会影响到涉及该 nickname 的 sql。column 级别的选项则只会影响该 column 对应的操作。下面链接包含了各种数据源对应的选项。
由于涉及到实现细节，并不是所有的选项都对用户公开。但针对各种数据源，IFS 都对选项值进行了定制。所以除了上面链接中提到的选项外，用户通常可以不需要考虑如何设置选项值。但是 ODBC 和 JDBC 数据源是例外。由于 ODBC 和 JDBC 可以用于所有支持 ODBC 和 JDBC 标准接口的数据源，故 IFS 无法对其选项值进行定制。除了上面链接中提到的选项外，用户可能还需要设定其他选项值来达到预期的性能。用户可以要求 IFS 服务团队针对其数据源进行针对性调优。
函数模版及函数映射 (Function templates/mappings)
IFS 如何将 DB2 SQL 翻译成数据源支持的 SQL，其中重要的一部分就是通过函数模版及函数映射来完成的。当 DB2 中函数在数据源中也有对应的函数时，可以通过创建函数映射来告诉编译器如何将 DB2 函数翻译成对应的数据源函数格式。而函数模版用于当数据源中函数在 DB2 中没有相对应函数。这时需要根据数据源函数语法在 DB2 中创建一个函数模版，然后基于函数模版和数据源函数创建函数映射。需要注意的是函数模版本身没有具体实现，对应的函数必须要下推到数据源执行，否则 DB2 会报错。如果编译器无法找到对应的函数映射或模版，则对应的函数无法下推到数据源。如果该函数对应的是谓词，这往往会带来 IFS 与数据源间传输数据量的增加，从而降低性能。
与 4.1 中的选项相同，IFS 针对各种数据源都定制了对应的函数映射。这包含了大部分 DB2 支持的函数，所以用户一般不需要再额外创建函数映射。而 ODBC 和 JDBC WRAPPER 同样可能需要用户针对性的创建函数模版或函数映射来提高性能。
下面的链接包含了函数映射及函数模版的细节信息。
与 DB2 一样，准确的统计信息对于编译器生成最优的执行计划十分关键。在 IFS 中，统计信息也是在存放在 sysstat.tables, sysstat.columns 及 sysstat.indexes 中。NNSTAT 是 IFS 中用于更新统计信息的工具。用户需要周期性的运行 NNSTAT，从而保证 IFS 中的统计信息能够反映最新的数据分布情况。下面的链接包含了 NNSTAT 的具体信息。
IFS 支持 MQT。本文一直强调 IFS 并不将数据存储在本地，而是在需要的时候向远程数据源获取，但 MQT 是唯一的例外。MQT 通常基于一个复杂而费时的 SQL 创建，并将该 SQL 的结果储存下来。当优化器判定后续 SQL 或其中的一部分子查询能够匹配该 MQT 时，将会直接应用 MQT 内储存的结果而不是进行重新计算，这经常会带来巨大的性能提升。
而这种技术对于 IFS 这种信息集成平台而言，其带来的收益往往更大。因为 IFS 的 SQL 或 SQL 的一部分需要到数据源执行，而且对应的数据要通过网络传输，这所带来的时延通常会比本地执行 SQL 要大得多。而使用 MQT 就可以解决上述问题。另外一个好处就是当其中一个远程数据源发生故障时，基于 MQT 的 SQL 仍然可以继续执行，而普通的联邦 SQL 则无法获取结果。
需要提醒的是，MQT 带来性能提升的同时所带来的一个负面效果就是数据的实时性无法保证。而数据的时延取决于 MQT 刷新的频率。下面的链接包含了如何在 IFS 中使用 MQT 的具体信息。
利用物化查询表提高 WebSphere Information Integrator 的性能
从版本 9.1 开始，IFS 支持调用定义在远程数据源上的存储过程。而联邦存储过程的引入，带了一种新的提高性能的方法。其原理与本文所描述的一样，通过降低 IFS 与远程数据源间交互的次数，从而降低二者之间的通信量。当然，性能提高的前提是存储过程中存在多条需要在远程数据源执行的 SQL。下面的链接包含了如何在 IFS 中使用联邦存储过程的具体信息。
在 WebSphere Federation Server V9.1 中使用联邦过程
4.6 索引声明 (Index specification)
之所以需要索引声明是由于针对有些对象的 nickname 无法获取索引信息，如视图 (view), 同义词 (synonym) 等。而且目前 IFS 并不支持获取新增索引信息。也就是说当用户在远程数据源的表上新增一个索引，在 IFS 中对应的 nickname 无法直接获取该索引信息。用户只能删除该 nickname 并重新创建。这可能会对基于该 nickname 的其他对象及应用产生影响。用户可以通过在该 nickname 上根据远程数据源上新增索引的定义创建一个索引声明来让编译器识别可能的 index scan 的机会。
需要强调的是，创建索引声明只是在全局 catalog 中增加了一个索引定义，在 IFS 中并没有物理索引与其对应。而且 IFS 并不会真正到远程数据源上核实是否有该索引存在。所以用户在创建索引声明前应确认数据源上确实存在对应的索引，否则容易误导 IFS 生成错误的计划。尤其是当索引声明被定义成 unique 时。下面的链接包含了 IFS 中索引声明的具体信息。
在 IFS 版本 9.1 中引入了一个新特性，它支持在 Union, merge join 等场景中，将串行的联邦查询操作并行化，从而提高性能。
以 union 为例子进行一个简单介绍，在版本 9.1 之前，如果 union 下面的各分支涉及到多个数据源的子查询，IFS 会串行的完成 union 操作。也就是说它会等待第一个分支的子查询完成后再启动第二个子查询，依次类推来完成 union 操作。而在版本 9.1 中，IFS 支持并行的执行各分支的子查询，并将最终结果汇总。由于 union 操作本身对各分支的执行顺序没有要求，所以实现并行是可行的。下面的链接包含了 IFS 中并行执行联邦查询的具体信息。
在 WebSphere Federation Server V9.1 中异步执行联邦查询
由于 IFS 是基于 DB2 实现的，所以 DB2 的调优方法大多也适用于 IFS。下面的链接包含了 DB2 性能调优的最佳实践。
最后通过两个案例分析来结束本文。在遇到性能问题时，一般通过以下步骤来进行分析：
- 通过 db2exfmt 来得到执行计划并分析该执行计划是否与预期相同。其中最重要的就是 SHIP 操作符的位置。它是本地执行计划与数据源执行计划的分界点；
- 如果执行计划不符合预期，尝试上面介绍的调优方法；
- 如果上述方法无法解决问题，收集相关信息并要求 IBM 技术支持。
图 10 是一个单数据源性能调优的案例。该案例是在进行 IFS 性能测试时，发现用 IFS 执行 SQL2 的时间是使用 Oracle 客户端直接执行时间的 2.5 倍，而其他 SQL 的性能差别不大。
图 11 是 SQL2 的执行计划。以 SHIP 作为分界点可以看到，5 个表的连接操作已经下推到了数据源执行。而 LIKE 对应的谓词和排序操作留在本地执行。而且可以看到经过 FILTER(4) 后，结果集行数减少了大概七千行。也就是说如果 LIKE 对应的谓词能够下推到数据源执行，将会极大减小 IFS 与数据源间的数据交互量。而排序操作放在本地与数据源执行通常不会有太大的差别，这通常与机器的性能及数据库配置有关。通过分析，可以看到性能的瓶颈所在。而 LIKE 之所以不能下推，是由于 DB2 和 Oracle 的语义不能保证一致。如果用户希望下推该谓词，可以联系 IBM 支持团队，在保证数据符合某些条件时，有条件的下推 LIKE 谓词。
可以看到，当 SQL 能够完全下推，返回的数据量适中而且在数据源执行的时间较长时，IFS 的性能与直接用客户端执行的性能相差不大。但是当 SQL 无法完全下推从而导致大量的中间结果需要返回给 IFS 时，其性能会大幅下降。在有些情况下，IFS 可能会重写或在本地选择一个更好的执行方案从而能够达到比直接通过数据源客户端执行更好的性能。
图 10. 单数据源案例
图 11. 执行计划
图 12 是一个多数据源性能调优的案例。在图 13 中包含了查询 #1 及查询 #2 在表 ORDERS 和 CUSTOMER 分布在两个 Oracle 数据库中所生成的执行计划。并且比较了当 ORDERS 和 CUSTOMER 分布在两个 Oracle 数据库与 ORDERS 和 CUSTOMER 位于同一 Oracle 数据库时的性能。可以看到查询 #1 在两种情况下的性能差距不大。但查询 #2 则存在很大的差距。原因在于 SHIP(5) 和 SHIP(7) 都会产生大量的中间结果需要从数据源传输到 IFS，从而带来巨大的网络通信消耗。
通过上面的分析，用户可以得到结论：在实时性要求不高的前提下，MQT 技术可以极大的提高查询 #2 的性能。
图 12. 多数据源案例
图 13. 执行计划及时间
学习
-
在 Information Management 专区 “InfoSphere Federation Server 专题”，
学到更多关于联邦数据库的知识。还可以找到技术文档、how-to 文章、培训、下载、产品信息等。
- 查看
DB2 V9.7 信息中心，了解 DB2 V9.7 产品的详细信息。
- 通过
使用 WebSphere DataStage 和 WebSphere Federation Server 的一种灵活数据集成架构，了解 WebSphere DataStage 和 WebSphere Federation Server 的集成技术。
- 通过
利用物化查询表提高 WebSphere Information Integrator 的性能，了解如何利用物化查询表提高性能。
- 通过
WebSphere Information Integrator V8.2 中的并行性，了解 WebSphere Information Integrator V8.2 中引入的一些关键性能增强。
- 通过
WebSphere Federation Server 中新功能的性能特征，了解一些专门为提高产品的易用性和通用性而设计的新特性。
- 通过
在 WebSphere Federation Server V9.1 中使用联邦过程，了解如何创建和调用联邦过程以及如何诊断和避免某些最常见的问题。
- 通过
DB2 最佳实践: 编写并调试查询语句以优化性能最佳实践，了解最小化 SQL 语句对 DB2 数据库性能影响的最佳实践。
获得产品和技术
- 下载
IBM 软件试用版，体验强大的 DB2®，Lotus®，Rational®，Tivoli®和
WebSphere®软件。
讨论
- 参与论坛讨论。
- 查看
developerWorks
博客的最新信息。
内容
标签
使用 滑动条 调节标签的数量。
热门标签 显示了特定专区最受欢迎的标签（例如 Java technology，Linux，WebSphere）。
我的标签 显示了特定专区您标记的标签（例如 Java technology，Linux，WebSphere）。