Oracle數據導入的一點心得

按照原本的設想，我不導入索引的話，應該對INDX表空間沒有影響的，但是為何還是導入了這么多的數據呢。查了不少資料，發現還有個

Oracle數據導入

imp user/passwd file=abc.dmp tables=abc indexes=n

Oracle數據導入時(dmp文件)

有一回導數據，數據量比較大，壓縮的dmp文件有15G，，需要將數據往公司的測試數據庫上導。

本以為很簡單，傳好dmp文件，imp導入即可。結果貌似簡單的過程，卻耗費了我不少的時間。

導入前，建立表空間（dvbboss: 80G），建立用戶并指定該表空間。然后導入，在導了半個小時左右后發現報錯，意思是指定的表空間已滿，不能導入了。我郁悶了，80G的表空間還不夠？于是查了一下，令人驚訝的是根據用戶指定的表空間占用率還是0，而已經滿了的表空間只有兩個：

INDX（索引表空間）和dvbcetus，都已經到了99%。將imp停止，并將該用戶刪除，發現一個情況是，對應的這兩個表空間又恢復到原來的狀態了，幾乎是沒有使用。

按照原本的設想，我不導入索引的話，應該對INDX表空間沒有影響的，但是為何還是導入了這么多的數據呢。查了不少資料，發現還有個強制約束的索引。如果光指定indexes=n，則只是將一般的索引排出掉不導入，對于這個也需要進行限制，即：constraints=n，這樣限定后產看INDX表空間發現沒有增長。

約束往往和一個唯一索引/主鍵相關聯，所以僅僅利用indexes=n 選項是不夠的，必須添加CONSTRAINTS=n，才能真正避免導入時的檢查。

另外一個表空間的增長，后來發現是這個原因所導致的：

如果數據庫已經存在dmp文件中建表所需要的表空間，則默認會往該表空間中增加表及數據如果沒有不存在該表空間，則會按照建立用戶：user的時候所指定的表空間里建表與數據。

聲明：本網頁內容旨在傳播知識，若有侵權等問題請及時與本網聯系，我們將在第一時間刪除處理。TEL:177 7030 7066 E-MAIL:11247931@qq.com