轉自：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完成，在此不作多的說明。