資料整合式遷移的一些總結

   說起資料遷移，感覺也算是有些感受了，但是最近參與的幾個遷移案例還是和以前大大不同，以前的遷移專案是比拼停機維護時間，儘可能在短時間誒匯入大批次的資料，有參與表空間傳輸的場景，還有跨平臺的資料遷移，資料庫遷移式升級等等，相對難度大一些的算是增量資料的遷移場景。為此也算把sqlldr,datapump和exp/imp玩了一圈，最後寫了一個小的工具使用外部表遷移，也算是有了一些談資。
   最近的遷移專案還是有些特殊，有schema級別的遷移，這種情況資料庫版本的影響就沒有那麼大了，基本就是schema級別的平移，這種聽起來還算容易，有些場景是同名schema,同名表的整合，這種情況就有些讓人頭疼，每個owner使用者可能有若干個連線使用者，還需要考慮每個連線使用者的許可權和對應關係。有些使用者如果整合起來重合度夠高，還需要調整使用者名稱。
像比如下面的遷移場景，其實難度基本都不在資料量上，而在在整合的難度上，這個時候資料遷移基本上就成了整合。

如果把上面三個資料庫整合起來，其實也有幾種方式，在11g中直接就是schema複製，匯出匯入即可，對於衝突重複的schema可能需要逐個確認，要不就是省事一些，直接修改使用者名稱加以區分。
     還有一種方案是放在12c的pdb裡面。其實這種方式看起來還是能夠解決大部分的相容問題，但是個人感覺這種方式有個缺點就是會把原來的問題包裝起來，原來的不規範的資料設計我們只是把它整合在一個資料庫裡，哪些問題還是問題，不規範還是不規範，如果其中一個pdb出現了大的效能抖動，影響是全域性的。還有就是R2版本還為釋出，在生產上使用還是存在一點的顧慮，不過那種方式有個很明顯的優點就是省事。對於測試環境的整合還是一種好的方式。
     所以現在重點已經不在於資料量了，主要還是在於環境的整合複雜度，因為涉及的有些系統是測試環境的整合，可能維護時間會寬裕一些，有些是重要的線上業務，可能需要前期準備要更多，保證停機維護時間短。
     大體總結了一下，關於這種整合式的遷移，有一些資訊需要考慮。
1.關於表空間的資訊，這部分資訊源端，目標端做比對，大小，可用空間等做一個比對。
2.使用者的資源管理profile，對於原來使用者設定的profile需要原封不對的複製過來，當然資源的整體使用情況是在合理範圍之內。
3.crontab 原來的庫中的crontab可以直接平移到目標庫中
4.監聽埠，原來庫中的監聽埠可能和目標端不同，這個時候可以根據情況做調整，是新建啟用新的埠還是把埠整合在一個指定的範圍之內。
5.防火牆，這部分資訊需要保證訪問的許可權和源庫要保持一致，當然在不考慮filter chain的情況下，還是簡單的追加即可。
6.使用者許可權，關於系統許可權，角色許可權等，需要和源庫保持基本一致。
7.關於db link這個部分比較糾結，可能需要手工逐個處理，確實這些細節沒有搞頭，但是又不得不做。
8.儲存過程，pl/sql，檢視  這部分資訊還是需要和源庫複製保持一致，當然還是會有一些細節差別。
9.序列 序列的處理其實還是一個比較特殊的部分，為了保證不會出現sequence的當前值比欄位最大值小的情況，需要在遷移後同步sequence的值，對於此，一個比較省事的方式就是重建序列，當然需要注意的部分就是序列的許可權設定，其它可以透過dbms_metadata或者解析dump檔案得到對應的sequence 語句。
10.tns部分，如果是遷移，對於源庫的配置可能就不需要了，但是對於db link相關的tns部分還是需要的。
所以這種整合式遷移的很多場景都是不斷整合結構，這個骨架搭建好了，就好比上了高速公路。資料遷移才剛剛開始。