有很多dba朋友在入門時總覺得不得路徑，長久的徘徊于門外，而過來人的經驗又往往高屋建瓴難以落地，兩者總覺得難以對接起來，如何才能解決這個問題呢？
回顧：由點及面由淺入深的學習方案
我一直主張"由點到線再及面"的學習方法。特别是對于初學者，如果沒有經過專門的教育訓練和系統學習，那麼自己通過實踐的學習和思考就應當深入，在知識上，從某個角度來說，是"不患寡，而患不精深"。在我們遇到問題時，就應該不斷深入研究，直至問題的核心本質，這樣通過一個案例或實際問題的診斷學習和研究，我們就可以帶動很多連帶知識的學習，這樣從一個點深入下去就形成一條線，再橫向擴充就可以形成一個知識網，解決和研究的問題多了，就可以逐漸覆寫一個面，形成一個知識體系，這樣慢慢的你就會覺得學習不再困難，而是一件得心應手的事情。
案例：expdp ora-31626 錯誤的啟示
今天有朋友在‘雲和恩墨大講堂’提出一個關于expdp的導出問題。
操作：
expdp system/password directory=expdir full=y dumpfile=20151230.dmp logfile=20151230.log
錯誤提示：
ude-00008: 操作産生了 oracle 錯誤 31626 ora-31626: 作業不存在 ora-39086: 無法檢索作業資訊 ora-06512: 在 "sys.dbms_datapump", line 2772 ora-06512: 在 "sys.dbms_datapump", line 3886 ora-06512: 在 line 1
在面對錯誤的時候，dba不能有畏縮的心理，一定要認真閱讀錯誤，對于這個提示，其實可以看到明确的資訊“作業不存在”，也就是job檢測不到了，那麼要麼這個job執行完了，要麼異常中止了。
建議：
以下兩條是我們給所有初學者的建議，收集資訊、保護現場，這是尋求解決和幫助的必要手段。
在面對任何錯誤時，都應當詳細的排查所有可以獲得的日志； 在面對複雜問題時，一定要得出結論後再操作，在操作前盡量保留可回退的現場。
其實在擷取了充足的資訊之後，無論是提問還是自己排查都容易接近真相。
結論：
檢查導出記錄檔，可以看到導出是完整成功的，我們由此可以判定導出的正常執行，那麼前台抛出的錯誤可以安全的忽略。當然也可以測試一下，判定導出檔案是完好的。到這一步判斷，是每一個工程師應該自主做出的。
. . 導出了 "system"."repcat$_user_ath"0 kb 0 行 . . 導出了 "system"."repcat$_user_ps" 0 kb 0 行 . . 導出了 "system"."sqlpls_t_profile" 0 kb 0 行 . . 導出了 "tsmsys"."srs$" 0 kb 0 行 已成功加載/解除安裝了主表 "system"."sys_export_full_01" *************************************************************************** system.sys_export_full_01 的轉儲檔案集為: /oradata/20151230.dmp 作業 "system"."sys_export_full_01" 已于 09:41:33 成功完成
進一步的确認：
通過mos官網進一步的确認問題，是oracle dba的必要技能。在mos上可以找到這個問題的相關bug，bug号是5969934。
bug 5969934 : expdp client gets ude-00008 ora-31626 while the server side export is ok
這個bug的從 10.2.0.2 到 11.2.0.3，都可能發生，其根本原因是job的執行和用戶端的通訊出現問題。
oracle support的提示也包括檢查日志：
relying on information in the log file is one way to verify that the job actually completed successfully.
問題源自：dbms_datapump.get_staus 的調用。在以下的mos回複中，可以看到，執行expdp的工作是通過dbms_datapump包進行的，其中get_staus用于狀态擷取。當擷取狀态時發現job程序失蹤，就抛出前台的異常，而從日志可以判斷，事實上是導出已經完成。如果expdp能夠争取回報給用戶端完成狀态，那麼這個問題就不會出現了。
the expdp client makes calls to dbms_datapump package to start and monitor export job. once the export job is underway, the client just monitors the job status by issuing dbms_datapump.get_staus. therefore, if the export logfile says “job successfully completed”, the dump file generated by the job should be fine. you can simply ignore the errors, since the dump file is still valid for an import.
這是一個簡單的例子，我們希望大家也能夠分析、總結自己遇到的問題，如此即可以分享給大家，又可以提升自我的學習和總結能力。
這個案例，從一個最簡單的錯誤分析猜測，到日志檢查判斷，進一步确認bug根源，由此又可以進一步了解expdp的工作原理，這就是由淺入深，逐層遞進，形成思路和方法。在遇到任何問題時，都可以借鑒這樣的過程和方法。