今天主要跟大家分享一下XTTS，我在網上曾看過相關討論，但發現按網上講的那些去實際操作的話，還是會遇到一些坑，並不能實際落下來，所以今天想跟大家分享一些實戰乾貨。
一、什麼是XTTS
首先什麼是XTTS。XTTS其實是從TTS來的，TTS大家做過嗎？TTS其實也是傳輸數據的一種手段，傳輸數據的時候可能用過EXP的方式，再往後可能用數據泵導入導出一些數據，或者去做備份然後再恢復。其實還有一種方式是用TTS，TTS就是傳輸表空間，把表空間傳輸出去，數據從一個庫傳輸到另外一個庫，而XTTS是在TTS基礎上做了一些更新，支持了跨平臺，再有一個可以支持增量備份。
因爲過去傳統的TTS是不支持增量的，我們可以想象一下，一個表空間從一個庫拷貝到另外一個庫，轉移過程當中業務新增的數據是有所丟失的。
二、適用場景
1數據泵
我們做數據遷移的時候大概有三種手段，第一種是數據泵，這種方式進行數據遷移，爲了保證應用不丟數據，做的時候需要把應用停掉，停完應外之後數據沒有更新了，可以能保證所有業務表的一致性，這種方式操作起來其實是最簡單的，它比較適用的場景就是數據量比較小、數據大概在5T以下，使用數據泵會方便很多。
2GoldenGate
再往下一種就是我們在做一些重要的大型系統，對它進行遷移時，我們往往會使用GoldenGate，它遷移的時間很短，剛纔使用數據泵時需要提前把應用停掉，或者允許遷移過程中的數據丟失，但是對於GoldenGate而言，在準備的階段數據一直是同步的，只有業務正式割接時才把業務停掉，切換連接串，切到新的庫上，停機時間十分短暫。
3XTTS
我們再看一下XTTS，XTTS其實也是類似於GoldenGate的方式，也是前期要有一個準備，有一個數據的初始化，數據初始化之後，它是後續作爲一個增量的恢復，把我們初始化之後的那些變更數據，使用增量的備份和恢復，去把之前的數據往前補上，到最後應用切換時，把最後一次小增量再補回來。這樣我們保證割接的時間便會比較短暫。
最短停機時間，最少數據丟失的一種，這是甲方的訴求。那麼我來總結下三種方式：
數據泵、GoldenGate、XTTS這三種方式都是支持跨版本、跨平臺、停機時間，對於GoldenGate來說它的停機時間是最短的，數據泵是停機時間最長，XTTS是介於這兩者之間的，我們後面會進行更深入的討論，看一下XTTS實際的步驟，在看完這個步驟之後，就可以看到時間具體花在哪。
三、XTTS的基本操作步驟
對於現在很多大型企業來說，現在有一個很大的環境是去IOE，但O是很難去掉的一個東西，而I和E其實是很多廠商開始實施的事情，這裏就有一個很重要的點就是跨平臺，平臺會從以前的小機遷移到x86，所以我們需要考慮到跨平臺的問題。
1TTS的基本步驟
A、將源端數據庫表空間設置爲READ ONLY模式。
B、傳輸數據文件到目標系統。
C、轉換數據文件爲目標系統的字節序。
D、在源端導出元數據，並在目標端導入。
E、將目標端的數據庫表空間設置爲READ WRITE。
講解XTTS前可以先看一下TTS，很多同學想必都用過TTS。TTS操作起來很簡單，第一步是把源端的表空間設置爲READ ONLY，把源端的數據文件傳輸到目標端，拷貝過去就可以，拷貝過去之後會牽扯到轉換字節序的問題，然後是在源端對源數據做一個元數據的導出，在目標端把元數據再導入，導入之後我的目標端就已經能看到用戶的數據，最後把目標端表空間置爲READ WRITE。
2XTTS的基本步驟
A、將源端數據文件傳輸到目標系統。
B、轉換數據文件爲目標系統的字節序。
C、在源端創建增量備份，並傳輸到目標端。
D、在目標端恢復增量別分。
E、重複多次操作C和D步驟。
F、將源端數據庫表空間設置爲READ ONLY模式。
G、最後一次執行C和D步驟。
H、在源端導出元數據，並在目標端導入。
I、將目標端的數據庫表空間設置爲READ WRITE。
再看到XTTS的步驟，猛的看上去這個步驟比TTS多了很多，但其實它中間變化很少，其實E這個步驟寫的是重複C和D，G這部分也是重複C和D，真正多的步驟是在源端進行一個增量的備份，把它傳輸到目標端，在目標端做一個增量的恢復。
我們談談做TTS具體存在哪些問題。我們把源端的一個表空間置成了READ ONLY，這時已經不能提供正常業務了，對於5乘8的系統來說，對它的影響其是比較小的，可以接受這種情況的。但對於7*24小時的業務來說，不可能在遷移的過程中隨便的停掉源端的業務，這種肯定不能接受的，這個時候就需要遷移的過程當中儘量保證業務是可用的，而XTTS就可以保證源端的業務遷移前一直可用。
3XTTS的參數設置
XTTS涉及到的參數，乍一看感覺比較多，其實可以分成兩部分的參數，XTTS可以使用兩種方法去傳輸數據。我個人是建議使用DBMS_FILE_TRANSFER數據包的方式去做。
第一個是平臺號，可以通過語句從源端數據庫裏面查詢到。第二個是源端的數據文件目錄，第三個是目標端的一個目錄，第四個是目標端創建的db_link，剩下幾個是源端備份保存路徑，目標端備份文件的保存路徑，還有目標端增量備份的路徑。底下這兩個都叫目標端文件的路徑，這兩個有什麼區別呢？這個目標端備份的路徑可以理解爲，你遷移完之後，你數據文件所在的路徑，即遷移完之後，我把數據從這邊遷移到了這邊，新的數據文件在目錄裏面就是它的目錄，backupondest是增量備份文件目錄，增量備份文件是從源端產生的，是源端做完第一次初始化之後，源端需要對這段時間做一個增量的備份，而這些備份集放在這個目錄裏面。
XTTS案例-準備
下面講一個簡單的例子，看一下XTTS操作是什麼樣的，首先第一步是在源端，源端執行如下命令：
§ 源端運行perl腳本，操作命令
$ORACLE_HOME/perl/bin/perl xttdriver.pl –S
該操作將生成xttnewdatafiles.txt、getfile.sql兩個文件。
XTTS案例-數據文件拷貝
首先需要在配置信息裏面，把這些信息做好配置，做好配置之後可以在源端執行—S操作，當然在這個位置需要設置上要傳輸哪一些表空間，執行完—S會生成兩個文件。然後，我們要把生成的那兩個文件傳輸到目標端，傳輸到目標端之後執行—G這個參數，會把源端數據文件抽到目標端。
目標端執行命令：
XTTS案例-進行第1次增量備份
因爲抽取過程往往是比較費時的，所以我們需要把這一段時間的數據再追回來，追回來時在源端做一次增量備份，這個備份指的是從第一次拽數據文件到做本次增量備份的時間段內新增的數據，執行如下命令，這樣執行完了文件的備份，目錄底下生成三個文件，做增量恢復的時候需要把它產生的文件，以及增量備份級同時拷到目標端。
$ORACLE_HOME/perl/bin /perl xttdriver.pl –i
該命令將對xtt.properties參數文件中指定的表空間，使用進行一個增量備份，同時會生成tsbkupmap.txt、incrbackups.txt、xttplan.txt三個文件。
備份的數據是從做xttdriver.pl -S時在xttplan.txt文件中記錄的SCN開始的。備份完成後需要將這3個文件連同增量備份集一起傳輸到目標端。
XTTS案例-進行第1此增量恢復
拷貝到目標端後，我們就執行一下—r操作，完了之後把增量備份恢復到了目標端。然後回到源端執行Pl—s操作，確認了增量備份已經完成了恢復，這樣下次再做增量備份時，就從上一次做增量備份的點繼續往後去做備份。
但是如果一套庫上有多個實例的話，在執行該步驟之前，需要對環境變量進行確認，如檢查當前ORACLE_SID是否是需要執行的SID，否則可能會恢復到其他實例上。（並非是真實的恢復，因爲其他實例跟這個備份集沒有任何關係，但恢復的過程會在其他實例上進行一遍，如關閉/啓動數據庫，包括增量恢復的日誌都會在另一個數據庫上顯示。）如果發生了這種事情，不用緊張，調整好環境變量，再執行一次perl xttdriver.pl –r即可。誤操作的實例不受影響。
XTTS案例-進行SCN推進
解釋下—s這個過程。假設初始化數據文件時SCN號是100，做增量時SCN號是200，這之間數據是從100到200之間，如果做完—s之後再做增量備份，這個SCN號就變成200了。如果不做—s，就意味着在源端做恢復的時候，有可能出現了異常，我沒有恢復成功，這會我再去做增量備份，還是從100開始往後做。
$ORACLE_HOME/perl/bin/ perl xttdriver.pl –s
該命令將修改FROM_SCN，用於確定下一次增量備份的起點。
建議在【目標端】每次做完recover動作後，【源端】就執行一次該命令，以免遺忘。
XTTS案例-最後的增量備份和恢復
最後一次做備份及恢復時有很重要的一步，就是我們把源端的表空間設成RARD ONLY，再做一次備份和恢復，這樣就完成了數據文件傳輸的過程。最後的步驟還是元數據的導入，最後這個步驟和TTS步驟幾乎是一樣的。導出和導入的命令也是很簡單。
【原庫端】表空間設置爲READ ONLY
alter tablespace XXXX read only;
【原庫端】做最後一次增量備份
perl xttdriver.pl –i
【目標端】做最後一次增量恢復
perl xttdriver.pl –r
在執行完恢復操作後，腳本會自動將目標庫重啓，不需要人工干預，如果出現到mount狀態出現異常，根據情況手工執行後續命令。
剛纔說的是理想的實驗環境過程，通過這個過程大家可以簡單瞭解XTTS整個過程，而從這個過程大家會發現XTTS其實是很簡單的一個過程，第一步是寫配置文件，配置文件裏面寫好我們的一些系統裏的信息，它的平臺號，寫上傳輸哪一些表空間，以及設置一些文件的源端的地址，目標端的地址配備好之後，然後去執行一些後面的參數，都是很簡單的一些操作，下面我們就考慮一些實際當中的一些案例。
四、XTTS案例分享
1運營商環境
首先是目標端是生產庫，第二個是源端的數據量是20TB+，每天歸檔量是1TB+，本地空間不足2TB，網絡單進程是35MB/S，業務中斷時間是3小時內，業務中斷時間這麼短，數據量比較大的情況下，第一時間就會考慮GoldenGate，因爲它的數據是實時傳輸的，最後保證最後中斷時間比較短。
大家入行業時大概都聽說過DBA是比較清閒的一份事業，這個其實是每個人剛入行時的願景，實際工作當中往往碰不到，尤其遇到這種需求時。在這種情況下，如果用GoldenGate的話，就需要把數據庫裏的每一個用戶去分組做一個導出，導出完之後再去目標端做一個個恢復，恢復完之後建立了某幾個用戶的連接之後再循環操作。再加上每次傳出數據量只有1TB，網絡速度又不是很高，時間和工作量是一個很大的情況。基本上至少要兩週的時間才能完成GoldenGate的搭建，這樣再過一段時間穩定之後，業務方纔會去允許你做正式的割接，這個工作量可能大家都深有體會。實際上， XTTS可以較輕鬆地解決這個問題。
首先，數據量雖然是20TB，但是調用DBMS_FILE_TRANSFER包，我們可以很輕鬆地把源端數據文件傳輸到目標端，傳輸的過程當中人爲不需要干預的，週末的時候讓它傳輸文件就好了，一個週末傳完數據文件之後，週一來了之後對它進行從週五到週一這段時間增量數據做一個恢復就OK，只要保證我在正式遷移的那一天，我差的數據比較少的情況下就可以完成遷移的工作。
但XTTS也並非完美，它存在一個問題，就是在它做恢復時，就是剛纔我們看到的那個步驟需要重啓數據庫，這個案例裏面對的問題是目標端數據庫也是一個生產庫，這種情況下如何破解呢？很簡單。
我們只需要創建一個pfile就可以了，這樣我在做數據文件恢復的過程中，就不會影響到我的生產環境。再有一個問題就是考慮如何把整個最後增量的備份和恢復時間縮短到可控的時間（三個小時之內）。
2如何加速XTTS
我們來看一下這個XTTS整個的時間流程，準備階段、初始化和N次增量備份恢復，這些都是遷移之前的，只需要考慮實際停業務的時間，這段時間做表空間只讀，增量備份恢復，元數據導入，數據校驗。我們知道表空間的只讀和數據的校驗，這兩個時間是固定的，表空間只讀速度很快，關鍵的時間點是增量的備份和恢復的時間，以及元數據的導入時間。
這是一個實際的案例，我們在做增量備份時，一天的數據，因爲它每天的歸檔量是1T，每24個小時業務數據需要備份的時間是6個小時，這種情況下再加上網絡速度，備份是需要6小時，傳輸這些增量備份時間也需要6小時，恢復需要4個小時，時間一加是6+6+4就是16個小時，整個備份恢復的時間是一個很長的時間，換句話說，完全不可能縮減到3小時以內。
其實我們可以利用Oracle的一些特性，比方說它有一個BCT的特性，我們可以開啓BCT的特性，它做增量備份時，它只會掃描有變更的數據塊，這樣就可以加速備份的時間。開啓的方式也很簡單，執行如下命令就直接開啓，需要注意的目錄需要共享的目錄。
再有一個問題就是關於傳輸的問題，有了增量備份，增量備份放在源端，放在源端之後，傳輸備份也是需要一定時間。剛剛看到實際環境裏面，網絡環境是35兆每秒，對於24小時數據，產生的備份文件也是1T，拿1T除以35兆每秒，時間也很長，我們如何優化傳輸的時間呢？這裏面有一個小技巧，就是在RMAN裏面開啓並行，表空間最多對應那麼多分片，這樣有了分片之後就可以開不同的進程傳輸數據文件。
爲什麼說這個有意義呢？因爲在生產環境裏面，我們發現有一些表空間會比其他表空間大很多，就是它的容量很不均勻，有可能一個表空間的大小就可以超過其它表空間很多倍，雖然我是一口氣對十幾個表空間做遷移的工作，但那一個表空間傳輸的時間是最長的。我經過開啓並行之後，把一個表空間分成8個片，分組進行傳輸，這樣就可以加快傳輸的速度。
再有一個是我們要考慮元數據導入的時間，正常情況下，元數據導入的時間73%花在統計信息導入這一塊。這塊有一個小的技巧可加入統計信息導入，就是我第一次導入這個元數據的時候，把統計信息排除，排除掉之後可以快速地第二次導入，第二次導入時會加入一個並行，這一塊就可以很快速地導入這些文件。同時這一步可以把之前沒有導入的這些過程，視圖、包、觸發器這些信息也可以導入進去。表空間裏面只包含表、索引這些東西，但下面這些東西其實是存在系統表空間裏的，系統表空間沒有通過XTTS做遷移，所以這部分數據如果不導入的話是丟失的。
3遷移前的準備
最後我們再來看看整個XTTS在前期準備當中還需要做哪一些工作。首先是對象的統計，跟業務確認需要傳輸哪一些數據，哪一些表空間是遷移的對象。第二個是源端字符集的檢查。第三個是檢查表有沒有空段，第四個是失效對象檢查。第五是基於XMLSchema的HMLType對象檢查。第六個是目標端創建檢查用DBlink。第七個是檢查源數據庫的目標庫具有重複名稱的表空間。最後是檢查是否存在應用用戶建在systmwem、sysaux、users上的情況。
然後表空間自包含的檢查，所有表空間裏面是否都是自包含的，對錶新舊環境role，對比新舊環境profile，在新環境當中對比並創建用戶，生成恢復用戶默認表空間和臨時表空間的腳本，創建非默認的temep表空間，最後一部分是軟件包上傳。
五、總結
簡單總結一下，XTTS支持跨平臺遷移，操作起來十分方便，使用XTTS之後就可以讓DBA過上一個理想中的生活，輕鬆完成遷移工作。最後，它的停機時間較短。
建議大家在做遷移的時候減少批次，批次越多，增量備份的數據越少，數據越少，最後停機時間越短，但是這個過程如果做太多就越容易出錯。謝謝大家！
Q&A
Q1：完成增量備份的時候，假如說要恢復時，能不能用歸檔的方法？
A1：在XTTS裏面是不可以的。
Q2：如果說加快傳輸方式的就要開並行，如果有20t，如果開並行有可能影響現有生產？
A2：沒錯，初始化傳輸數據文件的時候可以開並行，做增量備份的時候也可以開並行，這兩個是不一樣的。其實這個影響主要是網絡傳輸那一塊，看實際的網絡帶寬。
Q3：並行開完了以後傳輸速度是加快，生產不停機可能會影響現在生產，會出現等待事件。
A3：做並行的時候，肯定是先要測試網絡和磁盤性能最大可以開到幾個並行，我們可以開到最大並行減N的方式來保證生產，肯定要給生產留一點空間的。
Q4：EXP導出的時候，有可能會遇到ora-01555的問題。
A4：沒錯，但是導出原數據的過程出現的時間很小的，而且表空已經設置爲read only，表空間的沒有被使用，所以不會出現ora-01555。
Q5：之前說傳輸，從源端到目標端有一個重啓，那塊沒聽太懂。
A5：XTTS在執行—l的時候，會導致目標和數據庫自動重啓到寫nomount狀態下恢復數據文件，這個過程中，可以創建另外一個實例來做恢復這個事情，只有真正的到元數據導入這個步驟的時候，再切換到實際的目標庫就可以了。
PPT下載鏈接：http://pan.baidu.com/s/1bQauxK
原文地址：http://dbaplus.cn/news-10-1121-1.html