以下的文章主要介紹的Oracle impdp的具體操作方法，如果你是Oracle impdp實際應用方面的新手，你就可以通過以下的文章對Oracle impdp是如何正確使用的方法有一個更好的了解，以下就是文章的詳細內容的介紹。
立馬打開查詢窗口，查詢相關的表，結果返回：no rows selected.數據已經全部清掉了。
一瞬間一下子就懵了：我Kao，搞什麼鬼？怎麼能把生產機的數據truncate掉？是不是腦子進水了？馬上打電話給H，電話占線，Shit，再打，還是占線...... 急，先上洗手間，掏出手機，繼續打，終於通了，第一句話：怎麼在生產機上導數據？為什麼動生產機的數據？
H給出的答復是由於剛才導網上查詢數據時誤操作把一張表的數據刪掉了，沒有把問題反饋上來，直接就想通過18：30左右的備份恢復該表，由於缺乏IMPDP的相關知識，以為導出文件有的表，在Oracle impdp的時候都必須制定，結果把其他十來各表都全部truncate。
出現問題沒有反饋，掩蓋問題試圖自己解決，由於缺乏相關的知識，結果誤操作導致更嚴重的後果。
由於有下班後的Expdp備份，本來是一張表的數據，而且該表數據在下班後不會變化，簡單的通過Oracle impdp就可以恢復，結果用truncate選項把其他表統統清除掉，當時心裡那個苦啊！
事已至此，沒有辦法，馬上組織其他人手先通過備份恢復數據。
1.把大表和小表分開，大表先drop索引再導入，小表直接導入。
2.大表導入完畢後同步建立索引。
其他表都比較順利，最後有兩張表（大表A和中表B），死活導不進去。當時已經是凌晨0點10分左右。出現的現象是：
大表A導入了1.5個小時，沒有任何反應，中表B導入時通過後台查詢發現有其他進程lock該表，進程是Oracle.EXE(DW01)。
再等了十分鐘，還是如此，覺得不能這樣坐以待斃，重啟數據庫，重寫執行導入數據，還是如此。
大表A的導入沒有任何異常情況，就是Hang著不動，這時候想到該表是復合分區表，如果改成普通表是否可以？通過rename原來的表，通過CTAS創建普通表，重新導入，It works！數據導入後，通過insert into as select導入到正式表，然後通過rename等操作把正式表恢復到正常的表名。
大表A導完後，發現中表B還是在等待Oracle.EXEC(DW01)，本想著通過alter system kill session把相關的session kill掉，半個小時過去，沒有kill掉，只是mark kill。這時候查詢session時發現相關schema是XDB，把XDB用戶account lock，再導入，還是如此。
這時候已經凌晨一點，就剩下這張表，頭都有點大了，再仔細分析session的信息，發現module是Data pump，不是Oracle的必須後台進程，同時想起幾年前在windows平台可以用orakill殺掉Windows線程，抱著試試的心態，用 orakill殺掉了ORACLE.EXE(DW01)的線程，然後用Oracle impdp嘗試導入，God，It works！謝天謝地，總算，數據都恢復了，這時候是凌晨1：30.
索引都創建完畢後，再次一張一張表檢查一次，確保數據和索引都存在。
最後執行dbms_stats.gather_table_stats過程對相關的表執行一遍信息，並設定定時任務對數據庫進行備份。
