ODI的性能优化策略

应用：

Oracle Data Integrator - 版本: 3.2.03.01 及以后发行的版本

本文档的信息可以应用到任何平台

目的

解决ODI的数据集成问题可能会引起关于如何最好的实现性能和可扩展性的问题

ODI通常很快的事实主要是因为ODI的E-LT体系结构利用了本地的DBMS SQL和本地的DBMS实用程序，像散装装载机、卸载机和复杂的基于组转换

本文档倾向于回答一些性能和可扩展性的问题，叙述最优方案

最后审核日期

使用说明

提供一个检修向导帮助调试指定问题。测试工具包含在文档里，用来帮助解决问题

解决问题细节

最优集成接口

其中最费时的操作是在服务器和计算机之间移动数据

第二耗时操作是加入数据集

使用一个知识模块技术可以显著地改变性能：

JDBC驱动程序和数据库访问本地加载器

     INSERT.SELECT 和SELECT.INSERT

如果数据库里有个知识模块，应该选择从数据库细节获益的那一个

优化器提示技巧

多重事务级别

委托政策

    集成接口设计要点：

1.减少服务器间数据移动

正确定位数据缓冲区

数据缓冲区通常位于目标服务器上，但是在某些情况下，将数据缓冲区移到另一个资源服务器上会明显减少大量的数据转移

例如：如果一个集成接口聚集大量的源数据，在一个远程目标上产生一个小的数据流，那么就应该考虑将数据缓冲区定位于其来源

正确定位转换-过滤器、连接和映射

应该根据引擎的功能能力和CPU速度来设置转换的位置，同时也要减少数据流的容积

例如：

i）在过滤源数据时，推荐在源服务器上执行过滤器，来减少从源服务器到数据缓冲区的数据流

ii)连接源表时，如果由连接产生的预期来源集比两者总和的来源稍小，那么连接就应该在其源服务器上执行。如果在连接后，预期的来源集比两者总和的来源稍大，那么连接就应该在数据缓冲区执行，比如在交错连接的情况下。这也适用于聚集源数据来减少传送到数据缓冲区的数据总量

使用编制分录/改变数据捕捉特性

这特性能用来减少源数据的量，通过减少流量来改变数据

在触发器或者数据库日志的基础上，ODI提供两种方法来捕获更改

这方法能引起较少的操作源开销

2.选择最好的加载策略来加快移动

这方法用于将一个数据集从一个服务器上移到另一个服务器上。该方法是由源数据集选择的加载知识模块所决定

ODI使用树方法来传输数据：

i）通过代理数据流动

ii）通过加载器数据流动

iii）特殊的方法

这些方法能够和用同样的集成接口从不同的服务器上提取数据的方法结合起来

通过代理数据流动

通过代理数据流动时，通过批记录来读源连接，并且写入目标

下面的参数能够帮你调谐数据流：

在源数据服务器里组获取的定义

这参数定义了每次在源服务器上阅读的批记录的大小，并且存储在代理里

在目标数据服务器里批量更新的定义

这参数定义了写入目标服务器的批量记录的大小

注意组获取和批量更新是java参数，详情请看：

注释424482：批量更新和组获取值是如何影响ODI进程的性能？

大组获取/批量更新的值会有以下影响：

相同行数会减少批量阅读，因此要减少由客户端/服务器通信所引起的开销

批量更新/组获取的配置是网络和代理开销之间的平衡

在高度可利用的网络里，可以保留较低的值（比如<30）

在较差的网络里，可以使用较大的值（100及以上）

组获取/批量更新的范值在30到500之间

使用通过增加10或者减少10的实际方法和检查执行观察所引起的变化，为源服务器和目标服务器修改组获取和批量更新

通过加载器数据流动

当加载器用来传输数据时，代理将工作委托给局部的加载程序，像SQL加载器、Microsoft SQLServer BCP BCP等

通常，数据被系统的本地加载器提取到文件里，这文件就被复制到目标计算机上，然后使用本地目标装载器下载

装载机要求安装在运行代理的计算机上。有可能使用一个叫做OdiSQLUnload的卸载命令的ODI内置

装载机通常提供最好的性能去从数据库里提取或者插入大容量的数据。使用这些装载机的知识模块通常能够以最快的速度完成装载机指定的性能

注意：在卸载每一列记录时，OdiSQLUnload工具提供较好的性能。因此推荐将列和分隔器作为一个在数据库引擎执行的转换聚集起来

特殊的方法

这些方法包括指定的引擎下载方法：

通过类似于oracle数据库连接或者微软SQL服务器连接的服务器技术来进行服务器之间的通信

文件表加载特殊的方法，比如oracle外部的表

创建AS/400 DDM文件，通过CPYF指令下载数据

通过UNIX管道代替大量的文件来使用卸载机/装载机方法

下载策略的选择通常受技术局限性的限制：

你能在磁盘上创建一个临时文件吗？

你能够访问运行代理的计算机上的装载机吗？

DBA允许创建DB链接吗？

运行代理的计算机支持管架吗？

带宽是什么？

多少 CPU/RAM能够合理的被代理使用？

通常，推荐使用KMs实现最优性能，KMs会平衡两个源目标技术的大部分本地指定的性能

例如，从oracle到oracle使用一个SQL到SQL策略不是个好方法，因为有些方法快好几倍，像DBLINKS 或者 SQL*Loader

3.执行大型的最优化连接，正确定位它们

在数据集成里，连接是第二耗时的活动

每个引擎的连接能力不同

关键是要定位服务器上有最优能力的连接，并且大部分CPU是可利用的

通常最好的选择是在大部分CPU可用的服务器上有一个数据缓冲区，并且有连接运行在这个数据缓冲区上

对于参与转换的连接，ODI能够产生SQL，为这些SQL问题分析基础数据库执行计划，能够帮助调谐一个集成接口到更好的性能

理解那些能够以更好的性能代替转换的连接也是很重要的

例如，一个像这样的过滤器：

TABLE1.COLUMN1 in (SELECT COLUMN2 from getObjectName(TABLE2)) 你呢个够被TABLE1.COLUMN1 和 TABLE2.COLUMN2之间的连接代替

4.集成数据的策略

阻止无用的连接，通过选择适当的集成策略来加快数据集成

集成策略要求的操作序号是和集成策略的复杂度直接相关

在处理大量数据时，避免使用不必要的复杂的IKMs

常见不必要操作的例子：

和DELETE TARGET 和 INSERT选项一起使用一个递增的更新知识模块。用一个受控制的附加知识模块来代替，与使用更好的性能有相同的结果

当副本不合理时或者由不正确的定义连接所导致副本记录时，检查集成的DISTINCT 选项。对于数据引擎来说，执行一个DISTINCT 是个耗时操作

5.检查完整性的策略

通过移除无用的数据完整性检查来加快数据集成

在一个数据完整性进程中，检查约束的序号会增加更多操作。因此要减缓全面的集成进程

当处理大量数据时，要避免使用无用的检查

如果这是你数据集成进程的要求，那么只有选择流控制选项了，因为这步对性能会有很大的影响

不必要操作的例子：

在一个集成链里，对已经改变的数据检查三次

最优运行时间

通过代理配置可以调谐最优执行时间，负载平衡和适当位置

1.    适当的定位代理

在选择位置时要注意以下事项：

限制网络的开销

通过JDBC读大量的数据时，在包含数据的服务器上有个代理是比较好的。该服务器和已载入的服务器本地连接，替代远程连接

如果有重要的大量数据被下载，在源服务器上设置一个代理

如果在目标区有重要的转换执行，在目标服务器上设置一个代理

在处理大量文件时，在运行集成接口之前，在运行代理的服务器上将文件进行备份。注意这步可能会集成到一个ODI情境中，例如SnpsFTP, OdiFileCopy

限制计算机开销

如果代理必须让数据流通过它，则它不应该安装在没有多余资源的计算机上

在odiparams配置文件里可以调节 ODI_INIT_HEAP 和 ODI_MAX_HEAP参数，定义初始的代理JVM和最大化堆

配置批量升级和组获取参数

利用数据库实用程序(SQL*Loader, exp/imp, Fastload, Multiload, TPump, Bulk...).

在同一个计算机上设置代理，来利用数据库实用程序

一个典型的例子就是，在源服务器上使用OdiSqlUnload 工具来创建临时数据文件时，代理设置在哪是很重要的。临时数据文件稍后会被本地加载机下载到目标服务器上

这种情况下，它是和源服务器上有代理运行相关

如果它位于目标服务器上，它将通过网络使用JDBC来转换所有的数据

注释：

代理是多线程的

监听不同TCP/IP端口的多重代理会和同一个服务器并行。因为这使计算机上的资源加倍，无用的服务器不是多线程的，要避免这样的情况

2.使用负载平衡

ODI能和多重代理一起配置负载平衡

负载平衡是通过几个代理上的会话执行来提供最优性能。当一个代理和已经定义的代理连接时，它会自动的分配这些代理的会话执行

负载平衡在会话的创建和执行上是分开的。如果你想使父代理来管理一些会话，而不分配会话，那么它必须和本身相连

3.设置执行日志级别

在生产环境里，将日志级别设置为1，在这种情况下只有错误会被报告

处理性能问题

如够有性能问题：

1.进入ODI操作，找出哪步最耗时

2.复制代码，在数据库上直接运行它，这可以让你比较两种执行的时间

1.复杂的SQL代码处理一排排的数据

通常，本地的程序语言SQL代码处理一排排的数据是违反语法的

可以通过使用集成接口来避免这样的代码，或者，如果已经调用SQL代码完成了这操作，那么要用DBA来调谐SQL

2.JVM的版本和JDBC驱动程序的版本不一致

ODI是与JVMs和JDBC驱动程序的各种版本一致

使用一个和java计算机或者数据库版本不一致的JDBC驱动程序会导致不同的执行

例如：一个在Oracle 11g的集成接口装载 Microsoft SQL Server 2005 表。有时候，执行很快，但是其他时候又很慢，并且下载数据这一步花很长时间。这是因为 Microsoft SQL Server 2005 和Oracle JDBC驱动程序是：

与用来运行ODI流的JVM不一致

与包含数据的数据库版本不一致。

记住不建议一起使用：

版本1.2 的Microsoft SQLServer 2005 JDBC 驱动程序 和 一个 JVM 1.5或最近的版本

一个JDBC驱动程序ojdbc14.jar和JVM 1.5或最近的版本

版本10.x 的Oracle JDBC 驱动程序和一个数据库11g.