在這裡分析下最近分析和解決odi效能問題的點滴，用作參考。在介入該問題前，已經具備的基礎知識包括了odi基礎，soa理論和實施，特別是04年封閉四天的informatic etl培訓和實操。幾年的開發經驗和技術積累。
首先我們拿到的問題是odi效能慢，要知道odi本身核心還是是etl，只是odi已經由傳統的etl轉化為了elt，先load資料然後再進行轉換。同時增加了宣告式設計，正是由了宣告式設計odi才能夠真正轉化為按需，按引數排程的資料服務，更好的和soa進行整合。
以往的經驗始終有用，只是你無法預知會在將來的什麼時候用到，即時你忘記也容易快速熟悉起來。
當拿到odi效能慢的問題的時候，首先還是問題定義，是如何乙個慢法，50萬條資料要1小時？那麼這個速度是否慢？我們是否有基於某種軟硬體環境下的標準
benchmark資料。注意硬體配置，軟體環境，源和目標的資料庫型別，網路頻寬都是我們需要分析的內容。任何問題的定義都必須要乙個十分明確的場景。
任何問題的定義都必須包括外在場景，脫離場景即無所謂問題。
在我們確認軟硬體環境都沒有問題後，再獲取同型別場景下的參考值一般為10分鐘左右，那就明顯存在odi效能問題。確認效能問題後接下來要做的就是確認出現在etl整個過程的那個階段，是抽取，轉換還是load過程中慢。在這裡首先進行如下分析：
由於我們odi抽取的是檢視，檢視涉及到複雜的關聯查詢，所以最開始懷疑是檢視查詢慢引起的，同時看odi整個步驟，發現是load環境慢(在這裡犯嚴重經驗性錯誤，誤認為了load是從源端抽取資料的過程)。後面我們對檢視進行了優化，效果還是不明顯。
定義問題涉及到問題的分解和邊界定義，分而治之和假設驗證始終是縮小範圍的關鍵。
為了進一步確定和檢視不相關，將源端的檢視換成實體表再試，發現仍然很慢，基本確認和檢視無關。在整個過程中我基本還沒有進入到odi設計器檢視詳細的
odi設計過程。在確認了和檢視關係不大後，進一步在網上搜尋資料，發現三個點影響到odi本身的效能。乙個是km知識模組的選擇，乙個是agent**
最好放到目標，乙個是最小化日誌記錄，調整批大小等。
對最小化日誌記錄和批大小再進行調整和測試，問題仍然沒有解決。排除掉兩個。由於目標端是生產系統，要在目標資料庫端安裝相應的agent是相當困難的，到了這裡感覺問題的解決必須要詳細學習odi產品和整個etl實現過程，否則很難再深入的去解決該問題。
任何經驗性判斷都有可能形成誤導或走入錯誤分支，唯一方法是要對提出假設盡快驗證。
到了這一步後，必須要學習odi了，原來都是理論和象徵性的了解了些odi，已經odi和soa服務整合的方法。那必須得進一步補充相關知識。這個時候開
技術說明，詳細的操作例子方法等，差不多有10多個文件。對這些文件進行大量的泛讀後將關注點停留到兩個詳細的odi操作手冊上面，仔細看了一遍後對
odi的物理架構，邏輯架構，知識模組，介面，排程這些就有了基本的理解。在這裡感覺到04年學習過得etl知識完全可以用上，所以再熟悉這個的時候很容
易。解決問題很多時候受時間約束，核心技能包括網際網路搜尋，大量泛讀後快速定位和精讀深入。
第二天馬上進入到odi設計環境，對相關的有效能問題的odi排程進行分析，詳細從物理架構，邏輯架構，知識模組，包，介面看了一遍。進一步理順這些功能模組的內在耦合關係，明確odi設計的乙個完整步驟。只有這個完成後才能夠進入到知識模組影響效能的進一步分析。
本次為oracle到sybase的資料同步，檢視使用的知識模組為sql to sybase而沒有使用另外乙個sql to
sybase(bcp)，那就有必要搞清楚兩個知識模組的區別，特別是sybase資料庫基本原來沒有用過，又到網上查詢資料和分析，得出官方結論是對於大批量的資料傳輸根本不推薦sql
to sybase而推薦bcp方案。因為bcp是sybase推薦的批量資料匯入方案。
再一次進入到執行排程過程，對原方法的排程過程進行檢視，發現load過程用時間最久，在排程臺可以看到具體的執行的命令和sql語句，發現load過程其實已經是完成了從源表取資料超目標的乙個臨時表插入的全過程。顯然不是我原來理解的僅僅從源端查詢出資料的時間。（進一步糾正錯誤假設）
走到這裡基本明確乙個正確的方向，即需要盡快對bcp方案進行測試和驗證。那麼把odi中的lkm知識模組切換到bcp方式再試驗，發現報異常。看來啟用odi不是簡單的事情，又需要到網上查詢資料檢視bcp啟用的一些基本條件，最終確定要做的事情包括：
1.需要在**機器安裝sybase open client，因為bcp應用在這個包裡面。odi也是調的這個外部程式。
2.需要目標資料庫開啟select into/bulkcopy設定。
第三天，安裝sybase open
client，安裝完成後終於找到bcp應用，重新對配置檔案進行了修改，讓bcp應用能夠呼叫到正確的路徑。這些都做完後至少bcp應用已經能夠成功找
到。也基本理順bcp方案的整個過程，即首先是通過oracle自身的unload將資料存為文字檔案，然後再呼叫bcp應用將資料匯入到sybase數
據庫。(逐步清晰)
首先對於unload資料到文字檔案，又出現亂碼問題，基本判斷為字符集原因，直接對lkm知識模組該步驟的內容進行檢視，看了字符集設定不正確，修改匯出**為utf8後問題解決。
對於bcp匯入也發現大量問題，首先就是伺服器或資料庫不存在，又進行了相關引數配置。然後發現bcp匯入發生unexpected eof
encountered in bcp
datafile的異常。這個問題基本又折騰我一天，不得不對bcp各個引數進行詳細的學習，發現雖然對欄位分割符，行分割符都進行了正確設定仍然無法成功匯入而報錯。(柳暗花明，在將要解決邊緣往往更難熬，乙個技術問題卡幾天都正常。)
如果乙個表能夠成功匯出，那麼也應該能夠成功再匯入。(英文搜尋一大堆也解決不了後，尋找新假設和途徑)到
這一步後，首先使用bcp對錶資料進行匯出，然後再匯入一切正常。發現這裡基本沒有顯性化設定相關分割符。bcp匯入預設製表符為字段分割符，預設換行符
為行分割符。那麼如果我文字檔案也能夠按該要求輸出，則應該就能夠成功匯入。再次修改unload程式設定字段分割符和換行符，修改完成後bcp匯入基本
成功。到這裡基本只剩下最後乙個問題，即bcp匯入的資料出現亂碼問題。現在sybase資料庫字符集編碼為cp936，但是我匯出檔案編碼為utf8格式，所
以必須要轉換。通過bcp增加引數顯性轉換後發現仍然匯入報錯誤。還得搜尋資料，搜尋後發現還需要對客戶端乙個配置檔案進行修改(還得搜尋)，修改完成後資料可以成功匯入。
到了這步，基本只剩餘乙個遺留問題，即如果資料裡面本身還有製表符這個不可見字元，那麼匯出的資料再匯入將報錯。這個問題需要在檢視中進行處理，將製表符替換掉，如果這樣基本就不會再有問題。
bcp全部除錯通過後開始測試，對於50萬條資料需要7分鐘即可以執行完成，時間基本都花在bcp
load過程上，但是仍然發現unload過程仍然花費了近1分鐘，再次對unload指令碼的批大小調整為3000再測試，差不多6分鐘即可完成50萬條資料的傳輸，整個方案應該有效和可行。
ODI 資料抽取流程
源資料 目標表 大綱 分別建立源資料 和目標表的 物理體系結構 物理方案 邏輯方案 模型 介面 拓撲 物理體系結構 oracle 右鍵 新建資料伺服器 連線的使用者和口令為表所在的使用者 儲存 右鍵 新建物理方案 方案和目標方案 填表所在的使用者 邏輯體系結構 oracle 右鍵 新建邏輯方案 填好...
ODI的基本組成
資料庫使用者 源庫odi source odi source 目標庫odi target odi target 資料庫 odi設計 使用者 主資料庫 odi master odi master 建立主資料庫 初始化 路徑 程式 oracle oracle data integrator reposi...
ODI實現緩慢變化維
前陣子，面試考官問我緩慢變化為實現過麼。答案是沒有，接觸etl一年以來做了不少inte ce,procedure,package 通過odi實現 卻從來沒有實現過緩慢變化維相關的etl。今天實現了個小例子 1.是沒有自己開發km，通過odi自帶的 ikm oracle slowly changing...