根據常理，這些高階建議放在最後，並且是在系統級上的建議。還有其他的適用於資料倉儲調優的高階建議，可以依據你的軟硬體資源存在的問題去尋找相應的幫助。
5、改變網路包的大小（對於sybase/sql server/oracle的使用者）。最大的網路包的大小是資料庫的設定，通常是512位元組或者是1024位元組。設定網路包的大小一般不會影響其他的使用者，但是卻會使informatica充分的利用到其優點，可以在同乙個網路包中傳輸更多、更快的傳輸資料。典型的最優設定是使網路包的大小在10k到20k之間。在oracle中，需要調整listener.ora和tnsnames.ora檔案中的sdu（service layer data buffer size）和tdu（transport layer data buffer size）引數。sdu和tdu應該被設定成為相等的大小。參見informatica的常見問題解答頁面來獲得更多的資訊。
6、對於本地的oracle資料庫，把連線設定為ipc方式。如果pmserver和oracle執行在同一臺機器上，使用ipc連線方式，而不要使用tcp/ip方式。在tnsname.ora和listener.ora檔案中進行修改，然後重新啟動listener服務。注意，這個協議只能在本機使用，然而使用ipc協議所帶來的效能的提高會達到2～6倍。oracle只是使用ipc協議，該協議是unix system 5定義的。可以在unix system 5的相關使用手冊中找到更多的關於ipc的資訊。
8、改變unix使用者的優先順序。為提高速度，執行informatica程式的unix使用者必須提供乙個較高的優先順序。unix的系統管理員應該明白這樣做可以改變登入unix的使用者的先後次序，同時給乙個特定的任務以較高的執行優先順序。或者，簡單的以超級使用者（super user）來執行informatica的程序，這樣可以保證informatica的內部程序的優先順序。這種方法的使用只能在其他方法都失效的情況下採用，或者是unix主機是由informatica程式的專用主機。
9、避免通過網路進行資料的載入。只要有可能，就將pmserver重新分配到資料庫的本地主機來執行。資料庫不在本地的意思是：1）repository是通過網路來訪問的（速度慢）；2）資料來源或者資料目標是通過網路來訪問，同樣潛在的存在速度變慢的因素。如果必須通過網路來進行資料的載入，至少應該保證repository是在資料庫所在的主機上。另外要注意的是，盡量將pmserver和資料目標所在的兩台機器放在同乙個子網內部，如果能夠使用同乙個hub是最好的，這樣做的話可以減少在網路上在進行路由的花銷。將資料庫本地化能夠讓你建立乙個本地化的資料目標——可以將進行載入的資料先導出（dump）到本地的檔案，然後通過ftp的方式上傳到目標伺服器，然後以並行（bulk）的方式載入到資料庫中。在進行資料新增或者進行資料完全的更新的情況下，這樣做的優點更明顯。
10、將session的共享記憶體設定成12mb～24mb的大小。很多時候，我發現人們願意給session分配更大的記憶體堆（希望能夠提高速度）。這樣做的結果是反而使得處理變慢。請參考memory layout document來獲得更多的關於這樣做會怎樣影響informatica的記憶體管理的資訊，同時也能了解為什麼簡單的新增記憶體並一定能夠提公升處理速度。
11、將共享的緩衝區的大小設定為128k左右。仍然是關於記憶體分配的問題，請參考上述文件。在informatica的程序裡面處理記錄所占用的記憶體塊的大小是一件很有意思的事情。
12、記憶體設定：上面提到的設定是針對一般情況而言的，少於10g記憶體的主機可以遵循上面的建議。如果主機擁有12g的記憶體，而且同時只執行1～3個session，可以考慮將
13、對資料庫進行快照分析。如果在伺服器之間有專線（ds3/t1等），使用快照或者高階複製的方法從源系統獲取相關的資料，放到臨時表中。在informatica的程序執行前啟動快照。關係型資料庫管理器就是為這種資料遷移而設計的，而且對這種增量更新資料和全部更新資料的資料傳輸有很多的優化設定。這一點可能會被很好的利用，尤其是源資料報括1300萬條或者更多的資料，可以讓informatica從快照中讀取資料，這時可以生成任何你需要的索引，在提高讀取速度的同時卻不影響資料來源系統。是的，快照的方式僅僅在資料來源和資料目標是同構資料庫的情況下（也是同樣型別的系統）。
14、提高磁碟的讀取速度。建設資料倉儲系統的乙個通常的誤區是僅僅需要兩個磁碟控制器和13塊磁碟就足夠了。如果系統僅僅處理少於500萬條記錄的資料量，或者載入的時間長度超過5個小時，這樣還算可以。我推薦至少4～6個磁碟控制器和至少50個磁碟，設定成raid0+1的方式，至少7200轉每秒。如果必要，投入一定的資金採購emc的儲存裝置。到達這樣的配置，在效能上可以得到很明顯的提公升。
15、採用raid0+1的磁碟陣列。raid5對於冗餘很好，但是對資料倉儲而言就很糟糕，尤其是在並行載入的時候。raid0+1方式的磁碟陣列很適合資料倉儲系統，大多數人也認為它的效果和raid5一樣的安全，尤其是現在的硬體幾乎都是熱切換的，而且相關的管理軟體也相當的成熟。
16、公升級硬體裝置。如果想得到每秒gb級的資料處理能力，或者系統能夠在4個小時內對3400萬行資料建立10個索引，那麼只能增加cpu的處理能力、新增記憶體和磁碟。4個cpu的機器對這樣的處理要求是無能為力的。我建議最少使用8個cpu的主機，如果必要的情況下公升級到12個cpu。這是對大型的資料倉儲系統而言的，就是那種每小時處理gb級資料的系統。4個cpu的主機適合於開發或者是小型的資料倉儲系統（總共不超過500萬條記錄的資料倉儲）。然而，主要匯流排速度也是乙個很重要的因素。我聽說4個cpu的dec-alpha系統相當於6個cpu的處理能力。那麼什麼是關鍵呢？磁碟轉數、匯流排速度、記憶體大小以及cpu的個數。我認為上面的順序是從重要到非重要。在6個cpu、8～12g的記憶體的主機和最少4個磁碟控制器的7200轉的emc儲存裝置上，oracle和sybase都能夠執行的相當不錯。
Informatica 效能調優 上
大多我們運用的工具都會提到乙個共同的問題 效能調優。什麼是效能調優，每個人都有自己的乙個定義，我比較喜歡的乙個定義就是 效能調優就是盡力去消除系統中存在的效能瓶頸。這是乙個迴圈往復的過程，首先找到效能瓶頸，然後採取各種方法盡力消除它，然後尋找下乙個效能瓶頸，然後消除它，迴圈往復，直到效能達到預期目的...
mysql高階 with as 效能調優
with as 意義 對於多次反覆出現的子查詢，可以降低掃瞄表的次數和減少 重寫，優化效能和使編碼更加簡潔 1 mysql版本 8以及8以上的 2 首先定義子查詢的臨時虛擬表 語法 with 臨時表名 as 子查詢，定義出 子查詢 的虛擬臨時表，然後定義之後需要立馬引用才有意義 即 定義好with子...
spark調優 shuffle調優
基於spark1.6 引數可以通過 new sparkcontext set 來設定，也可以通過命令的引數設定 conf spark.shuffle.file.buffer 預設值 32k 引數說明 該引數用於設定shuffle write task的bufferedoutputstream的buf...