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,请求