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

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

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

本篇就本萎大濕遇到的幾個(gè)數(shù)據(jù)導(dǎo)出導(dǎo)入(EXPDP/IMPDP)遇到的問題進(jìn)行一個(gè)分享。希望對(duì)各位看官有所借鑒。

場景一：

源端：12.2.0.1

目標(biāo)端：19.3

在目標(biāo)端通過imdp走dblink方式導(dǎo)入時(shí)，報(bào)ORA-39097，ORA-39065，ORA-03150

報(bào)錯(cuò)截圖如下：

從圖中我們可以看到JOB由于通道關(guān)閉導(dǎo)致導(dǎo)入失敗，最開始本萎大濕懷疑是網(wǎng)絡(luò)問題，通過ping，traceroute等各種姿勢確認(rèn)網(wǎng)絡(luò)沒問題。

心煩意燥之下，本萎大濕自我安慰任務(wù)報(bào)錯(cuò)是偶發(fā)的，并再次嘗試，在成功導(dǎo)入幾個(gè)表之后又出現(xiàn)通道關(guān)閉報(bào)錯(cuò)。多次嘗試之后，本萎大濕放棄了。

他丫的就一個(gè)導(dǎo)數(shù)而已，難道又遇上了19C數(shù)據(jù)泵走dblink方式的兼容性BUG？！去MOS擼擼吧，MOS上發(fā)現(xiàn)很多關(guān)于ORA-39097，ORA-39065報(bào)錯(cuò)的文章，但沒一篇跟本萎大濕情況是類似的。

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

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

導(dǎo)出DMP文件到本地，然后SCP至目標(biāo)端再impdp導(dǎo)入，保證啥報(bào)錯(cuò)都不會(huì)出。

附上本次走Dblink導(dǎo)入的腳本：

場景二：

源端：19.3

目標(biāo)端：12.2.0.1

將dmp文件從源端導(dǎo)出并已傳至目標(biāo)端，在目標(biāo)端進(jìn)行導(dǎo)入的時(shí)候，發(fā)現(xiàn)impdp卡在連接數(shù)據(jù)庫這一步，定住，不動(dòng)了。我滴個(gè)乖乖，真的是見了錘子了。

導(dǎo)入日志如下：

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

查看impdp進(jìn)程，發(fā)現(xiàn)并沒有派生sqlplus進(jìn)程，證明還沒到連接數(shù)據(jù)庫那步

是不是主機(jī)資源有什么異常，查看后發(fā)現(xiàn)內(nèi)存緊張，swap都使用了85%了

那到底跟內(nèi)存有沒有關(guān)系呢？決定嘗試釋放內(nèi)存試試。由于是測試庫，只要確認(rèn)應(yīng)用沒用即可重啟實(shí)例。重啟實(shí)例之后內(nèi)存及swap均釋放不少，再次導(dǎo)入成功。

場景三：

源端：19.3

目標(biāo)端：12.2.0.1

將dmp文件從源端導(dǎo)出并傳至目標(biāo)端，在目標(biāo)端進(jìn)行導(dǎo)入的時(shí)候，報(bào)19C導(dǎo)出的dmp文件不兼容12C：

解決辦法：

在19C expdp導(dǎo)出時(shí)加入?yún)?shù)version=12.2.0.1.0即可

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

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

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