最近測試了使用datapump來遷移百G資料的場景，因為實際需要，需要把Unix下10gR2的庫遷移到Linux下11gR2，所以這個過程相對來說牽制也較多。考慮了多種方案，最後權衡後決定使用datapump來遷移。 其實整個遷移的過程還算順利，完整模擬了整個生產環境的遷移情況，datapump的全庫匯入還是比較方便省心，只要匯出得當，匯入基本不需要太多的檢查 選項，匯入的過程中的可操作選項也非常有限。如果資料庫裡存在大量的結構資訊，而且關係錯綜複雜，使用datapump還是比較通用快捷。 datapump對於中小型的遷移場景來說還是比較合適，裡面的一個優勢就是並行，但是實際中的並行情況粒度還不夠細， 比如對於下面的這個表，儘管資料量還是比較大，但是匯入的時候還是按照表為單位，無法在表級更細粒度做更多的工作。

 	Worker 10 Status:
 	  Process Name: DW09
 	  State: EXECUTING                       
 	  Object Schema: TEST
 	  Object Name: SWD_BACKPOINT_LOG
 	  Object Type: DATABASE_EXPORT/SCHEMA/TABLE/TABLE_DATA
 	  Completed Objects: 1
 	  Completed Rows: 10,795,489
 	  Completed Bytes: 2,873,852,728
 	  Percent Done: 32
 	  Worker Parallelism: 1
 

當然資料量百G遷移還是很快到，使用datapump遷移時，首先會匯入哪些結構型資訊，然後匯入資料，最後建立索引，大體的效能消耗點就在這三個方面。 對於遷移中存在的一些小問題也總結了一下。 1.首先就是歸檔的情況，在歸檔模式下，這個匯入的過程是兩份寫資料，一份寫入日誌，一份寫入資料檔案，所以IO會有很大的壓力。歸檔還是需要重點關注。

 	ORA-19815: WARNING: db_recovery_file_dest_size of 214748364800 bytes is 100.00% used, and has 0 remaining bytes available.

2.資料問題 如果匯入的過程中出現了下面的報錯資訊，其實還是很無奈的。不過這類資料著實是少數，而且出現這個問題也是約束的校驗方式不夠嚴格導致。

ORA-12899: value too large for column DES (actual: 51, maximum: 50)

ORA-12899: value too large for column DES (actual: 53, maximum: 50)

ORA-12899: value too large for column DIST_SEX (actual: 3, maximum: 2) 如果資料量不大，也可以適當對欄位進行擴充套件，當然是在業務允許範圍內，或者由應用來評估是否需要這批超出限制的資料。 3.資料庫日誌中的警告 在資料匯入的過程中，留意到資料庫日誌裡面有如下的告警資訊：

WARNING: Oracle executable binary mismatch detected.

Binary of new process does not match binary which started instance

issue alter system set "_disable_image_check" = true to disable these messages

這個問題主要在資料庫open時打patch有關，所以唯一能讓我想起來的就是，前些天做orion測試的時候，因為配置的誤導，自己relink了整個$ORACLE_HOME,所以對於這個問題的徹底解決還是可以重灌資料庫軟體。 4.匯入過程中的控制粒度不足 如果全庫匯入的過程中，沒有太多的選項限制，就可能出現下面的警告資訊

ORA-31684: Object type USER:"OUTLN" already exists

ORA-31684: Object type USER:"ANONYMOUS" already exists

ORA-31684: Object type USER:"OLAPSYS" already exists

ORA-31684: Object type USER:"SYSMAN" already exists

ORA-31684: Object type USER:"MDDATA" already exists

ORA-31684: Object type USER:"MGMT_VIEW" already exists

ORA-31684: Object type USER:"SCOTT" already exists

這種情況在絕大多數的情況下還是沒有問題的，就怕這類的資料衝突，所以為了穩妥起見還是需要跳過這些本來資料庫中就有的預設使用者。如果檢視匯入的明細日誌，其實整個過程都會檢查然後忽略，其實我們可以更徹底的遮蔽這些不必要的變更。 在這個基礎上，就是考慮更好的效能，更短的視窗時間，可以做一些對比測試來逐步完善，當然這種測試時間還是比較緊的，所以需要更多的預備工作，保證在生產遷移中能夠平滑過渡。