多套Oracle10g整合遷移到11g的方法是什么

這篇文章主要講解了“多套Oracle10g整合遷移到11g的方法是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“多套Oracle10g整合遷移到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
   遷移的核心就在此了，行與不行全看這里了。

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

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

感謝各位的閱讀，以上就是“多套Oracle10g整合遷移到11g的方法是什么”的內容了，經過本文的學習后，相信大家對多套Oracle10g整合遷移到11g的方法是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！