本文將講述的是Oracle數據庫遷移的一些技巧，包括Oracle數據庫遷移前的准備工作，以及不同類型遷移的處理方法。希望對大家了解Oracle數據庫遷移有所幫助。
去年年底做了不少系統的數據遷移，大部分系統由於平台和版本的原因，做的是邏輯遷移，少部分做的是物理遷移，有一些心得體會，與大家分享。
首先說說遷移流程，在遷移之前，寫好方案，特別是實施的方案步驟一定要寫清楚，然後進行完整的測試。我們在遷移時，有的系統測試了四五次，通過測試來完善方案和流程。
針對物理遷移，也即通過RMAN備份來進行還原並應用歸檔的方式(這裡不討論通過dd方式進行的冷遷移)，雖然注意的是要將數據庫設為force logging的方式，在用RMAN做全備之前，一定要執行：
vIEw plaincopy to clipboardprint? alter database force logging; alter database force logging;
否則可能會產生壞塊。
對於邏輯遷移，在job_processes設置為>0的數值之前，注意job的下次執行時間和job所屬用戶。比如job的定義在之前已經導入，但是在遷移之時，job已經運行過，那麼遷移完成之後，job的下次時間還是原來的時間，這樣可能會重復運行。另外，job通過IMP導入後，job所屬用戶會變成導入用戶的名稱，顯然job原來的用戶就不能對JOB進行管理了，可以通過下面的sql進行修改：
vIEw plaincopy to clipboardprint? update sys.job$ set lowner=cowner , powner=cowner; update sys.job$ set lowner=cowner , powner=cowner;
在遷移之前，應該禁止對系統進行結構上的修改和發布，比如表結構，索引，存儲過程包等。
如果是用exp/imp導入的對象，包括存儲過程等，應該檢查對象是否與原生產庫一致，比如由於dblink的原因，imp之後，存儲過程不能創建，導致有部分存儲過程丟失，盡管這些存儲過程可能沒有被使用。
下面是一些加快遷移速度的技巧：
通過dblink，使用append insert的方式，同時利用並行，這種方式比exp/imp更快
對於有LONG類型的列，insert..select的方式顯然是不行的，可以通過exp/imp的方式，但是這種方式速度非常慢，其原因在於imp時一行一行地插入表。有另外一種方式，即sqlplus的copy命令，下面是一個示例： vIEw plaincopy to clipboardprint?
spool copy_long_table_1.log conn / as sysdba set copycommit=2000 set arraysize 30 set long 10485760 copy from system/xxxx@source_db append username.table_name using select * from username.table_name; spool off exit spool copy_long_table_1.log conn / as sysdba set copycommit=2000 set arraysize 30 set long 10485760 copy from system/xxxx@source_db append username.table_name using select * from username.table_name; spool off exit
不過，sqlpus的copy命令不支持有timestamp和lob列類型的表。如果有timestamp類型的表，可以通過在exp時，加上rowid的條件，將一個表分成多個部分同時操作，對於有lob類型的表，也可以同樣處理(因為insert …select方式下，有lob類型列時，也同樣是一行一行地插入)。注意在這種方式下，就不能使用direct的方式exp/imp。下面是exp導出時parfile示例：
query="where rowid>=dbms_rowid.rowid_create(1,71224,52,9,0) and rowid<=dbms_rowid.rowid_create(1,71224,55,1038344,10000)" file=/dumpdata/n1.dmp tables=username.table1 constraints=n grants=no indexes=no buffer=104857600 ... ... query="where rowid>=dbms_rowid.rowid_create(1,71224,423,137,0) and rowid<=dbms_rowid.rowid_create(1,71224,432,59272,10000)" file=/dumpdata/n6.dmp tables=username.table1 constraints=n grants=no indexes=no buffer=104857600 query="where rowid>=dbms_rowid.rowid_create(1,71224,52,9,0) and rowid<=dbms_rowid.rowid_create(1,71224,55,1038344,10000)" file=/dumpdata/n1.dmp tables=username.table1 constraints=n grants=no indexes=no buffer=104857600 ... ... query="where rowid>=dbms_rowid.rowid_create(1,71224,423,137,0) and rowid<=dbms_rowid.rowid_create(1,71224,432,59272,10000)" file=/dumpdata/n6.dmp tables=username.table1 constraints=n grants=no indexes=no buffer=104857600
將表分成幾部分同時操作，不僅僅可以利用rowid，也可以利用表上的列，比如說，表上有一個created_date的列，並且保證是遞增插入數據，那麼這種情況下，也可以使用這個字段將表分成不同的范圍同時進行導出和導入。不過使用ROWID通常具有更高的效率。
當然對於有lob列的表，可以按上述方式，拆成多個insert方式同時插入，不需要exp/imp。
對於特別大的分區表，雖然使用並行可以提高速度，但是受限於單個進程(不能跨DB LINK進行並行事務，只能並行查詢，也即insert..select只能是SELECT部分才能進行並行)的處理能力，這種方式下速度仍然有限。可以並行將數據插入多個中間表，然後通過Exchange partition without validation 的方式，交換分區，這種方式將會大大提高了速度。
有朋友可能會問，為什麼不並行直接插入分區表，當然如果是非direct path(append)方式，則是沒問題的，但是這種方式插入的性能較低。而direct path的方式，會在表上持有mode=6(互斥)的TM鎖，不能多個會話同時插入。(update: 在insert 時使用這樣的語句：insert into tablename partition (partname) select * from tablename where ….，更簡單更有效率。)
遷移時，將數據分成兩部分，一部分是歷史表，第二部分是動態變化的表，在遷移之前，先導入歷史表，並在歷史表上建好索引，這無疑會大大減少遷移時業務系統中斷時間。
遷移之前，考慮清理掉垃圾數據。
遷移時，應保證表上沒有任何索引，約束(NOT NULL除外)和觸發器，數據導入完成後，再建索引。建索引時同樣，同時使用多個進程跑腳本。索引創建無成後，應去掉索引的PARALLEL屬性。
在創建約束時，應按先創建CHECK約束，主鍵，唯一鍵，再創建外鍵約束的順序。約束狀態為 ENABLE NOVALIDATE，這將大大減少約束創建時間。而在遷移完成後，再考慮設回為ENABLE VALIDATE。
通過使用dbms_stats.export_schame_stats和dbms_stats.import_schame_stats導入原庫上的統計信息，而不用重新收集統計使用。
朋友們可以看到，以上均是針對9i的，實際上在10g甚至11g環境下，也仍然很多借鑒意義。當然這些技巧不僅僅用於完整的數據庫遷移，也可以應用到將個別表復制到其他數據庫上。
這裡沒有提到的是利用物化視圖或高級復制、觸發器之類的技術，因為這些技術，畢竟要修改生產庫，對生產庫的運行有比較大的影響，因此，只有在停機時間要求特別嚴格，而在這個時間內又不能完成遷移時才應該考慮。
從遷移的經驗來說，只有完善的流程，完整的測試才可以保證成功。這裡只是列舉了一些小技巧，如果對整個遷移過程有興趣，可以針對這個話題再進行討論。
