Informatica性能调优(初级)

DBA对最坏情况下的数据库进行调优。帮助DBA估计哪些表会被进行大量的读写、什么处理会进行排序等占用数据库资源的操作，然后考虑将那些表放置到合适的物理磁盘上，这样会取得很好的效果。利用PERL脚本生成“假数据”来生成各种容量的测试集合，以此来检验MAPPING的加载性能，DBA就会根据这些情况来进行数据库的相关参数的调整。

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

15、在开发的过程中，在服务器上运行一些加载监控工具，以便更清楚相关的资源是如何被使用的，什么是热点资源。要遵循这些建议，因为有可能需要升级硬件设备来达到预期的处理能力。虽然价格比较昂贵，还是建议考虑EMC的磁盘存储阵列，因为它的处理速度相当的快，我听说（并没有确认）在某些情况下可以把性能提高50％左右。

16、设置SESSION。SESSION的属性中有很多可以用来调优。通过设置“Collect Performance Statistics”属性可以获得在MAPPING运行期间的一些性能方面的信息，从而可以对SESSION的其他属性进行修改，或者对数据库的参数进行调整，最终实现平衡的目的。仔细的阅读INFORMATICA联机文档中的调优手册。需要实现的基本目标是：读优化、处理优化、写优化。这三部分的过度优化可能最终导致SESSION的运行速度下降。例如，写速度受制于读的速度以及INFORMATICA的处理速度，反过来，读的速度又受制于INFORMATICA的处理速度和写的速度。调优一个有问题的MAPPING的最好方法是把他分成几个部分分别进行测试：1）读的处理，调优READER，检查相关的配置是什么，把读出来的数据输出到平面文件，以减少冲突。检查“ThrottleReader”参数（默认是不被设置的），用64K/slot的因子来提高默认的Buffer Size，不要考虑最高128K的警告。如果READER在SESSION运行过程中仍然是在开始的时候增长、但是在几千条数据后速度就稳定下来的情况，那么把Shared Session Memory从12MB提高到24MB，如果READER的速度仍然稳定不增长，那么MAPPING面对的就是一个比较慢的数据源、比较慢的LOOKUP或者缓冲区不是在本地磁盘。如果READER越过了它一直稳定的那个速度，记录下来此时的SESSION的设置。检查性能统计数据确保此时的WRITER不是瓶颈，因为此时是进行READER的性能调优，肯定不希望WRITER进程降低了READER的速度。然后将目标从平面文件改回到数据库，再次运行SESSION，记录下来READER的速度降低了多少，最优化的性能是在向平面文件中写入时的读取速度。这时，较慢的目标就是问题所在。注意：如果在向平面文件中写入的时候READER都不是很快，就要做一些基本的MAPPING调优工作了。尽量的合并EXPRESSION控件，设置LOOKUP为非连接的（如果可能就复用该LOOKUP），检查AGGREGATION和LOOKUP中的索引和数据缓冲区的大小。如果目标的写入速度比较慢，把MAPPING修改为一次写入一个目标表，然后可以找到引起写入速度慢的那个目标表，然后进行调优处理。对原始的MAPPING进行复制，然后将复制后的MAPPING进行分解。一旦发现了写入速度慢的目标表，请求DBA对表进行分区、更新表的统计数据、在数据加载过程中删除索引等等，有许多关于数据库的事情可以做，从而达到调优的目的。

17、将PMSERVER的机器上的所有其他应用都移走，处理数据库、临时数据库和数据仓库本身。PMSERVER可以和关系型数据库配合的很好，但是和其他的应用服务器配合的就很差，尤其是JAVA虚拟机、WEB SERVER、Security Servers、application SERVER以及Report servers。所有的这些应用都应该移到其他的机器，这一点对提高PMSERVER的机器的性能是非常关键的