本文所列的諸要點都是對Informatica相關產品進行調優(yōu)過程中所涉及到較宏觀的問題难衰。他們不是放之四海而皆準的教條钦无，也不是最終的解決方案。其中一些已經條目（尤其是已經進行過調優(yōu)）的建議可能結果會有所不同盖袭。適用于某些特定條目的技巧由于其所要解決問題的層次不同也會產生不同的調優(yōu)結果铃诬。
? ? 對性能進行測試的時候，建議使用20萬條記錄左右的數據源進行處理苍凛。使用比之更大數據量的測試數據源趣席，可能會產生因為表分區(qū)、刪除和重建索引醇蝴、RAID數據條帶化等數據庫問題導致性能下降的問題宣肚，而如果使用的數據源的集合太小，統(tǒng)計出來的平均處理時間肯能會因為數據庫吞吐量悠栓、主機負荷以及網絡流量等因素的影響而變得不穩(wěn)定霉涨。20萬條記錄的集合一般是進行準確統(tǒng)計的比較理想的測試數據源。
? ? 首先試著用如下的方法對Mapping進行調優(yōu)惭适，然后進行Session的優(yōu)化笙瑟，然后重復這一過程直到對調優(yōu)的結果滿意為止，或者無論怎么努力也無法取得更好的效果癞志。如果經過調優(yōu)往枷，性能仍然無法令人滿意，那么整個處理的體系結果就需要進行調整（或者說改變Mapping所要完成的工作）。
? ? 始終要記状斫唷：要想得到一個理想的運行性能秉宿，盡量的要使得系統(tǒng)中的各個部分到達一種運行的平衡狀態(tài)，包括數據庫屯碴、硬件資源等描睦，讓他們做各自擅長的事情。不同的體系結構可能在速度以及優(yōu)化的可能性等方面產生巨大的差異导而。
? ? 1）利用數據庫（例如Oracle忱叭、Sybase、Informix今艺、DB2）進行大量的數據處理操作（例如排序韵丑、分組、匯總等）洼滚。換句話說，臨時表（中間表）會對并行操作有很大的益處技潘。在并行設計中遥巴，尤其是通過臨時表計算簡單的數學計算。
? ? 2）盡可能的本地化享幽。將所有的目標表放到Oracle的同一個實例中（相關的SID）铲掐。對任何處理都不要使用同義詞（遠程數據庫連接），包括Lookup值桩、存儲過程摆霉、目標表、數據源奔坟、函數携栋、權限等等。遠程連接的使用會使得處理的變得很慢咳秉。
? ? 3）盡可能的使目標表婉支、存儲過程、函數澜建、視圖以及序列都放到數據源的本地向挖。同樣，不要通過同義詞連接炕舵。
? ? 4）減少外部定義的模塊何之。作為代替，在pre-processing/post-processing中使用perl咽筋、sed溶推、awk等功能。調用外部的應用編程接口（API）本身就會降低性能
? ? 5）時刻謹記Informatica建議每個Session使用1--1.5個CPU。在這種情況下悼潭，Informatica可以和關系數據庫引擎在同一臺機器上配合的很好庇忌。
? ? 6）減少基于數據庫的序列。因為基于數據庫的序列生成器需要一個Wrapper函數和過程調用舰褪。使用這樣的過程會使得性能降低3被左右皆疹。而且這樣的速度降低也不容易通過Debug來發(fā)現，它僅僅是在寫入數據庫的列是才引起速度的降低占拍。先復制這個Mapping略就，然后改調用上面提到的存儲過程為調用Informatica本身提供的內部序列生成器，這樣的運行結果是這個Mapping所能得到的最快的運行結果晃酒。如果你必須使用基于數據庫的序列發(fā)生器表牢，那么最好遵循臨時表的使用建議，然后調用一個屬性為POST TARGET LOAD的存儲過程來分配序列的批量操作贝次。
? ? 7）關閉詳細日志崔兴。Session的日志會對整個Mapping的性能產生極大的影響。在Session里面去掉“覆蓋”（over-write）蛔翅，將生成日志的屬性設置為正常日志模式敲茄。不幸的是，在Informatica的內部山析，日志記錄并不是一個并行的機制堰燎，而是直接安排在操作的進行過程中。
? ? 8）關閉“收集性能統(tǒng)計”開關笋轨。然而秆剪，在進行調優(yōu)的過程中，開啟這項功能又是非常必要的爵政，它能發(fā)現一些Reader和Writer線程在速度方面的一些問題仅讽。
? ? 9）如果你的數據源是平面文件，可以使用臨時表钾挟。這樣的話何什，你就可以使用sql*loader、bcp或者其他數據庫的并行裝在功能等龙。只把那些簡單的處理邏輯放置在數據源的加載Mapping中处渣，不要加入那些編碼的查詢和轉換邏輯。盡量把平面文件放在本地磁盤上蛛砰，不要放在磁盤陣列中罐栈。
? ? 10）盡量不要使用無緩沖Lookup。使用無緩存的Lookup時泥畅，性能會受到顯著的影響荠诬，尤其是如果Lookup的表是一個可增長或者是可更新的表，一般來講這樣的表在整個操作過程中它的索引是會發(fā)生變化的，因此優(yōu)化器就無法利用所有的統(tǒng)計信息柑贞。同時方椎，盡可能的使用臨時表，此時數據庫中的視圖可以將相關的數據關聯起來钧嘶，或者可以利用Informatica的Joiner對象來關聯數據棠众，這兩種都可以明顯的提高數據處理速度。
? ? 11）分離復雜的Mapping有决。試著將整個Mapping分成一個個邏輯處理單元闸拿。如果需要進行并行的處理，重新進行體系結構的設計和布局书幕。通過小的組件來處理單個的任務新荤，可以提高整個處理過程的并行度。
? ? 12）平衡台汇，在Informatica苛骨、SQL語句和數據庫之間取得一種平衡。要重復利用數據庫的特長：讀苟呐、寫痒芝、排序、分組掠抬、過濾吼野；利用Informatica來處理復雜邏輯：外關聯校哎、數據繼承两波、多數據源處理等等，這種平衡需要DBA的幫助來實現闷哆。
? ? 13）調優(yōu)數據庫腰奋。根據數據庫的大小調整數據庫的參數。
? ? 14）確保在PMSERVER的機器上有足夠的SWAP空間和臨時空間抱怔。尤其是在Mapping中含有Aggregator劣坊、有緩沖的Lookup或者不同數據源的數據關聯的操作的情況，更有必要這樣做屈留。
? ? 15）在開發(fā)局冰、運行過程中，在服務器上面運行一些加載監(jiān)控工具灌危。EMC磁盤陣列也可以考慮一下康二。
? ? 16）設置Session。Session屬性中有很多可以用來調優(yōu)勇蝙。通過設置“Collect Performance Statistics”屬性可以獲得在Mapping運行期間的一些性能方面的信息沫勿，從而可以對Session的其他屬性進行修改，或者對數據庫的參數進行調整。調優(yōu)一個有問題的Mapping的最好辦法是把它分成幾個部分分別進行測試：（1）讀處理产雹，調優(yōu)Reader诫惭，檢查相關的配置是什么，把讀出來的數據輸出到平面文件蔓挖，以減少沖突夕土。檢查“Throttle Reader”參數（默認是不被設置的）。（2）如果在平面文件中寫入數據的時候Reader都不是很快时甚，就需要做一些基本的Mapping調優(yōu)了隘弊。盡量合并Expression控件，如果可能的話將Lookup改為非連接的荒适。檢查Aggregator和Lookup中索引和shju緩沖區(qū)的大小梨熙。（3）寫處理，如果目標的寫入速度比較慢刀诬，把Mapping改為一次寫入一張目標表咽扇，然后可以找到引起寫入慢的那個目標表。然后采用數據庫優(yōu)化技術分區(qū)陕壹、修改統(tǒng)計信息质欲、加載過程中去掉索引等等。
? ? 17）將PMSERVER的機器上的所有其他應用都移走糠馆，除了數據庫嘶伟、內存數據庫和數據倉庫本身。PMSERVER可以喝關系數據庫配合的很好又碌，但是和其他的應用服務器配合的就很差九昧。
來自 “ ITPUB博客 ” ，鏈接：http://blog.itpub.net/25811908/viewspace-1269442/毕匀，如需轉載铸鹰，請注明出處，否則將追究法律責任皂岔。
