共計 3217 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章主要講解了“多套 Oracle10g 整合遷移到 11g 的方法是什么”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學習“多套 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 的方法是什么這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關知識點的文章，歡迎關注！
