楊志洪

• 【DBA+社群】上海發(fā)起人

• 數(shù)據(jù)管理專家,。Oracle ACE、OCM,、 SHOUG/ZJOUG核心成員,、DAMA會員/CCF會員,，譯著《Oracle核心技術(shù)》,。

• 在Oracle OOW、DTCC及2015Oracle數(shù)據(jù)庫技術(shù)大會等全國性技術(shù)會議上發(fā)表主題分享,，并主辦了2014Oracle全國技術(shù)巡講,。

• 2015年創(chuàng)立DBA+社群迅速成為全中國最大的涵蓋數(shù)據(jù)架構(gòu)師、DBA及中間件的專業(yè)社群,。

既然說是又一個數(shù)據(jù)庫遷移,、升級的利器，那自然而然的,，要說到,，其他的利器是什么？

我印象里的第一個,，是exp/imp,，沒錯，這是一對組合,，那是使用svrmgrl的年代,。Svrmgrl從Oracle9i起就沒有了,，但是exp/imp到今天仍然可以用，就如同catproc和catalog一樣,。

Catproc這對神器我在《職場心路：一個老DBA的自白》里有提到（文章里筆誤成cataproc了）,，從這里，我才開始用正眼看Oracle數(shù)據(jù)庫,。

說到這里,，我要順便勘誤下這篇文章的一個錯誤。Part I第四節(jié),，原文有一段“最后在舍友的指點下,，讓程序員把開票查詢功能從3秒鐘降低到1分鐘，問題迎刃而解”,。正確的應(yīng)該是,，“最后在舍友的指點下，讓程序員把開票查詢功能的頻率從3秒鐘降低到1分鐘,，問題迎刃而解”,。同時，順便強(qiáng)調(diào)下所謂的優(yōu)化,，縱觀十幾年的服務(wù)歷程,，優(yōu)化問題的需求，應(yīng)該是最輕松,，且效果最好的,。如果您聽懂了，那么恭喜你,。如果您沒懂,，可以私下找我聊。

話說回來,，exp/imp做遷移太慢了,，但是2002年~2004年的時候，大部分的遷移升級工作我都是用它做的,。

Oracle從一家傳統(tǒng)數(shù)據(jù)庫廠商,，能夠在最近兩年幾乎徹徹底底的變?yōu)榱艘患褻loud的企業(yè)，實在是因為老拉里的基因本身就是不斷挑戰(zhàn),，不斷革新自己,。不論是從他跨界把SUN公司從臨死狀態(tài)搞活，還是帆船賽屌絲逆襲,，用大數(shù)據(jù)勇奪第一,。就算是個小小的數(shù)據(jù)遷移工具，他都是在不斷改進(jìn)。從另一個側(cè)面來說,，那些叫囂去O的小伙伴們,，先把O學(xué)好了，也許更合適些,。

因為exp/imp太慢了,，所以O(shè)racle9i開始，老拉里提供了全新的expdp/impdp,，速度杠杠的,，特別是impdp比imp的提升，那真是數(shù)量級的,。我這些年招人面試,，問到做過哪些數(shù)據(jù)庫遷移/升級，用什么手段/方法時,，絕大多數(shù)也是這2個,。

顯然，Oracle遷移升級工具還有很多,。比如存儲級的復(fù)制,，比如Oracle的DG，比如DBlink,，以及DBUA,，以及我們近幾年用得最多的升級遷移割接神器---Oracle GoldenGate。

嗯,，關(guān)于Oracle GoldenGate,，回頭邀請一位從開始接觸Oracle開始一直研究OGG的小伙伴來分享。

因為2015年,，我們在一些項目上,，有電信運營商的，有電網(wǎng)的,，有金融行業(yè)的,，嗯,，還挺多的行業(yè)項目的升級遷移上用到了XTTS,，積累了不少經(jīng)驗。所以我今天挑了這個主題,。

在此,，感謝下我團(tuán)隊的小伙伴，大兵和海鵬,，今天的分享,，幕后更多是他們的功勞。特別是大兵，我們團(tuán)隊里成長非常迅速的小伙子,。如果你想快速成長,，要一個發(fā)揮的舞臺，歡迎發(fā)簡歷給我,，yangzhihong#shsnc.com ,。北京、上海,、杭州,、廣州，3年以上Oracle經(jīng)驗,，聰明好學(xué),，愿意成長的。我保證你2年后,，完全會驚訝自己居然成長這么快,！

那接下來就是今天的主題xtts了

觀今宜鑒古，無古不成今,，表空間傳輸作為一項從8i時代就開始誕生的技術(shù),，在每個版本中借鑒著當(dāng)時主客觀原因不斷地發(fā)生著巨大的進(jìn)步。

從8i,，tts技術(shù)的誕生，引入了相同平臺相同塊大小之間的表空間傳輸,。到了9i,，tts開始支持同平臺中，不同塊大小的表空間傳輸,。

10g時代,，不僅引入了跨平臺的表空間傳輸方案，也就是我們說的xtts,；10gR2開始支持傳輸整個數(shù)據(jù)庫,。

11gR1開始，可以傳輸表空間中的某個特定分區(qū),。

在11.2.0.4開始,，為了應(yīng)對越來越大的數(shù)據(jù)量，而停機(jī)時間甚至還在減少的情況,，出現(xiàn)了新的解決方案—使用增量備份方式的xtts,。

上表也是官方文檔中對于數(shù)據(jù)傳輸各場景的版本支持匯總,。

說了這么多，有些dba朋友就要問了，xtts的具體實現(xiàn)是怎么樣來的呢,？

不急,，今夜依然漫長，先從傳統(tǒng)的xtts典型步驟開始說起,。

大家可以發(fā)現(xiàn)，對于傳統(tǒng)的xtts的步驟來說：

第一步將表空間置為只讀就意味著停機(jī),，而總體停機(jī)時間中整體數(shù)據(jù)文件的傳輸占了很大的比重,。

基于優(yōu)化這部分時間消耗的考量，11gR4開始出現(xiàn)了一樣新的技術(shù)--xtts via 增備,。

在源端庫保持正常運行的時候傳送所有的數(shù)據(jù)文件,，通過不斷生成的增量備份并恢復(fù)，使正式停機(jī)時間越來越短,，我們來看下它所涉及操作的停機(jī)時間軸,。

為了減少正式的停機(jī)時間,，oracle在xtts中引入了rman的增量備份前滾功能,。通過一次又一次的增量備份，使停應(yīng)用的時間主要包含四個方面：將表空間置為只讀,，最后進(jìn)行一次增量前滾,，元數(shù)據(jù)導(dǎo)入，數(shù)據(jù)文件校驗,，如上圖所示,。和傳統(tǒng)的表空間傳輸相比，通過減少數(shù)據(jù)文件的傳輸時間,，而大大減少了整體停機(jī)時間,。

當(dāng)然新技術(shù)有新門檻，并不是所有場景下都便于使用這個技術(shù),，綜合xtts所需要的版本特性,，操作復(fù)雜度，對于使用增備方式的xtts的適用場景,，做了如下總結(jié)：

版本和平臺限制源于新特性的使用，是硬性規(guī)定,；那么為什么說一定要TB級操作和停機(jī)時間在4小時這個區(qū)間呢,？

大家看完后面的分享就會知道,，增備方式的xtts操作還是較為復(fù)雜的,，對于小數(shù)據(jù)量的遷移，可以用其它較為簡便的方式來進(jìn)行代替，減少無謂的人力,。

至于停機(jī)時間,，這是稍后我們給大家給出的一個最佳實踐中的停機(jī)區(qū)間。

有道是萬丈高樓平地起,，一次完成的遷移也少不了完善的檢查,，下述是檢查項中最為重要的。

具體請參考1454872.1 Transportable Tablespace (TTS) Restrictions and Limitations: Details, Reference, and Version Where Applicable 完成必要檢查,。

只要地基打的牢，風(fēng)吹高樓也不怕

三山半落青天外,，一水中分白鷺洲,，前戲都說完了，接下來從使用的角度開始介紹,，這項遷移家族中的新武器增備方式xtts的,。

首先，我們先了解下增備xtts的四大階段：

關(guān)于初始化階段,，很簡單著重在腳本和參數(shù)的配置

rman-xttconvert_2.0.zip,，目前官方提供的用來執(zhí)行整個操作步驟的驅(qū)動腳本,。

這里需要注意的是環(huán)境變量$TMPDIR，當(dāng)考慮到種種情況,，需要將表空間分批傳送時,，需要指定不同的$TMPDIR目錄。

然后就是最重要的參數(shù)配置了（上圖中列出的最為重要的配置參數(shù)）

其中包括要傳輸?shù)谋砜臻g,，系統(tǒng)版本,，不同同步方式需要用的目錄制定

參數(shù)解釋如下。

具體參數(shù)請結(jié)合自身的實際使用情況,，結(jié)合文檔進(jìn)行配置

對于準(zhǔn)備階段,，也就是將所有的數(shù)據(jù)文件同步到目標(biāo)端的這個階段,，增備xtts提供了兩種方案，上圖是執(zhí)行操作的一個步驟流,。

dbms_file_transfer會根據(jù)源端的目錄結(jié)構(gòu)傳送到目標(biāo)端時配置成相同的目錄結(jié)構(gòu),，但是容易觸發(fā)bug，整個準(zhǔn)備階段的同步過程中容易間斷,，需要后期使用rman單獨數(shù)據(jù)文件的方式傳送失敗的數(shù)據(jù)文件,。

Rman方式目前為止比較穩(wěn)定,，但是它會將所有的數(shù)據(jù)文件后綴改名為xtf，并且每一個批次的數(shù)據(jù)文件只能傳送到一個目錄下,。比較適用于asm的情況,。

不管使用哪種方式完成準(zhǔn)備階段，增量前滾階段的步驟都是一致的,。

在源端執(zhí)行-i參數(shù)后，會直接生成增量備份和臨時文件,，將之傳送到目標(biāo)端后-r參數(shù)開始恢復(fù)即可,。

在增量備份階段還是有以下部分需要注意：

增量備份是基于xttplan.txt中的記錄進(jìn)行的,，如果在每次增備后沒有替換該文件,，下一次的增備又會基于之前記錄的scn開始進(jìn)行。

原庫使用增量備份,，每一次平均消耗兩個power 6 cpu的使用率，需要考慮到原庫的負(fù)載情況開始增備,。如果原庫的配置較高,，可以同時進(jìn)行幾個批次的備份，不過要注意,，目標(biāo)端恢復(fù)只能單個批次進(jìn)行,。

最后說下升級的主要步驟：

步驟雖然簡單,，還是有不少注意事項：

上述的注意事項，基本集中在元數(shù)據(jù)導(dǎo)入時,，那么問題來了,，元數(shù)據(jù)導(dǎo)入出錯怎么辦？

刪除所有的表空間后重新導(dǎo)入,，只有50%的成功幾率，oracle的原話如下：

The import process can modify the file headers at various points during the import, especially when transportable=always is used; it not currently possible to tell at which point in the import process that has happened, not even from a timestamp. The only thing you can do is drop* all of the tablespaces that have been plugged into the target and retry the entire TTS import. If it errors, you will need to recopy/convert all the datafiles again. You cannot do only a partial-tablespace import, as the export file references all tablespaces

不過這只是之后用于補救的方法了,，前期的檢查可以將這種50%的賭博解決于發(fā)生前,。

看完了具體使用的四個階段，也了解了不少注意事項,，大家對增備xtts的感覺如何,？

在分享我們的最佳實踐之前,，先和大家分享一下我們在得出最佳實踐之前，一次完整升級的用時情況,。

在本次遷移中,，數(shù)據(jù)量7.5T,，數(shù)據(jù)文件大小在8T,，目標(biāo)端使用文件系統(tǒng)

每個文件目錄1T，使用rman進(jìn)行傳輸,，分為8個批次進(jìn)行傳輸,。

準(zhǔn)備階段全同步，受限于遠(yuǎn)程掛載的中轉(zhuǎn)目錄網(wǎng)絡(luò)帶寬因素,，每個批次耗時總計2.5小時,。

增量前滾階段，同樣受限于網(wǎng)絡(luò)帶寬因素,，八個批次同步一天的增量數(shù)據(jù),，需要總計2.5小時的操作過程。

在正式遷移中,，因為操作的批次較多和網(wǎng)絡(luò)帶寬受限，導(dǎo)致了最后一次增量前滾耗時也在2小時以上,。

這之后開始進(jìn)行了元數(shù)據(jù)的導(dǎo)入,。

正式遷移當(dāng)天，在元數(shù)據(jù)導(dǎo)入階段中,，統(tǒng)計信息導(dǎo)入耗時3小時,。其余部分導(dǎo)入耗時40分鐘。二次導(dǎo)入系統(tǒng)表空間對象耗時30分鐘,。

下圖是元數(shù)據(jù)導(dǎo)入時,，各方面時間所占比重

在本次遷移中,，統(tǒng)計信息在首批元數(shù)據(jù)導(dǎo)入中,，這一批的元數(shù)據(jù)導(dǎo)入是無法開啟并行，以致時間消耗過久,，占總體比重70%以上,。

每次遷移都有不同的發(fā)現(xiàn)，針對這次遷移實施,，事后總結(jié)如下：

1.掛載共享存儲存放增備的時候,，要加大網(wǎng)絡(luò)帶寬

2.遷移時盡量減少批次，操作越多越容易出錯

3.元數(shù)據(jù)導(dǎo)入時排除統(tǒng)計信息

4.二次對象導(dǎo)入時開啟并行

我們回顧下在使用增備xtts遷移時,，總結(jié)的一些已知bug

大家可以發(fā)現(xiàn),，大部分bug已經(jīng)有了workaround。這里有一點要說一下,，就是使用在準(zhǔn)備階段使用dbms_transfer_file包進(jìn)行傳輸時,，遇到的兩個bug仍然處于開發(fā)人員跟進(jìn)狀態(tài)，我們在遇到后,，和原廠討論暫時使用rman傳輸單個文件的方式進(jìn)行規(guī)避,。

不過呢這也是屬于治標(biāo)不治本，并沒有從源頭上將dbms包執(zhí)行失敗導(dǎo)致的問題進(jìn)行修復(fù),。

上面細(xì)數(shù)了遷移的每個具體步驟和一直的bug列表,，接下來將會和大家分享一下關(guān)于使用增備xtts遷移的最佳實踐。

其實也談不上參數(shù)上的最佳實踐了,，只是經(jīng)驗所得的四個建議和一大杜絕,。

目前準(zhǔn)備階段使用dbms包遇到的bug過多,，同步過程極易打斷,，不建議使用。

目標(biāo)端使用一個大目錄或者asm磁盤組,，目的在于減少同步批次,，簡單最不容易出錯。

中轉(zhuǎn)目錄的掛載則是考慮到正式遷移時消耗在增量備份上面的時間,。

至于元數(shù)據(jù)導(dǎo)入,，相信各位之前看過前一頁的朋友們應(yīng)該不會再有疑問了

然后就是一大杜絕了，在后面我們會有介紹添加了數(shù)據(jù)文件的補救方法,，不過因為要改很多文件,，甚為麻煩，也希望大家不要在漫長的遷移期間為自己增加無謂的工作量了,。

Xtts因為整個操作步驟繁多,，時間周期漫長，在各個階段都存在不少的深坑,，接下來,，我們看下xtts的常見深坑。

首先和大家強(qiáng)調(diào)一定要開啟XTTDEBUG環(huán)境變量,，便于我們在出現(xiàn)問題時的定位,。

這是兩個文檔中沒有提及的錯誤,，在遷移實施中較為常見,，不過因為是在非停機(jī)時間段內(nèi)，所以不影響正式遷移的時間,。

當(dāng)批次過多時,，這兩個參數(shù)越容易出問題，當(dāng)我們的臨時文件出現(xiàn)錯亂時,，想要補救將要消耗很大的心力,。

這兩類容易出問題的對象mos上也有專門的文檔去修復(fù)了,，結(jié)合文檔內(nèi)容進(jìn)行整改,。

最后就是和大家分享下兩種常見場景下的補救措施,。

屋漏偏逢連夜雨的時候,，我們要相信那是柳暗花明又一村的開始,，遇到錯誤不可怕,，研究并解決才是我們做技術(shù)的職業(yè)素養(yǎng)。

首先是準(zhǔn)備階段全同步文件到一半出錯了怎么辦,。

還有就是前面提到的一大杜絕,，在整個遷移過程中，源端添加了數(shù)據(jù)文件怎么辦,。

在dbms包的情況我們需要修改三個文件去保證,。

如果是rman同步，則只需要修改xttplan.txt和xttnewdatafiles.txt即可,。

至此，補救完成,，我們的遷移又可以繼續(xù)進(jìn)行了,。

以上增備xtts的分享就結(jié)束了，作為遷移大家庭中的一員,，大家不要因為其理論上的停機(jī)時間而盲目的選擇它,，古詩云“梅須遜雪三分白，雪卻輸梅一段香”,。最適合的,，才是最好的。