?數(shù)據(jù)庫遷移是DBA經(jīng)常會(huì)面臨的工作，這二十多年來，我們也做過很多數(shù)據(jù)庫遷移的工作。早期的時(shí)候，作為一個(gè)DBA，考慮遷移方案的時(shí)候總是從數(shù)據(jù)庫的角度去考慮。隨著項(xiàng)目做多了，知識(shí)范圍不斷地?cái)U(kuò)大，加入了很多系統(tǒng)級(jí)的遷移方案，使遷移工作變得更加簡(jiǎn)單了。遷移工作做多了，也難免會(huì)遇到鬼，在這二十多年，上百個(gè)遷移項(xiàng)目中，也確實(shí)遇到過不少坑，有時(shí)候甚至面對(duì)命懸一線的絕境。

?到了后來，面對(duì)遷移方案的選擇，如果是十分重要的核心系統(tǒng)，一定要選擇最為穩(wěn)妥的方案，以備不測(cè)。昨天微信群里有人在問一個(gè)數(shù)據(jù)庫想遷移存儲(chǔ)，有沒有什么好方案，從我腦子里冒出來的都是系統(tǒng)層面的遷移方案，而群里的DBA朋友往往都說的是數(shù)據(jù)庫層面的遷移技術(shù)。實(shí)際上沒有最好的技術(shù)和方案，只有最合適的。具體選擇哪種數(shù)據(jù)庫遷移方案，最終還是要看具體的系統(tǒng)環(huán)境以及遷移實(shí)施隊(duì)伍的技術(shù)能力。

一、存儲(chǔ)復(fù)制

存儲(chǔ)復(fù)制是最近我比較喜歡的一種數(shù)據(jù)庫跨存儲(chǔ)遷移的方法，可以用于很多遷移需求。特別是一個(gè)環(huán)境中存在多種數(shù)據(jù)庫/多個(gè)數(shù)據(jù)庫的場(chǎng)景，用存儲(chǔ)復(fù)制的方式一下子可以搞定所有的數(shù)據(jù)庫，十分便捷。存儲(chǔ)復(fù)制的主要實(shí)施工作都由存儲(chǔ)廠商完成，對(duì)于DBA來說也是最為輕松的，如果出問題，都不需要DBA去甩鍋，肯定是存儲(chǔ)廠商的問題。DBA要做的就是打開數(shù)據(jù)庫，用rman validate校驗(yàn)一下數(shù)據(jù)文件是否存在物理/邏輯壞塊就可以了。十年前一個(gè)金融客戶的核心數(shù)據(jù)庫數(shù)據(jù)庫從9i HA升級(jí)為10g RAC,存儲(chǔ)從IBM 8000系列遷移到HDS高端存儲(chǔ)，采用的就是這個(gè)方案。使用HDS自帶的異構(gòu)存儲(chǔ)虛擬化能力，首先將數(shù)據(jù)從IBM 8000系列存儲(chǔ)復(fù)制到HDS上，最后切換的那一晚上停掉生產(chǎn)數(shù)據(jù)庫，作最后一次增量復(fù)制后，用10g RAC的環(huán)境掛在新的卷，然后UPGRADE數(shù)據(jù)庫，整個(gè)數(shù)據(jù)庫遷移升級(jí)工作一個(gè)多小時(shí)就完成了。

很多DBA會(huì)把卷復(fù)制和存儲(chǔ)復(fù)制看作一碼事，對(duì)于DBA來說，存儲(chǔ)和卷并無不同，反正看到的是一堆裸設(shè)備。實(shí)際上二者還是不同的，卷復(fù)制采用的是卷管理軟件的數(shù)據(jù)同步功能，比如VERITAS的LVM，卷管理軟件天生就是支持異構(gòu)平臺(tái)的，因此使用卷復(fù)制技術(shù)同步數(shù)據(jù)有更廣泛的適用性，而存儲(chǔ)復(fù)制技術(shù)需要存儲(chǔ)本身的支持（不過現(xiàn)在大多數(shù)高端存儲(chǔ)都支持異構(gòu)存儲(chǔ)的存儲(chǔ)虛擬化，因此大多數(shù)情況下都能支持，如果實(shí)在你的環(huán)境中的存儲(chǔ)不支持異構(gòu)復(fù)制，也可以考慮租借一臺(tái)支持你所需要復(fù)制的存儲(chǔ)的虛擬化機(jī)頭來做實(shí)施，費(fèi)用在幾千塊錢到幾萬塊錢不等，看你租借的設(shè)備和租借的時(shí)間）。

大概十年前吧，一個(gè)運(yùn)營(yíng)商從HP小機(jī)上遷移一個(gè)數(shù)據(jù)庫到IBM小機(jī)，存儲(chǔ)也從HP存儲(chǔ)更換為EMC存儲(chǔ)，當(dāng)時(shí)他們?cè)瓉淼南到y(tǒng)使用了VCS，因此使用VERITAS的卷復(fù)制做的數(shù)據(jù)遷移。在IBM端CONVERT數(shù)據(jù)庫的時(shí)候（因?yàn)镠P-UX和AIX都是大端的，所以可以做DATABASE CONVERT，而不需要使用XTTS）遇到了ORACLE 10G的一個(gè)BUG， UNDO表空間CONVERT失敗，數(shù)據(jù)庫無法打開，當(dāng)時(shí)也是驚出一身冷汗，最后通過強(qiáng)制OFFLINE相關(guān)UNDO SEGMENT，重新創(chuàng)建UNDO表空間切換等方式解決了這個(gè)問題，不過完成遷移的時(shí)候已經(jīng)接近早上8點(diǎn)，超出了申請(qǐng)的停機(jī)窗口，差點(diǎn)影響了第二天營(yíng)業(yè)廳開門。所以說，再簡(jiǎn)單的遷移方案，都不能保證不出意外。

二、邏輯復(fù)制

邏輯復(fù)制是一種停機(jī)窗口較為緊張時(shí)候常用的數(shù)據(jù)庫遷移的方案。兩千零幾年的時(shí)候幫助一個(gè)運(yùn)營(yíng)商把計(jì)費(fèi)/賬務(wù)兩大核心系統(tǒng)從Oracle 8i遷移到Oracle 10g的時(shí)候，為了縮短停機(jī)窗口，使用ogg進(jìn)行邏輯復(fù)制。那時(shí)候的OGG也是比較垃圾的，功能、性能都存在一定的問題，BUG也比較多。切換當(dāng)晚發(fā)現(xiàn)有幾張表總是追不上，最后決定直接通過dblink CTAS重建的方式遷移了。最后還好，在規(guī)定的時(shí)間窗口內(nèi)完成了數(shù)據(jù)庫的遷移和數(shù)據(jù)校驗(yàn)工作。使用OGG做遷移，數(shù)據(jù)校驗(yàn)的工作量十分大，如果是十分核心的系統(tǒng)，對(duì)數(shù)據(jù)一致性和完整性要求較高，一定要留足時(shí)間做數(shù)據(jù)校驗(yàn)。

邏輯導(dǎo)出導(dǎo)入一直是被認(rèn)為最為安全的遷移方式，不過天底下沒有絕對(duì)安全的遷移方案。大概6/7年前，一個(gè)銀行把核心系統(tǒng)從HDS存儲(chǔ)遷移到華為18K上的時(shí)候，想把數(shù)據(jù)庫也順便從10g升級(jí)到11g，因?yàn)楹诵膽?yīng)用也要做升級(jí)，因此申請(qǐng)了36小時(shí)的業(yè)務(wù)停機(jī)窗口，其中核心系統(tǒng)完全停止業(yè)務(wù)18小時(shí)，這18小時(shí)中，給了數(shù)據(jù)庫遷移8個(gè)小時(shí)的時(shí)間。通過綜合考慮，他們決定采用最為穩(wěn)妥的數(shù)據(jù)庫邏輯導(dǎo)出導(dǎo)入的方式。

首先在老存儲(chǔ)上導(dǎo)出數(shù)據(jù)，然后把整個(gè)卷掛載到新的服務(wù)器上，再做導(dǎo)入。按理說夠安全了吧，沒想到主機(jī)工程師掛載這塊盤的時(shí)候沒注意給掛載成只讀的了。DBA也沒檢查就開始導(dǎo)入了，幾個(gè)小時(shí)后報(bào)無法寫入磁盤數(shù)據(jù)，impdp異常退出了。這時(shí)候8小時(shí)的時(shí)間窗口已經(jīng)使用了5個(gè)多小時(shí)了，如果重新導(dǎo)入一次，時(shí)間上肯定是不夠的。當(dāng)時(shí)我正好在現(xiàn)場(chǎng)，通過檢查發(fā)現(xiàn)是impdp輸出日志的時(shí)候無法寫盤導(dǎo)致了錯(cuò)誤，而剛開始的時(shí)候?qū)懭肴罩镜臅r(shí)候是寫在緩沖里并沒有刷盤，所以沒有報(bào)錯(cuò)，等刷盤的時(shí)候就報(bào)錯(cuò)了。通過校驗(yàn)數(shù)據(jù)表和索引發(fā)現(xiàn)所有的索引都已經(jīng)完成創(chuàng)建了。因此報(bào)錯(cuò)時(shí)可能已經(jīng)完成了主要的數(shù)據(jù)導(dǎo)入過程。最后經(jīng)過會(huì)商決定暫時(shí)不回退整個(gè)工作，繼續(xù)進(jìn)行后續(xù)工作。

不過因?yàn)檫@個(gè)插曲，原本計(jì)劃的對(duì)所有表和索引做一次重新統(tǒng)計(jì)（通過SPA分析后發(fā)現(xiàn)11g對(duì)統(tǒng)計(jì)數(shù)據(jù)的依賴性更強(qiáng)，因此建議最后做一次表分析）就沒有進(jìn)行了。核心系統(tǒng)啟動(dòng)順利完成，主要功能測(cè)試也順利完成，大家揪著的心才放了下來。不過前臺(tái)很快傳來更壞的消息，應(yīng)用開發(fā)商在測(cè)試性能的時(shí)候，認(rèn)為主要核心交易的延時(shí)都慢了幾十毫秒，平均核心交易延時(shí)從升級(jí)前的80毫秒提高到120毫秒以上，因此拒絕新系統(tǒng)上線。大家折騰了這么長(zhǎng)時(shí)間還要回退，這對(duì)IT部門的打擊十分嚴(yán)重的。因此CIO希望我們能夠盡快找到問題，解決問題。

通過分析存儲(chǔ)的性能，數(shù)據(jù)庫的總體性能沒有發(fā)現(xiàn)什么問題。時(shí)間已經(jīng)接近8小時(shí)的窗口了，按道理現(xiàn)在必須做回退了。我當(dāng)時(shí)和CIO說，能不能再給我20分鐘我再分析一下，如果找不到原因再回退。當(dāng)時(shí)CIO說，我給你40分鐘，如果不行只能我去向行長(zhǎng)請(qǐng)罪了。最后在差不多半小時(shí)后，我終于定位了引起一部分核心交易延時(shí)增加的主要原因是幾張表的統(tǒng)計(jì)數(shù)據(jù)過舊，更新了統(tǒng)計(jì)數(shù)據(jù)后，核心交易延時(shí)恢復(fù)到90毫秒左右，低于開發(fā)商要求的不高于120毫秒的要求。從這個(gè)案例上看，最簡(jiǎn)單靠譜的遷移方案，也不是萬全的。

三、ASM磁盤組加盤/刪盤

ASM磁盤組上加入新存儲(chǔ)的磁盤，然后逐步刪除老存儲(chǔ)的磁盤，利用ASM的REBALANCE功能實(shí)現(xiàn)存儲(chǔ)遷移也是一種挺不錯(cuò)的方案，只是REBALANCE時(shí)間比較長(zhǎng)（如果數(shù)據(jù)量較大，業(yè)務(wù)負(fù)載較大），需要DBA隨時(shí)關(guān)注整個(gè)進(jìn)程，如果系統(tǒng)負(fù)載較高，IO吞吐量較大，那么在此期間可能會(huì)引起一些IO方面的性能問題。嚴(yán)重時(shí)可能導(dǎo)致應(yīng)用系統(tǒng)總體性能嚴(yán)重下降，而一旦這些問題發(fā)生，我們只能暫時(shí)降低REBALANCE的優(yōu)先級(jí)，緩解問題，無法徹底解決問題。因此對(duì)于特別核心的系統(tǒng)使用這種方式還是要十分注意。我把這個(gè)方法教給一家銀行后，他們就喜歡上了這種遷移方式，并用這種方式遷移了大量的系統(tǒng)，總體上來說還是比較平穩(wěn)的。不過在核心交易系統(tǒng)上，他們還是沒敢使用。

數(shù)據(jù)庫遷移的方法有很多，今天時(shí)間的關(guān)系我就不一一舉例了。不過無論采用何種方式，都需要實(shí)施者不要掉以輕心，對(duì)每個(gè)環(huán)節(jié)都做最精心的準(zhǔn)備。不過有一定可以提醒大家的是，跳出DBA的思維方式，可能會(huì)找到更好的方法。?