親愛滴伙伴們！本萎專家又來了，掌聲響起來。哈哈哈。。。。。。咋感覺那么別扭啊。

好了，下面開始咱今天的分享。

由于12C版本不是很穩定，本萎大濕所在客戶現場后續安裝的數據庫都集成19C版本。這就涉及頻繁的數據遷移、同步等工作。

本篇就本萎大濕遇到的幾個數據導出導入(EXPDP/IMPDP)遇到的問題進行一個分享。希望對各位看官有所借鑒。

場景一：

源端：12.2.0.1

目標端：19.3

在目標端通過imdp走dblink方式導入時，報ORA-39097，ORA-39065，ORA-03150

報錯截圖如下：

從圖中我們可以看到JOB由于通道關閉導致導入失敗，最開始本萎大濕懷疑是網絡問題，通過ping，traceroute等各種姿勢確認網絡沒問題。

心煩意燥之下，本萎大濕自我安慰任務報錯是偶發的，并再次嘗試，在成功導入幾個表之后又出現通道關閉報錯。多次嘗試之后，本萎大濕放棄了。

他丫的就一個導數而已，難道又遇上了19C數據泵走dblink方式的兼容性BUG？！去MOS擼擼吧，MOS上發現很多關于ORA-39097，ORA-39065報錯的文章，但沒一篇跟本萎大濕情況是類似的。

困難面前，大濕都是堅挺的，于是嘗試在源端導出dmp文件，然后SCP到目標端再導入。人品大爆發啊，終于導入成功了。

說到這里本萎大濕要感慨下，impdp走dblink方式數據導入一直都有不少BUG，無論哪個版本都是這個命運。根據本萎大濕多年夜觀天象得出的結論，這種問題都有一個最終的萬全解決辦法，那就是：

導出DMP文件到本地，然后SCP至目標端再impdp導入，保證啥報錯都不會出。

附上本次走Dblink導入的腳本：

場景二：

源端：19.3

目標端：12.2.0.1

將dmp文件從源端導出并已傳至目標端，在目標端進行導入的時候，發現impdp卡在連接數據庫這一步，定住，不動了。我滴個乖乖，真的是見了錘子了。

導入日志如下：

在標注這里就沒有日志輸出了。就像兩個互相欽慕已久的年輕人，好不容易疫情下開個房，良辰美景之際，坐床上聊天到天亮，沒有進一步動作，腦袋被驢踢了吧。。。

查看impdp進程，發現并沒有派生sqlplus進程，證明還沒到連接數據庫那步

是不是主機資源有什么異常，查看后發現內存緊張，swap都使用了85%了

那到底跟內存有沒有關系呢？決定嘗試釋放內存試試。由于是測試庫，只要確認應用沒用即可重啟實例。重啟實例之后內存及swap均釋放不少，再次導入成功。

場景三：

源端：19.3

目標端：12.2.0.1

將dmp文件從源端導出并傳至目標端，在目標端進行導入的時候，報19C導出的dmp文件不兼容12C：

解決辦法：

在19C expdp導出時加入參數version=12.2.0.1.0即可

最后，很多看官可能會問，萎大濕啊，你這些腳本都是可以直接copy使用的，但你用的是圖片，你是啥居心啊？

本萎大濕只想說，年輕人，我是為你好，用這種方式來鍛煉你的手速。

好了，本次分享到此結束，咱們下回分解再見，周末愉快。