多套Oracle 10g整合遷移到11g的方案

   在資料遷移中，除了跨平臺，全量，增量資料遷移之外，還有一類會把已有的難度升級，那就是整合式遷移，比如原來有兩個資料，遷移後是一個，類似這樣的需求，如果再加上平滑升級資料庫版本，那就值得我們好好想想方案了。

  如果兩個源庫不大，其實直接使用Datapump不失為一種方法，最大的優點就是操作簡單，可控性強，而瓶頸也很明顯，隨著資料量的增長，這個遷移時長就會線性增長，從邏輯遷移的角度來看，對於版本升級的依賴性不高。

   而如果兩個源庫都很大，比如都是5T這樣的級別，整合起來就是10T,這樣的量級，給你一個小時搞定，而且還要做資料庫的平滑升級，難度就相當大了。

    我們來簡單理一下時間主要都花在哪裡了。

     1.資料匯出，我們還需要額外配置的磁碟空間和儲存，基本是200%以上的冗餘空間才可以，我們拍腦袋給個時間，比如30分鐘。

     2.資料dump傳輸到目標庫，這個時間依賴於幾個點，比如源庫的網路鏈路配置，頻寬上限等。假設這些都不是問題，還是拍腦袋，至少得60分鐘

    3.如果按照預想的計劃到了這一步，資料遷移的工作還沒正式開始，時間就用完了。我們硬著頭皮繼續，資料匯入，按照目前做PCIE-SSD POC的資料，5T按照最理想的情況，非歸檔匯入至少得500分鐘

     所以上面的方案就註定了是一個失敗的遷移案例，但是我們可以從中最佳化出很多東西，直到滿足我們的需求為止。

    我們拋開上面的方案來，簡單回憶一下，資料庫遷移的本質，資料庫升級的本質，首先資料可以大體分為系統表空間資料(system,sysaux,undo),應用資料（表資料，索引等），只是表現形式會是表空間，資料檔案，如果跨平臺，我們考慮的資料的邏輯一致性，而如果不跨平臺，考慮的是儘可能按照物理一致性來考量。在整合式遷移中，物理一致性就很難實現，但是我們可以最大程度的實現。

    然後是資料庫升級的本質，本質上資料庫升級就是資料字典升級，對於資料檔案來說，簡單來說，可以認為沒有差別。

   所以資料庫從低版本升級到高版本，比如10g到11g,資料檔案本質上是不變的，那麼變化的是資料字典，我們就可以取長補短。我們只關注資料字典的這部分，遷移的時候就會有很明確的方向。

   那麼上面失敗的案例如何最佳化呢。我們可以極大的減少匯出的時間，減少資料dump傳輸的時間，說得更加自信一些，我們能不能不匯出資料，不傳輸dump。答案顯然是可以的，那就是充分利用Data Guard。

   這樣前期的工作在正式遷移前都已經就位了，升級的過程中我們需要做得事情就是關注於資料字典的升級，而遷移的部分怎麼來做呢，就是透過傳輸表空間的方式來實現。

    假設我們要遷移的資料庫是peak,extradb,我們計劃整合後的資料庫為peak,那麼在伺服器上應該會有下面的例項，很明顯有兩個名為peak的資料庫，因為ORACLE_HOME的不同，所以不會衝突。

$ ps -ef|grep smon
oracle    77606      1  0 Jul03 ?        00:00:03 ora_smon_extradb
oracle    97643      1  0 14:39 ?        00:00:00 ora_smon_peak
oracle    98133      1  0 14:49 ?        00:00:00 ora_smon_peak
oracle    98486  98195  0 15:15 pts/0    00:00:00 grep smon

   按照目標庫最終的結果，我們的oradata下的目錄結果大體如下：

drwxr-xr-x 2 oracle oinstall 4096 Jul 14 15:04 extradb
drwxr-xr-x 2 oracle oinstall 4096 Jul 14 15:01 peak
drwxr-xr-x 2 oracle oinstall 4096 Jul 14 14:46 peak_old

peak是最終的資料檔案，extradb和peak的資料檔案統統在peak目錄下面，而extradb的系統表空間在extradb目錄下，源庫peak的資料字典在peak_old下。

   如果要遷移資料檔案，在備庫上操作很簡單，可以參考如下的動態SQL.

  select 'alter database rename file '||chr(39)||name||chr(39)||' to '||chr(39)||replace(name,'/extradb/','/peak/') ||chr(39)||';' from v$datafile;

   這個時候peak目錄下的檔案就像參加一個聚會一樣，大家都坐在一起，但是彼此之間還缺少聯絡，還沒有連線起來。

   遷移前，需要做一個基本的檢查，當然這個工作是提前要做好的。到時候至少驗證一下即可。    

    exec dbms_tts.transport_set_check(TS_LIST=>'USERS,PEAK_DATA,PEAK_INDEX,PEAK_CHANNEL_DATA,PEAK_CHANNEL_INDEX,PEAK_NEW_DATA,PEAK_NEW_INDEX',INCL_CONSTRAINTS=>TRUE,full_check=>true);

然後檢視select *from transport_set_violations;
是否有衝突的資訊

遷移的時候，把表空間置為read only狀態，可以使用如下的動態SQL來生成批次的遷移指令碼。

select 'alter tablespace '||tablespace_name ||' read only;' from dba_tablespaces where tablespace_name not in ('SYSTEM','SYSAUX','UNDOTBS1','TEMP');
  匯出資料字典的資訊：

exp \'sys/oracle as sysdba\' file=exp_tts_peak.dmp transport_tablespace= y tablespaces=USERS,PEAK_DATA,PEAK_INDEX,PEAK_CHANNEL_DATA,PEAK_CHANNEL_INDEX,PEAK_NEW_DATA,PEAK_NEW_INDEX log=exp_tts_peak.log
這個dump其實很小，而且匯入的過程時間也很短。

接下來的工作就很瑣碎了，就是初始化基本的使用者資訊，準備匯入資料字典的資訊，這裡需要提到一點的是users表空間的部分，這個表空間整合肯定會衝突，所以如果條件允許，我們可以給表空間改一下名字，避免衝突無法匯入。

   匯入的部分語句如下，這個過程就是最終的對映，其實就跟一次聚會一樣，彼此介紹大家互相認識，產生了連線。

imp \'sys/oracle as sysdba\' file=exp_tts_peak.dmp transport_tablespace=y tablespaces=USERS,xxxxx,U01/app/oracle/oradata/peak/peak_new_data04.dbf,/U01/app/oracle/oradata/peak/peak_new_index04.dbf log=imp_tts_peak.log
   遷移的核心就在此了，行與不行全看這裡了。

    而遷移之後，切記需要把表空間置為讀寫狀態，這樣一來大部分的遷移工作就提前準備好了。

    如果滿打滿算，準備充分，半個小時搞定全然不成問題。