informatic 使用注意事项

以下是一个朋友的总结:

关于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的表是一个可增长或者是可更新的表,一般来讲这样的表在整个操作过程中它的索引是会发生变化的,因此优化器就无法利用索引的统计信息。同时,尽可能使用临时表,此时数据库中的视图可以将相关的数据关联起来,或者可以利用INFROMATICAJOINER对象来关联数据,这两种都可以明显的提高数据处理速度。

 

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

 

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

 

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

 

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

 

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

 

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.尽量减少LookupSorterJoiner控件的个数。如果有 LOOKUP控件,在内存中会占用大量的缓冲,最终的结果是没有其他的内存用来供SESSION的运行而使用。

 

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

猜你喜欢

转载自star1989.iteye.com/blog/1452248