建站
咨詢
售后
建站咨詢
新聞中心
?數(shù)據(jù)庫遷移是DBA經(jīng)常會面臨的工作，這二十多年來，我們也做過很多數(shù)據(jù)庫遷移的工作。早期的時候，作為一個DBA，考慮遷移方案的時候總是從數(shù)據(jù)庫的角度去考慮。隨著項目做多了，知識范圍不斷地擴大，加入了很多系統(tǒng)級的遷移方案，使遷移工作變得更加簡單了。遷移工作做多了，也難免會遇到鬼，在這二十多年，上百個遷移項目中，也確實遇到過不少坑，有時候甚至面對命懸一線的絕境。
為企業(yè)提供成都網(wǎng)站制作、網(wǎng)站設(shè)計、外貿(mào)網(wǎng)站建設(shè)、網(wǎng)站優(yōu)化、全網(wǎng)整合營銷推廣、競價托管、品牌運營等營銷獲客服務(wù)。創(chuàng)新互聯(lián)擁有網(wǎng)絡(luò)營銷運營團隊，以豐富的互聯(lián)網(wǎng)營銷經(jīng)驗助力企業(yè)精準獲客，真正落地解決中小企業(yè)營銷獲客難題，做到“讓獲客更簡單”。自創(chuàng)立至今，成功用技術(shù)實力解決了企業(yè)“網(wǎng)站建設(shè)、網(wǎng)絡(luò)品牌塑造、網(wǎng)絡(luò)營銷”三大難題，同時降低了營銷成本，提高了有效客戶轉(zhuǎn)化率，獲得了眾多企業(yè)客戶的高度認可！
?到了后來，面對遷移方案的選擇，如果是十分重要的核心系統(tǒng)，一定要選擇最為穩(wěn)妥的方案，以備不測。昨天微信群里有人在問一個數(shù)據(jù)庫想遷移存儲，有沒有什么好方案，從我腦子里冒出來的都是系統(tǒng)層面的遷移方案，而群里的DBA朋友往往都說的是數(shù)據(jù)庫層面的遷移技術(shù)。實際上沒有最好的技術(shù)和方案，只有最合適的。具體選擇哪種數(shù)據(jù)庫遷移方案，最終還是要看具體的系統(tǒng)環(huán)境以及遷移實施隊伍的技術(shù)能力。
一、存儲復制
存儲復制是最近我比較喜歡的一種數(shù)據(jù)庫跨存儲遷移的方法，可以用于很多遷移需求。特別是一個環(huán)境中存在多種數(shù)據(jù)庫/多個數(shù)據(jù)庫的場景，用存儲復制的方式一下子可以搞定所有的數(shù)據(jù)庫，十分便捷。存儲復制的主要實施工作都由存儲廠商完成，對于DBA來說也是最為輕松的，如果出問題，都不需要DBA去甩鍋，肯定是存儲廠商的問題。DBA要做的就是打開數(shù)據(jù)庫，用rman validate校驗一下數(shù)據(jù)文件是否存在物理/邏輯壞塊就可以了。十年前一個金融客戶的核心數(shù)據(jù)庫數(shù)據(jù)庫從9i HA升級為10g RAC,存儲從IBM 8000系列遷移到HDS高端存儲，采用的就是這個方案。使用HDS自帶的異構(gòu)存儲虛擬化能力，首先將數(shù)據(jù)從IBM 8000系列存儲復制到HDS上，最后切換的那一晚上停掉生產(chǎn)數(shù)據(jù)庫，作最后一次增量復制后，用10g RAC的環(huán)境掛在新的卷，然后UPGRADE數(shù)據(jù)庫，整個數(shù)據(jù)庫遷移升級工作一個多小時就完成了。
很多DBA會把卷復制和存儲復制看作一碼事，對于DBA來說，存儲和卷并無不同，反正看到的是一堆裸設(shè)備。實際上二者還是不同的，卷復制采用的是卷管理軟件的數(shù)據(jù)同步功能，比如VERITAS的LVM，卷管理軟件天生就是支持異構(gòu)平臺的，因此使用卷復制技術(shù)同步數(shù)據(jù)有更廣泛的適用性，而存儲復制技術(shù)需要存儲本身的支持（不過現(xiàn)在大多數(shù)高端存儲都支持異構(gòu)存儲的存儲虛擬化，因此大多數(shù)情況下都能支持，如果實在你的環(huán)境中的存儲不支持異構(gòu)復制，也可以考慮租借一臺支持你所需要復制的存儲的虛擬化機頭來做實施，費用在幾千塊錢到幾萬塊錢不等，看你租借的設(shè)備和租借的時間）。
大概十年前吧，一個運營商從HP小機上遷移一個數(shù)據(jù)庫到IBM小機，存儲也從HP存儲更換為EMC存儲，當時他們原來的系統(tǒng)使用了VCS，因此使用VERITAS的卷復制做的數(shù)據(jù)遷移。在IBM端CONVERT數(shù)據(jù)庫的時候（因為HP-UX和AIX都是大端的，所以可以做DATABASE CONVERT，而不需要使用XTTS）遇到了ORACLE 10G的一個BUG， UNDO表空間CONVERT失敗，數(shù)據(jù)庫無法打開，當時也是驚出一身冷汗，最后通過強制OFFLINE相關(guān)UNDO SEGMENT，重新創(chuàng)建UNDO表空間切換等方式解決了這個問題，不過完成遷移的時候已經(jīng)接近早上8點，超出了申請的停機窗口，差點影響了第二天營業(yè)廳開門。所以說，再簡單的遷移方案，都不能保證不出意外。
二、邏輯復制
邏輯復制是一種停機窗口較為緊張時候常用的數(shù)據(jù)庫遷移的方案。兩千零幾年的時候幫助一個運營商把計費/賬務(wù)兩大核心系統(tǒng)從Oracle 8i遷移到Oracle 10g的時候，為了縮短停機窗口，使用ogg進行邏輯復制。那時候的OGG也是比較垃圾的，功能、性能都存在一定的問題，BUG也比較多。切換當晚發(fā)現(xiàn)有幾張表總是追不上，最后決定直接通過dblink CTAS重建的方式遷移了。最后還好，在規(guī)定的時間窗口內(nèi)完成了數(shù)據(jù)庫的遷移和數(shù)據(jù)校驗工作。使用OGG做遷移，數(shù)據(jù)校驗的工作量十分大，如果是十分核心的系統(tǒng)，對數(shù)據(jù)一致性和完整性要求較高，一定要留足時間做數(shù)據(jù)校驗。
邏輯導出導入一直是被認為最為安全的遷移方式，不過天底下沒有絕對安全的遷移方案。大概6/7年前，一個銀行把核心系統(tǒng)從HDS存儲遷移到華為18K上的時候，想把數(shù)據(jù)庫也順便從10g升級到11g，因為核心應(yīng)用也要做升級，因此申請了36小時的業(yè)務(wù)停機窗口，其中核心系統(tǒng)完全停止業(yè)務(wù)18小時，這18小時中，給了數(shù)據(jù)庫遷移8個小時的時間。通過綜合考慮，他們決定采用最為穩(wěn)妥的數(shù)據(jù)庫邏輯導出導入的方式。
首先在老存儲上導出數(shù)據(jù)，然后把整個卷掛載到新的服務(wù)器上，再做導入。按理說夠安全了吧，沒想到主機工程師掛載這塊盤的時候沒注意給掛載成只讀的了。DBA也沒檢查就開始導入了，幾個小時后報無法寫入磁盤數(shù)據(jù)，impdp異常退出了。這時候8小時的時間窗口已經(jīng)使用了5個多小時了，如果重新導入一次，時間上肯定是不夠的。當時我正好在現(xiàn)場，通過檢查發(fā)現(xiàn)是impdp輸出日志的時候無法寫盤導致了錯誤，而剛開始的時候?qū)懭肴罩镜臅r候是寫在緩沖里并沒有刷盤，所以沒有報錯，等刷盤的時候就報錯了。通過校驗數(shù)據(jù)表和索引發(fā)現(xiàn)所有的索引都已經(jīng)完成創(chuàng)建了。因此報錯時可能已經(jīng)完成了主要的數(shù)據(jù)導入過程。最后經(jīng)過會商決定暫時不回退整個工作，繼續(xù)進行后續(xù)工作。
不過因為這個插曲，原本計劃的對所有表和索引做一次重新統(tǒng)計（通過SPA分析后發(fā)現(xiàn)11g對統(tǒng)計數(shù)據(jù)的依賴性更強，因此建議最后做一次表分析）就沒有進行了。核心系統(tǒng)啟動順利完成，主要功能測試也順利完成，大家揪著的心才放了下來。不過前臺很快傳來更壞的消息，應(yīng)用開發(fā)商在測試性能的時候，認為主要核心交易的延時都慢了幾十毫秒，平均核心交易延時從升級前的80毫秒提高到120毫秒以上，因此拒絕新系統(tǒng)上線。大家折騰了這么長時間還要回退，這對IT部門的打擊十分嚴重的。因此CIO希望我們能夠盡快找到問題，解決問題。
通過分析存儲的性能，數(shù)據(jù)庫的總體性能沒有發(fā)現(xiàn)什么問題。時間已經(jīng)接近8小時的窗口了，按道理現(xiàn)在必須做回退了。我當時和CIO說，能不能再給我20分鐘我再分析一下，如果找不到原因再回退。當時CIO說，我給你40分鐘，如果不行只能我去向行長請罪了。最后在差不多半小時后，我終于定位了引起一部分核心交易延時增加的主要原因是幾張表的統(tǒng)計數(shù)據(jù)過舊，更新了統(tǒng)計數(shù)據(jù)后，核心交易延時恢復到90毫秒左右，低于開發(fā)商要求的不高于120毫秒的要求。從這個案例上看，最簡單靠譜的遷移方案，也不是萬全的。
三、ASM磁盤組加盤/刪盤
ASM磁盤組上加入新存儲的磁盤，然后逐步刪除老存儲的磁盤，利用ASM的REBALANCE功能實現(xiàn)存儲遷移也是一種挺不錯的方案，只是REBALANCE時間比較長（如果數(shù)據(jù)量較大，業(yè)務(wù)負載較大），需要DBA隨時關(guān)注整個進程，如果系統(tǒng)負載較高，IO吞吐量較大，那么在此期間可能會引起一些IO方面的性能問題。嚴重時可能導致應(yīng)用系統(tǒng)總體性能嚴重下降，而一旦這些問題發(fā)生，我們只能暫時降低REBALANCE的優(yōu)先級，緩解問題，無法徹底解決問題。因此對于特別核心的系統(tǒng)使用這種方式還是要十分注意。我把這個方法教給一家銀行后，他們就喜歡上了這種遷移方式，并用這種方式遷移了大量的系統(tǒng)，總體上來說還是比較平穩(wěn)的。不過在核心交易系統(tǒng)上，他們還是沒敢使用。
數(shù)據(jù)庫遷移的方法有很多，今天時間的關(guān)系我就不一一舉例了。不過無論采用何種方式，都需要實施者不要掉以輕心，對每個環(huán)節(jié)都做最精心的準備。不過有一定可以提醒大家的是，跳出DBA的思維方式，可能會找到更好的方法。?
網(wǎng)站名稱：總結(jié)出這套數(shù)據(jù)庫遷移經(jīng)驗，我花了20年……
本文鏈接：http://www.dlmjj.cn/article/cdgscsi.html
