informatic 使用注意事项 博客分类： BI informaticabi

以下是一个朋友的总结：

关于Informatica Performance有如下建议：

 

1.对于Source Qualifier中的复杂SQL简化，拆分，通过在Mapping中使用Transformation来实现。例如在Source Qualifier中复杂的Union All SQL语句，可以在Mapping中通过Union组建实现，可以提高50%以上的性能。

 

2.尽可能的本地化。将所有的目标表放到ORACLE的同一个实例中（相同的SID）。对任何处理都不要使用同义词（远程数据库连接），包括LOOKUP、存储过程、目标表、数据源、函数、权限等等。远程连接的使用会使得处理变得很慢，数据库的远程使用会使性能产生很显著的降低。

 

3.尽可能的使目标表、存储过程、函数、视图以及序列都放到数据源的本地。同样，不要通过同义词进行连接。同义词（远程数据表）可能会使性能降低3倍甚至更多。

 

4.尽量减少基于数据库的序列。因为基于数据库的序列生成器需要一个wrapper的函数和过程调用。使用这样的过程会对使得性能降低3倍左右。

 

5.SESSION的日志会对整个MAPPING的性能产生极大的影响。在SESSION里面去掉“覆盖”（over-ride），将生成日志的属性设置为正常日志模式。在INFORMATICA的内部，日志记录并不是一个并行的机制，而是直接安排在操作的进行过程中。

 

6.尽量不使用无缓冲LOOKUP。使用无缓冲LOOKUP时，性能会受到显著的影响，尤其是如果LOOKUP的表是一个可增长或者是可更新的表，一般来讲这样的表在整个操作过程中它的索引是会发生变化的，因此优化器就无法利用索引的统计信息。同时，尽可能使用临时表，此时数据库中的视图可以将相关的数据关联起来，或者可以利用INFROMATICA的JOINER对象来关联数据，这两种都可以明显的提高数据处理速度。

 

7.分离复杂的MAPPING。试着将整个MAPPING分成一个个逻辑处理单元。如果需要进行并行的处理，重新进行体系结构的设计和布局。通过小的组件来处理单个的任务，可以提高整个处理过程的并行度。

 

8.确保在PMSERVER的机器上有足够的SWAP交换空间和临时空间。如果没有足够的磁盘空间，会导致处理性能成指数级的速度降低。因此可能需要在SESSION运行的时候监控磁盘空间，否则无法得到在操作过程中磁盘空间的变化情况，在MAPPING中含有AGGEGATOR、有缓冲的LOOKUP或者含有不同数据源的数据关联的操作的情况，更是有必要这样做。

 

9.变量端口比输出端口要慢，减少变量端口的使用。变量会对经过EXPRESSION控件的每条记录都要进行分配/重新分配的操作，会增加处理时间。

 

10.去掉没有使用的端口。虽然没有使用的输出端口对于性能没有什么影响。然而，一般来讲，删除那些在 MAPPING没有使用的端口（包括变量）是一个好习惯。这样更加方便于数据的测试和修改。

 

11.大量嵌套的IIF函数对性能的影响不小的。如果有可能，通过重新设定逻辑来避免IIF函数的使用。因此尽可能的避免的使用IIF函数，而唯一可能替代IIF函数的方法是在SQL中使用ORACLE的DECODE函数。

 

12.IIF条件判断比IS_NUMBER要快一些，因为IS_NUMBER需要解析整个字符串。

 

13.UPDATE表达式，将SESSION的属性设置为UPDATE ELSE INSERT。如果已经这个开关打开的话，会导致SESSION的运行速度明显的下降，因为INFORMATICA对每行记录都执行两个操作：更新（根据主键），如果返回的结果时更新了0条记录，再执行一个插入操作。改变这种情况的办法是，提前知道在MAPPING中要执行的是DD_UPDATE，还是DD_INSERT，然后告诉UPDATE控件采用什么更新策略。接下来你可以改变 SESSION的属性为INSERT/UPDATE AS UPDATE/UPDATE AS INSERT。

 

14.同时写入多个目标的速度很慢。通常MAPPING会产生多个数据目标，有时会有多个数据源。这样的结果是更加花费时间，如果体系结构允许改变，同时用户也能够对 MAPPING进行调整，那么尝试着对体系结构进行修改：一个数据目标一个MAPPING是基本的标准。

 

15.尽量减少Lookup、Sorter、Joiner控件的个数。如果有 LOOKUP控件，在内存中会占用大量的缓冲，最终的结果是没有其他的内存用来供SESSION的运行而使用。

 

16.对性能进行测试的时候，建议使用 20万条记录左右的数据源进行处理。使用比之更大数据量的测试数据源，可能会产生因为表的分区、删除和重建索引、RAID数据条带化等问题数据库相关问题导致性能下降的问题，而如果使用的数据源的集合太小，统计出来的平均处理时间可能会因为数据库吞吐量、主机负荷以及网络流量等因素的影响而变得不稳定。 20万条记录的集合一般是进行准确统计的比较理想的测试数据源。