Informatica性能调优(初级)

debug来发现，它仅仅是在写入数据库的列时才引起速度的降低。先复制这个MAPPING，然后改调用上面提到的存储过程为调用INFORMATICA本身提供的内部序列发生器，这样的运行结果是这个MAPPING所能得到的最快的运行结果。如果你必须使用基于数据库的序列发生器，那么最好遵循临时表的使用建议。如果你处理的是GB级或者是TB级的数据量，这样会节省很长的调试时间。如果你必须使用一个共享的序列发生器，那么根据平面文件（flat file）建立一个临时表，加入一个SEQUENCE ID列，然后调用一个属性为POST TARGET LOAD的存储过程来生成那个列。把这个属性为POST TARGET LOAD的存储过程放到那个从平面文件导入临时表的MAPPING中去（译者注：这一句话与前面的一句所表达的意思相同）。数据库里面存储过程的一次调用，紧接着是一个分配序列的批量操作，是处理这用共享的序列发生器的最近的方法。

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

8、关闭“收集性能统计”开关。如果开启这项功能也会对性能产生影响——虽然有的时候这种影响很小——因为它会把一系列的与性能相关的数据写入到性能日志中去。关闭这项功能会减少操作对与平面文件操作的依赖性。然而，在进行调优的过程中，开启这项功能又是非常必要的，它能发现一些reader和writer线程在速度方面的一些问题。

9、如果你的数据源是平面文件，使用临时表（参见本网站的临时表的相关幻灯片）。这样的话，你就可以使用SQL*Loader、BCP或者其他的数据库的并行装载的功能。只把那些简单的处理逻辑放置在数据源的加载MAPPING中，不要加入那些编码的查询和转换逻辑。如果在这种情况下，你的reader仍然比较慢，请从如下两方面进行检查：1）如果在你的产品注册信息或者配置文件中设置了ThrottleReader参数来限定最大的读取数据块的话，就会限制读取的速度（仅仅是在SESSION处理带约束的装载事务时明显存在问题的情况下，才进行这样的参数调整）；2）把平面文件移动到本地磁盘上。尽量不要从网络或者是磁盘阵列上读取平面文件。大多数的磁盘阵列处理速度是很快的，但是INFORMATICA是个例外，而读取本地磁盘就非常的快。需要指出的是，连接（LINK）并不能提高速度，必须是将文件本身存储在本地磁盘上

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

11、分离复杂的MAPPING。试着将整个MAPPING分成一个个逻辑处理单元。如果需要进行并行的处理，重新进行体系结构的设计和布局。通过小的组件来处理单个的任务，可以提高整个处理过程的并行度，相关的细节请参见关于方法的讨论。

12、平衡，在INFORMATICA、SQL语句和数据库之间取得一种平衡。要充分利用数据库的特长：读、写、排序、分组、过滤，利用INFORMATICA来处理复杂的逻辑：外关联、数据继承、多数据源处理等等，这种平衡需要DBA的帮助来实现。为了达到这种平衡，需要根据各自的优势重新组织整个数据处理过程，利用数据库的处理能力并不是降低ETL工具的作用，相反是ETL工具的处理能力的加强，并且是进行大数据处理过程调优的必备条件。

13、调优数据库。要考虑不同数据集合的大小（包括小规模数据量、中等规模数据量、大量数据以及超大规模数据）对数据加载的时间的影响，并将这些信息提供给DBA，请求