1，sql自身的優化：調優，並行處理
2，stage的拆分與合併：實踐測試為準
如多個join的stage雙方都為大數量(幾百萬一般大於200w)則考慮合併。如大表但join的資料不大就不用合併。
如乙個stage中的兩個表都為大表且關聯很慢時考慮拆分為兩個stage作join（select後資料不大：小於40w）
3，選用合理的stage: 像sort,之類的盡量少用，在資料庫裡完成
4，大資料量(上千萬)上述方法都優化不明顯後 可考慮採用直接insert 語句 使用oracle後台處理，而非ds資源抽取插入。
datastage job優化指導原則之一：演算法的優化。
任何程式的優化，第一點首先都是演算法的優化。當然這一點並不僅僅侷限於電腦程式的優化，實際生活中也處處可以體現這一點。條條大路通羅馬，完成任何一件事，也同樣有很多種方法。而方法當然有優有劣，有低效有高效。所以想提高完成任何一件事的效率，首先就是做事方法的優化。體現在電腦程式中，也就是演算法的優化。也只有演算法的優化，才可能使做事的效率有十倍、百倍，甚至上萬倍的提公升。
但是是在實際的job開發過程中，絕大部分人都會忽略這一點。原因很簡單，絕大部分人都認為job開發是一種很低階的工作，最常用的stage可能也就不到10種，熟練使用了這10種stage不怕job開發不好。的確，job實際開發過程中，也許只會用到不超過10種stage。最重要的無外乎oracle stage、lookup stage、join stage、transformer stage等。但是，如何在適合的場景使用合適的stage，如何平衡datastage與資料庫的負載均衡，如何確定與哪些表做關聯，以及與這些表關聯的順序怎樣才是最做優的等等，都是需要考慮的問題。開發乙個job完成需求的功能並不難，難的是如何以更少的資源消耗，更有效率的完成需求指定的功能。
datastage job優化指導原則之二：儘量減少ds需要處理的資料量。
這一點，簡單來說，主要指兩點。一是儘量減少從資料庫抽取至ds臨時緩衝區的資料量（包括資料記錄條數和資料位元組數）；二是盡量避免在ds內部處理過程中，產生一些不必要的資料處理。
但是說起來容易，做起來難！隨便開啟乙個job，80%的可能都會存在上述說的乙個或兩個問題。
首先對於第一點，經常發現job從資料來源抽取了幾十萬甚至上百萬的資料至ds，緊跟著跟乙個小表（20w以內資料量）做內關聯，關聯之後的資料，可能只有從資料來源抽取資料的三分之一甚至十分之一。那為什麼不考慮將這兩張表的內關聯使用sql在資料庫中完成呢？這樣做明顯可以減少從源表抽取資料的資料量，減少了資料抽取至ds的時間，減少了ds伺服器臨時緩衝區空間的使用。
其次對於第二點，很典型的乙個就是對remove duplicate stage的使用。個人認為，所有凡是使用到這個stage的job都應該去認真仔細的檢查一下，到底是不是真的有必要使用該stage來完成資料的去重。首先該stage的效率相當低下不說，重複的資料從何而來呢？是從源表抽取的時候，源表有資料重複？還是在job處理過程中，通過關聯導致資料重複？不管是哪一種重複，都應當從源頭上避免將重複的資料抽取至ds中做處理。
datastage job優化指導原則之三：儘量減少使用的stage數量。
在ds8.5中，job執行時，會將每乙個stage對應生成乙個執行緒或程序去處理。當大批量高併發的執行job時，系統需要處理的執行緒或程序太多。
datastage job優化指導原則之四：盡量平衡ds伺服器與資料庫伺服器的處理負擔。
兩張表或多張表關聯時，是在ds伺服器中完成呢，還是在資料庫伺服器中完成呢，這就需要根據ds伺服器和資料庫伺服器的效能進行平衡。另外對於一些太複雜的多表關聯，也可拆分，以便將資料抽取至ds中進行關聯運算。
datastage job優化指導原則之五：充分發揮各stage的長處。
每一種stage都有其存在的合理性，否則ibm的工程師們何必大費周章的為ds開發如此多的stage呢？
但是是不是所有的stage都物盡其用了呢？實際也許未必。例如有多少人使用過lookup stage和一張小表做內關聯呢？咦！lookup stage還能實現內關聯？對，他真的可以！lookup stage能像join stage關聯時那樣，當關聯的右表有重複時，關聯出多條資料來呢？lookup stage真的可以！
datastage job優化指導原則之六：盡量使用更高效的stage以及儘量減少低效stage的使用。
當然這一點要看具體實現的功能。比如lookup stage和join stage應該使用哪個呢？因為lookup stage會將右表全部裝入記憶體，所以在處理效率上要比join stage快的多。但是當關聯的右表為大表時，將整張表的資料放入記憶體可能會占用大量的記憶體空間，甚至會導致記憶體不夠用而job執行失敗。何為大表，何為小表呢，這就是乙個經驗值，不是一成不變的。當伺服器的記憶體足夠大時，1000w的資料量放入記憶體，也只是佔據了記憶體空間的九牛一毛時，1000w的表也是小表。我們專案組使用的臨界值是100w，右表超過100w的，盡量使用join stage。
另外像上面提到的remove duplicate stage，就是乙個相當低效的stage，應當減少類似低效stage的使用。
Datastage效能優化
state的拆分與合併 如兩個join的stage都為大數量 幾百萬 且主表是一樣的則考慮合併。如乙個stage中的兩個表都為大表且關聯很慢時考慮拆分為兩個stage作join。copy stage 在記憶體中操作的元件，建議1進多出用copy元件 tansformer stage 是內嵌的程式，一...
Datastage 許可權管理
乙個使用者id是分配套件角色可以登陸資訊伺服器日誌控制台。怎麼樣乙個使用者id是datastage的套房分配乙個元件的角色？如果使用者id是datastage的管理員分配的作用，那麼使用者將立即獲得datastage的管理員對所有專案的許可。如果使用者id被分配乙個datastage user 角色...
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...