转自：http://informatica.iblog.com/post/3070/384539
大多我们运用的工具都会提到一个共同的问题------性能调优。什么是性能调优，每个人都有自己的一个定义，我比较喜欢的一个定义就是：性能调优就是尽力去消除系统中存在的性能瓶颈。这是一个循环往复的过程，首先找到性能瓶颈，然后采取各种方法尽力消除它，然后寻找下一个性能瓶颈，然后消除它，循环往复，直到性能达到预期目的为止。比较喜欢这个定义在于它告诉我们，性能调优没有一个最终的答案，每一次优化只要达到我们的期待的结果即是优化完成。
性能优化应该从整个系统上去规划，使系统能有一个理想的性能平衡。换句话说就是使系统中的各个部分：应用软件、数据库、硬件资源共同达到一个性能的最优化，让各部分资源能用自己最擅长的一面最大程度的提升系统性能，最终达到一个系统级的性能平衡。
在此我们将对Informatica性能优化做一个系统的介绍，而其中也在一定程度上运用系统性能平衡的规则进行调优指导。在此我们将按调优的一个通用的顺序进行介绍，或者说是一个调优Guideline, 即首先定位性能瓶颈，其次进行性能调优，最后介绍一些调优经验。
一、 性能瓶颈
性能调优时，首要的任务即是确定性能的瓶颈所在。在对Informatica进行瓶颈确定时，我们应首先排除是否特殊情况，即从当时网络、数据库、服务器是否运行正常、是否忙等情况排除，当确认是普通情况后，我们便可以按以下步骤进行性能瓶颈确定。
1． Target
确定瓶颈是否发生在ETL中的L上。
在做Informatica调优过程中，我们发现绝大部分的系统瓶颈都会发生在
Informatica的写目标数据库这个过程中。对于我们大部分的系统来说，我们的目标均是数据库系统，此时我们可以在Session中将目标写方式直接改为File Writer，而此时如果系统性能得到了显著的提高，那我们可以确定写Target是我们的一个系统瓶颈。而如果系统性能没有什么提高，那说明写Target不是瓶颈，需要从其它方面确定瓶颈。
Thoughput 这是一个结果值, 它是每秒L的条数, 但并不代表L的Performance.问题.
2． Source
确定瓶颈是否发生在ETL中的E上。
当确定写Target不是系统瓶颈后，我们可以查看是否瓶颈发生在读时。我们可以按以采用以下几种方法来进行确定。
1）在每个 Source Qualifier后增加一个Filter Transformation，并把Condition设置为False.，并比较修改前后的运行时间，如果前后运行时间没有什么变化，则我们可以确定读Source是瓶颈。
2）把Mapping 复制出一个新的Mapping，修改为一个只有读操作的Mapping，删除Mapping中所有其它的Transformation，并把目标改为Flatfile，如果运行时间和之前的Mapping差不多，那我们可以确定读Source是瓶颈。
3）最简单且最直接的方法，在Source Qualifier中把SQL 拷贝出来，直接在PL/SQL中运行，并把其运行时间与Mapping运行时间进行比较，如果两者运行时间差不多，那我们可以确定读Source是瓶颈。
4）Throughput(Rows/Sec)
3． Mapping
确定瓶颈是否发生在ETL中的T上。
当我们经过L，E两个过程的确认后都没有发现瓶颈问题，或者说这两个部分
的性能调优存在很大的困难或者需要很大的代价，我们可以考虑进行T的性能调
优。所谓T 也即我们所指的Mapping 调优。
Mapping的性能瓶颈确定相对来说比较复杂。因为其涉及了所有我们可以运用到的Transforamtion。需要我们对Mapping的每个步骤及Transformation有较多的了解。
我们可以在每个Target前加一个Filter，并将条件设置为False，在保证没有数据Load的情况下运行Mapping ，如果时间还是原来一样，表示我们的Mapping设计里存在瓶颈。
当确定Mapping中存在性能瓶颈，我们可以采用不同的方式进行最终的瓶颈确定。我们可以采用一般的二分法，排除法进行确定，当然也可以根据经验或Mapping具体业务操作的分析确定瓶颈Transformation。在此我们介绍一种利用Informatica本身的特性来确定性能瓶颈的方法。这种方式就是设置Performance Detail来确定瓶颈。
进行Performance Detail设置将有两个主要作用。当设置了这个属性后，我们可以在Workflow Monitor 里看到Mapping运行时每个Transformation 的详细的输入数据条数及输出数据条数，以及其它的统计信息。所以可以知道第一个作用即它是进行Mapping查错的一个重要参考。第二个作用即利用它所提供的性能统计信息确定性能瓶颈。
设置Performance Detail只需要在Session属性中选中Collect Performance Data选项，此时在Workflow Monitor中可以看到运行的详细情况，且这个统计的详细信息也会被存为Log文件。
这个统计信息在调优过程中主要用于AggregatorRank、Lookup、Joiner的性能瓶颈确定。
当设置了该选项后，我们可以看到运行过程中，Workflow Monitor在
Performance中有了统计数据，它详细记录了每个Transformation的输入、输出及错误条数。而对于以上所提到的几个Transformation则多了其它的统计信息。注意比较这几种Transformation，我们可以知道为什么Informatica要对这几种Transformation作性能统计。这几种Transformation都是Active的，且具有Cache的Transformation（在此对Active作一个简单的解释。我们知道每个Transformation都有一个属性Active / Passive。Passive即数据通过该模块时，将不会发生数据条数的改变，Active而则不同，输出条数不一定与输入条数相符，而这两个属性在我们设计Mapping时，作为Informatica的语法检测会起作用，简单的一个规则即从同源出来的数据，如果分为两条数据流，一条Active，另一条Passive，最终不能再次将它们汇集到同一个模块中）。据有同样属性的的Transformation我们知道还有两个Sorter、Sequence。而大家打开这两个模块的属性即可发现，它们没有Data Cache及Index Cache两个选项，而我们的Performance Detail最主要的即是通过对这两个属性的调整进行性能调优。其中Index Cache是用来存储Group 信息的，Data Cache 是用来存储完整数据的。Informatica在运行的时同时创建Memory Cache及Cache File。而此处调优的原理即是调整Cache大小，减少Memory与Cache File的数据交换次数，以达到调优的目的。
以Aggregator为例简单介绍一下如何从Performance Detail中找出性能瓶颈。
主要看其Readfromdisk / Writetodisk的指数，如果这些值大于0，我们可以调整Index /Data Cache Size，使其减少并趋向于0。Newgroupkey指Informatica总共创建的Group数，Oldgroupkey则指Informatica使用已创建Group的次数。而这个次数也从另一方面指示了我们使用Index Cache的次数。理论上来说当然是希望New值越小越好，Old越大越好，这个值主要是受我们设置的Group by字段影响，所以这个值的调优需要结合业务需求，选择最优的Group by字段。
4． Session
当我们完成了L、E、T的瓶颈确认后，如果还需要进一步的寻找调优的可能，
那就是Session级的瓶颈确定了。
而Session级的调优主要是对Session的参数的调整，以期达到进一步调优的效果。其中主要涉及到以下几个参数。
这几个参数每个参数的意义及其调优方式，将在下面调优过程中进行说明。
5． System
利用一些系统监控工具监控系统性能。整体对硬件、操作系统、数据库系统、
网络等进行系统级调优。在此不作具体说明。
二、 系统调优
1. 性能平衡
性能平衡的调优更多的是需要靠经验及系统的熟悉进行调优。需要熟知系统所运行的Sever、Database、网络、硬件系统、操作系统等信息。并且在此基础需要对目标Mapping的整个设计有详细的了解。通过全面的比较及分析，确定整个ETL过程中几个较为耗用性能的步骤，例如：Extract、Join、Lookup、Aggregator等。我们可以考虑，是否把这些步骤进行拆分，把资源的占用进行平衡分配，一部分放到数据库完成，或者利用Informatica Sever的Cache机制把数据库的一些操作放到Informatica Sever上进行。最终充分发挥各个方面的最强项，达到一个性能的最优平衡点。性能平衡也是我们在设计Mapping 时应该遵循的一个规则。这个方式的运用需要一定的经验及技术要求，在此没有一些具体的方法和数值进行说明，只能给大家一个指导思想。所以我们知道在此基础上的调优会对原设计有较大的改动，但也会是一个最有效的调优过程。
2. Target
当我们确定了系统瓶颈在写Target后，我们可以按以下步骤进行调优：
1）、Drop index and key constraint
我们知道当目标表存在Index和Key constraint时，会很大程度上影响我们Load的性能，而对此情况我们可以采用使其在Load的过程中失效的方式来提升性能。
具体做法可以采用把Drop和Rebuild 语句分别写成Procedure，在Mapping每次运行的前后分别调用。或者将Drop和Rebuild语句写在pre SQL / post SQL 里使其在每次Load的前后分别调用。最终达到提升Load性能的目标。( Session log)
2）、Use bulk loading
Bulk 方式进行目标数据的Load，是Informatica提供的一种高性能的Load数据方式。它利用数据库底层机制，依靠调用数据库本身提供的Utility来进行数据的加载。
使用Bulk方式 Load时，Informatica调用Utility进行Load，此方式将绕过数据库的 log记录，以此来提高数据库Load性能，因此Bulk方式也就不可能进行Rollback操作，也不可能使用数据库作Recover操作。所以当进行这个属性设置时，需用平衡一下性能提升与系统数据恢复的重要性。
从Bulk的实现方式上我们即可以知道，Bulk方式主要是进行大数据量Insert的操作时选用，换句话说就是不做Update。当设置了这个选项后，Informatica Sever实际是调用了数据库的Bulk Utility 并忽略log进行加载的。所以在这儿对Bulk方式也可进行调优设置，这就是我们需要调整的“事务提交数”了。Commit Interval的默认值是10000。所以可以调大这个值，以减少事务数(Bulk Load Transaction)，提升性能。需要说明的是这个调整只对Oracle和SQL Sever有用。DB2 和Sybase不受这个值影响，只与Write Block的大小有关系，一旦写满即进行提交。
因为Bulk方式只能用来做Insert操作。而大家知道我们如果需要Update操作，在Session的Treat source rows as的设置上需要设置成Data Driven，当我们同时选择了两种设置，会有什么结果呢。如果你同时设置了Data Driven和Bulk模式 PowerCenter Sever将自动切换采用Normal 方式进行Load。
默认Bulk到Normal设置. Workflow ManageràToolsàOptionsàMiscellaneousàTarget Load Type ( Session log)
3）、Use External Loading
上面我们所提到的Load方式均是指Relational Connetion方式下的调优。而除了在此基础上的调优，我们也可以直接利用数据库的Loader 工具并选用Informatica的External Load方式进行数据的Load。
我们知道在Workflow Manager中的Connection设置中除了Relational方式外还有其他几种方式，而我们现在所指的就是其中的External方式。在此简单说明一下External Loading的实现方式，设置External Loading方式时，必须把目标设置改为Flatfile的方式，这样做是因为Loader工具读取数据时并不是采用SQL的方式，而是直接的Flatfile文件的读取。Informatica Sever首先将需要Load的数据在Sever上先生成Flatfile，同时生成控制文件，数据一面写Flatfile，控制文件启动Loader操作，一面统一进行目标数据库的SqlLoad。Staging Data to Flat Files时, 将先等写Flatfile结束后,才开始Loader操作,最终结束时，作为中间步骤临时生成的Flatfile将不会被自动删除，所以在运行结束后，应注意手动及时备份或删除文件，确保Sever有足够的磁盘空间大小。
Oracle版本不同需要。修改sqlloadàSQLLDR.EXE
increase commit intervals
Row Per Commit à 10000 ( Session log)
只作Insert操作, 发生约束冲突将失败. 或者Disable constraints.
4）、Optimize Oracle database
在完成这些操作后，如果需要进一步调优，可以考虑对数据库性能的调优。而数据库性能的调优将主要由DBA完成，在此不作多的说明。