企業(yè)傳統(tǒng)Oracle數(shù)據(jù)庫遷移到國產(chǎn)數(shù)據(jù)庫核心難點(diǎn)總結(jié)

企業(yè)傳統(tǒng)Oracle數(shù)據(jù)庫遷移到國產(chǎn)數(shù)據(jù)庫核心難點(diǎn)總結(jié)背景近幾年國產(chǎn)數(shù)據(jù)庫以其高并發(fā)、海量數(shù)據(jù)、易擴(kuò)展、高可用、易運(yùn)維（一體化自動運(yùn)維平臺）等技術(shù)優(yōu)勢，以及其部署在普通硬件服務(wù)器之上的成本優(yōu)勢，在國內(nèi)各個行業(yè)取得了廣泛應(yīng)用，成熟度也越來越高，關(guān)注程度也越來越高，在金融行業(yè)尤其是銀行業(yè)數(shù)據(jù)庫國產(chǎn)化替換的趨勢越來越明顯：在銀行業(yè)數(shù)字化轉(zhuǎn)型和高質(zhì)量發(fā)展過程中，IT系統(tǒng)的飛速發(fā)展，而傳統(tǒng)以O(shè)racle為代表的集中式IT架構(gòu)己經(jīng)無法滿足需求，像云平臺、大數(shù)據(jù)、AI、微服務(wù)、分布式架構(gòu)、敏捷前臺、統(tǒng)一中臺等技術(shù)架構(gòu)的發(fā)展很好的契合了銀行未來業(yè)務(wù)發(fā)展的需求，而國產(chǎn)數(shù)據(jù)庫作為其中重要環(huán)節(jié)貫穿了整個前中后端，重要程度不言而喻，是未來銀行IT架構(gòu)轉(zhuǎn)型發(fā)展的重要趨勢；此外，金融行業(yè)國產(chǎn)化進(jìn)一步推進(jìn)并逐步進(jìn)入深水區(qū)，數(shù)據(jù)庫國產(chǎn)化是其中一項(xiàng)重要內(nèi)容，數(shù)據(jù)庫從傳統(tǒng)Oracle遷移到國產(chǎn)數(shù)據(jù)庫勢在必行。本文重點(diǎn)圍繞企業(yè)在去0實(shí)踐過程中遇到的難題進(jìn)行交流探討總結(jié)：1、由Oracle數(shù)據(jù)庫遷移到分布式數(shù)據(jù)庫之后，關(guān)聯(lián)查詢的語句怎么解決？【問題描述】由Oracle數(shù)據(jù)庫遷移到分布式數(shù)據(jù)庫之后，除了讓盡量把需要關(guān)聯(lián)的表按照相同的規(guī)則分布在一個節(jié)點(diǎn)外，現(xiàn)在系統(tǒng)的數(shù)據(jù)量都是5T以上的，不同的表已經(jīng)按照不同的規(guī)則進(jìn)行了分區(qū)，這些表之間的關(guān)聯(lián)查詢是應(yīng)用必須要的而且頻率很高，如果需要把所有的表按照統(tǒng)一規(guī)則去設(shè)置分布字段讓同一用戶下的資料都相同的節(jié)點(diǎn)上，這樣的話改造就非常大，萬一要回退也會非常麻煩，請問一下專家，這個問題還有沒有其他好辦法來解決復(fù)雜的關(guān)聯(lián)查詢的問題，又不會導(dǎo)致應(yīng)用改造過大？@hanfeng_twtSphcrcEx數(shù)據(jù)庫架構(gòu)師:解決上述問題有幾個思路：.產(chǎn)品層面完成后，再進(jìn)行國產(chǎn)化改造就很方便了。甚至可以分階段先改造讀交易至國產(chǎn)數(shù)據(jù)庫，再改造寫交易至國產(chǎn)數(shù)據(jù)庫。最后：如果一個系統(tǒng)在Oracle上運(yùn)行就有比較多的問題，不要試圖通過改造成國產(chǎn)數(shù)據(jù)庫來解決改問題，可能會把問題放大。9、Oracle到國產(chǎn)數(shù)據(jù)庫遷移后數(shù)據(jù)如何作對比，比如大字段等？【問題描述】數(shù)據(jù)遷移后需要進(jìn)行源庫和目標(biāo)庫的數(shù)據(jù)比對，以確保數(shù)據(jù)遷移準(zhǔn)確性，但是由于是數(shù)據(jù)庫異構(gòu)，字段類型會發(fā)生變化，數(shù)據(jù)比對往往沒有那么容易，記錄數(shù)比對相對來說比較容易實(shí)現(xiàn)，但是字段級別的比對難度和效率很難達(dá)到平衡，例如大字段類型等，所以遷移后數(shù)據(jù)比對如何實(shí)現(xiàn)，確保數(shù)據(jù)庫一條一個字段都不能有問題？@yata52中國人壽財險數(shù)據(jù)庫管理員：.目前國產(chǎn)的數(shù)據(jù)同步工具已經(jīng)在逐步適配國產(chǎn)數(shù)據(jù)庫，可以依托這些工具自帶的對比工具。.在沒有外部工具的情況下如何平衡效率和全面性，可以考慮上線前的測試階段對數(shù)據(jù)進(jìn)行全面校驗(yàn)，在正式遷移停機(jī)窗口內(nèi)效率優(yōu)先（目前國產(chǎn)數(shù)據(jù)庫廠商已有對比腳本，僅對比對象數(shù)量、狀態(tài)、條數(shù)、主鍵）。.測試階段可以要求開發(fā)團(tuán)隊(duì)或者業(yè)務(wù)團(tuán)隊(duì)聯(lián)合驗(yàn)證，一些由于遷移引起的大字段丟失、亂碼、精度錯誤等問題暴露的會比較快，排查起來更高效。@lulihuanl987張家港行數(shù)據(jù)庫管理員：一方面可以依靠數(shù)據(jù)庫廠商提供的同步平臺，但是目前大字段的比對沒有太好的辦法，可以試著增加字段求該行md5值的方法試試。10、0racle遷移至國產(chǎn)數(shù)據(jù)庫后，如何保證數(shù)據(jù)的完全一致性？并行期間，如何將數(shù)據(jù)回寫Oracle?@lulihuanl987張家港行數(shù)據(jù)庫管理員：Oracle遷移到國產(chǎn)數(shù)據(jù)庫后，如果Oracle想要作為備份繼續(xù)使用，那么雙寫和數(shù)據(jù)同步都是可以的，具體的方案也需要結(jié)合業(yè)務(wù)系統(tǒng)去做。兩個數(shù)據(jù)庫間數(shù)據(jù)的完全一致性需要靠同步工具或者編寫腳本去檢驗(yàn)，一般以同步工具為主，腳本為輔。@yata52中國人壽財險數(shù)據(jù)庫管理員：具體哪種方式需要看應(yīng)用支持雙寫的難度。說一個我們碰到的應(yīng)用雙寫難點(diǎn)，部分流水號是通過序列生成的。為了加速序列的使用Oracle和國產(chǎn)庫都加了cache,如果是簡單的通過nginx將業(yè)務(wù)流量鏡像，兩邊取到的序列值就難于保障是一致的。創(chuàng)建訂單的流程都能完成，只是生成的流水號不一樣，但是對于根據(jù)流水號修改的業(yè)務(wù)，流量復(fù)制到備端就會異常。11、遷移至國產(chǎn)分布式數(shù)據(jù)庫后分表實(shí)踐方案？【問題描述】各位老師，遷移至國產(chǎn)分布式數(shù)據(jù)庫后的分庫分表方案，一直困擾著我。也查閱了很多相關(guān)資料，但是還是感覺沒有一個滿意的可落地方案。因此提出幾個具體問題，希望各位老師能夠解答，也希望各位同業(yè)一起交流。.盡量保證單庫查詢的原則是指的一個交易事務(wù)范圍內(nèi)，還是單個sql范圍內(nèi)呢？.一筆記賬交易涉及多類表：如賬戶表，參數(shù)表，憑證表，流水表，機(jī)構(gòu)表等。如何合理劃分分片鍵呢，保證盡量單庫處理。能否有具體的案例參考？.如何衡量分庫分表策略合理呢？是否有類似單庫sql占比，兩分片sql占比等類似的指標(biāo)進(jìn)行衡量呢？.是否可以提供某個具體案例，交易描述，分片策略等，幫助我們進(jìn)行參考？@huhu097云南紅塔銀行DBA：先考慮表的性質(zhì)，是在線交易型（存放在線交易數(shù)據(jù)），還是分析型（歷史數(shù)據(jù)歸檔和交易日志等），在線交易型的表分區(qū)優(yōu)先考慮事務(wù)處理邏輯，避免分布式事務(wù)，考慮和其他表關(guān)聯(lián)的情況，來確定分區(qū)鍵以及分區(qū)的方式，索引的創(chuàng)建和使用需要考慮表分區(qū)鍵，在線交易系統(tǒng)單筆交易涉及sql數(shù)量一般都比較多，單個事務(wù)內(nèi)包含多條sql,建議分析交易處理邏輯以及sql涉及的表結(jié)構(gòu)，再做分區(qū)。分析型的表優(yōu)先考慮歷史數(shù)據(jù)歸檔以及清理的問題，另外還有歷史數(shù)據(jù)查詢的效率問題，OccanBasc現(xiàn)有的表組，支持全局唯一性索引（可以不帶分區(qū)鍵），廣播表，對分表非常的友好。@lulihuan1987張家港行數(shù)據(jù)庫管理員：通常單sql查詢索引合理的情況下不會有問題，這里的單sql指的是單表的sql,如果帶上分片字段的話是最優(yōu)解，只操作單節(jié)點(diǎn)。單sql的更新，update和delete需要帶上分片字段，否則存在跨節(jié)點(diǎn)更新，會有效率問題，對于不支持全局一致性的數(shù)據(jù)庫來說，可能還有一致性問題。insert時涉及跨節(jié)點(diǎn)更新時也要注意。兩個以上表操作sql設(shè)計是難點(diǎn)，總得原則就是避免跨節(jié)點(diǎn)數(shù)據(jù)流動，能拆就拆，不能拆的關(guān)鍵字段必須是分片字段。?hanfengtwtSphereEx數(shù)據(jù)庫架構(gòu)師：.所謂單庫查詢，是指語句查詢可以精確到某個分片中，這樣的效率最高。從事務(wù)處理角度來看，能否限制在某個分片內(nèi)（即本地事務(wù)），也是效率最高的。.具體的分片策略沒有一定之規(guī)，一方面可選擇業(yè)務(wù)的共性部分作為分片鍵，一方面數(shù)據(jù)量不大又參與到業(yè)務(wù)中的，也可考慮全局表（或廣播表）的方式。.無法完全杜絕分庫分表，只能盡量減少。具體比例取決于業(yè)務(wù)及分片策略。4.可參考北京金融聯(lián)盟最新發(fā)布的單元化策略指南。有些分布式數(shù)據(jù)庫產(chǎn)品，提供“自動分布式”能力，即可以實(shí)現(xiàn)數(shù)據(jù)自主分片，不再需要人為干預(yù)。這樣在結(jié)構(gòu)設(shè)計無需做太多修改。針對語句方面，也可以免改造或低改造完成遷移。當(dāng)然這種方式還是要看業(yè)務(wù)復(fù)雜度，很難做到完全規(guī)避因引入分布式帶來的改造成本。且針對復(fù)雜查詢情況下，目標(biāo)數(shù)據(jù)庫是否能很好處理且保證性能也是需關(guān)注的。.設(shè)計層面在設(shè)計方面，提前做好相應(yīng)的改造評估工作。如對現(xiàn)有結(jié)構(gòu)、語句通過工具掃描方式，獲得當(dāng)前的工作負(fù)載，針對分布式情況下做改造評估等。這種方式不會減少改造工作量，但會提前規(guī)劃避免被動。這種也是我比較推薦的方式。.架構(gòu)層面針對復(fù)雜的Oracle查詢，有些場景可考慮下移到大數(shù)據(jù)技術(shù)棧解決。后者針對復(fù)雜關(guān)聯(lián)查詢，會更為適合。但兩者需解決數(shù)據(jù)同步問題且業(yè)務(wù)是否接受一定延遲，也需關(guān)注。2、如果數(shù)據(jù)庫較大，全量遷移時間較長，如何盡可能縮短停機(jī)窗口？【問題描述】對于數(shù)據(jù)庫容量較大的庫，從Oracle遷移到國產(chǎn)數(shù)據(jù)庫，全量遷移需要較長時間，而對于金融機(jī)構(gòu)來說，停機(jī)窗口非常寶貴，如何可以縮短停機(jī)窗口是實(shí)施的難點(diǎn)之一，如果是同構(gòu)數(shù)據(jù)庫的遷移，比如Oracle遷移到Oracle,有比較成熟的工具實(shí)現(xiàn)全量和增量的遷移，前期先進(jìn)行全量遷移，停機(jī)窗口時再進(jìn)行增量遷移，可以盡可能縮短停機(jī)時間，但是Oracle到國產(chǎn)數(shù)據(jù)庫，如何進(jìn)行類似的全量和增量遷移，需要重點(diǎn)考慮？@hanfeng_twtSphereEx數(shù)據(jù)庫架構(gòu)師:總結(jié)來說，是異構(gòu)數(shù)據(jù)庫間遷移的問題.提供常規(guī)的全量及增量數(shù)據(jù)遷移能力，這對于有效縮短時間窗口有益。目前已有很多廠商提供此類能力。但需要注意的是，從集中式架構(gòu)到分布式架構(gòu)還可以；反之仍有一定局限。.提供全量及增量數(shù)據(jù)對比能力，滿足對數(shù)據(jù)一致性的檢驗(yàn)?zāi)芰?，這對于實(shí)施切換是重要參考依據(jù)。此外包括差異數(shù)據(jù)的正向、反向的補(bǔ)償能力，也是需要的。.由業(yè)務(wù)邏輯方面提供一定的兼容能力，可滿足短時間系統(tǒng)間遷移的數(shù)據(jù)補(bǔ)償能力，有助于縮短窗口。.架構(gòu)設(shè)計方面，提供多種數(shù)據(jù)同步考慮，除了數(shù)據(jù)庫外，還可以考慮如應(yīng)用報文、網(wǎng)絡(luò)協(xié)議等方面的同步機(jī)制，作為有益的補(bǔ)充。@huawei851120江蘇省農(nóng)村信用社聯(lián)合社數(shù)據(jù)庫運(yùn)維工程師：有兩種思路：.先對Oracle的大表進(jìn)行改造，分為歷史表和當(dāng)前表。把歷史表先期遷移到國產(chǎn)數(shù)據(jù)庫，停機(jī)窗口內(nèi)再把當(dāng)前用的表遷移過去。這種用法比較推薦；2.利用同步工具。幾家大廠的國產(chǎn)數(shù)據(jù)庫，都有自己的數(shù)據(jù)同步工具，可以先期進(jìn)行數(shù)據(jù)同步，但不能同步DDL。這個階段不要進(jìn)行Oracle表結(jié)構(gòu)的表更。投產(chǎn)窗口內(nèi)，把應(yīng)用停掉后，等數(shù)據(jù)追平就可以了。@劉煒鋅城銀清算服務(wù)有限責(zé)任公司應(yīng)用維護(hù)：.截止到一個時間點(diǎn)可以提前遷移歷史數(shù)據(jù)，比如窗口前一周或者提前1、2天；.到了停機(jī)窗口，業(yè)務(wù)停運(yùn)后補(bǔ)增量數(shù)據(jù)；.做好全量數(shù)據(jù)的檢查，補(bǔ)完增量后，新老庫數(shù)據(jù)量對比，做最終確認(rèn)，這樣就能大大減少數(shù)據(jù)遷移時間。@yata52中國人壽財險數(shù)據(jù)庫管理員：目前我們接觸的國產(chǎn)數(shù)據(jù)庫廠商都有了適合自己的全量初始化加增量同步方案，有的是利用自有工具，有的是利用常見數(shù)據(jù)遷移軟件，都能做到在切換前數(shù)據(jù)實(shí)時同步幾乎無延遲。但是總結(jié)下來，遷移的過程還需要重點(diǎn)考慮這幾個問題：.如果源庫較大，為了保障全量初始化成功，需要考慮適當(dāng)調(diào)大undo表空間，為了保障遷移時對生產(chǎn)影響較小，盡量使用物理備庫抽取，全量遷移時合理分組初始化。如果是單表過大又沒有物理備庫的情況，可以考慮使用更高效的工具（數(shù)據(jù)泵等）將單表遷移至Oracle中轉(zhuǎn)庫（不承載業(yè)務(wù)）再慢慢導(dǎo)入到國產(chǎn)數(shù)據(jù)庫。.如果遷移過程中使用了kettle,ogg、平面文件多種技術(shù)組合實(shí)現(xiàn)，上線前一定要對數(shù)據(jù)做驗(yàn)證，防止出現(xiàn)中文亂碼。.各家都實(shí)現(xiàn)了實(shí)時增量同步，目前切換過程中占用停機(jī)時間的主要是這兩個步驟，一是數(shù)據(jù)靜態(tài)后的數(shù)據(jù)檢驗(yàn)時間，二是反向同步啟動前的配置和檢查工作。3、國產(chǎn)數(shù)據(jù)庫分集中式和分布式，Oracle遷移至集中式還是分布式場景？【問題描述】國產(chǎn)數(shù)據(jù)庫有提供集中式模式和分布式模式兩種，集中式省去了數(shù)據(jù)分布方面的難點(diǎn)，更容易實(shí)現(xiàn)遷移，但是性能、容量和擴(kuò)展性受限，向分布式數(shù)據(jù)庫改造難度相對較大，但性能、容量和擴(kuò)展性優(yōu)勢明顯，因此，如何更加具體業(yè)務(wù)場景選擇合適的數(shù)據(jù)庫？@huawei851120江蘇省農(nóng)村信用社聯(lián)合社數(shù)據(jù)庫運(yùn)維工程師：.首選無論是集中式還是分布式，都盡量采用大廠的產(chǎn)品。因?yàn)閿?shù)據(jù)遷移工作，看似沒什么大不了，一旦出問題后后果很嚴(yán)重。大廠的集中式和分布式產(chǎn)品一般都有數(shù)據(jù)遷移工具，并且在很多客戶那使用過，遷移都會比較方便,但沒有想象的完美。.如果是小庫，遷移至集中式會比較方便，通過工具直接可以遷移。如果是交易量比較大、數(shù)據(jù)量比較大的庫，推薦采用分布式數(shù)據(jù)庫，集中式的性能肯定不如大廠的分布式數(shù)據(jù)庫產(chǎn)品。.如果庫有非常多的存儲過程（幾十個，乃至幾百個），還是采用集中式比較好。分布式數(shù)據(jù)庫，尤其是基于MySQL的對存儲過程兼容性不太好。@yata52中國人壽財險數(shù)據(jù)庫管理員：首先總結(jié)下我司所使用的兩種數(shù)據(jù)庫特點(diǎn)：集中式數(shù)據(jù)庫：體系結(jié)構(gòu)與Oracle類似，語法兼容度高、對服務(wù)器無要求、數(shù)據(jù)遷移成本小、運(yùn)維規(guī)范可基本沿用。單集群性能上限受限于X86服務(wù)器算力，相比小型機(jī)+Oracle的組合仍存在一定差距。分布式數(shù)據(jù)庫：使用分布式協(xié)議和LSM-Tree數(shù)據(jù)結(jié)構(gòu)，需要修改為Mysql語法、對服務(wù)器性能要求較高、數(shù)據(jù)遷移成本較高、運(yùn)維規(guī)范需重新建立。單集群庫性能可通過擴(kuò)充服務(wù)器進(jìn)行擴(kuò)展，算力可突破小型機(jī)+Oracle的組入口O針對以上兩種特點(diǎn)，我們的替換場景如下：.切換前使用虛擬機(jī)運(yùn)行數(shù)據(jù)庫的中低負(fù)載系統(tǒng)，替換為集中式數(shù)據(jù)庫。.切換前使用小型機(jī)或者多臺物理機(jī)運(yùn)行數(shù)據(jù)庫的中高負(fù)載系統(tǒng)，替換為分布式數(shù)據(jù)庫。@lulihuanl987張家港行數(shù)據(jù)庫管理員：國產(chǎn)數(shù)據(jù)庫集中式模式遷移難度較小，適配容易，特別是一些特殊數(shù)據(jù)庫對象也可以支持，比如函數(shù)和存儲過程，對于性能，容量和擴(kuò)展性要求不高，單臺數(shù)據(jù)庫服務(wù)器足以支撐的業(yè)務(wù)場景，可以采用。而分布式模式對于數(shù)據(jù)庫比較大，高并發(fā)，需要根據(jù)業(yè)務(wù)需求可以擴(kuò)展的業(yè)務(wù)場景，單臺服務(wù)器無法支撐的場景。無論是集中式還是分布式模式，均支持跨機(jī)房級容災(zāi)和節(jié)點(diǎn)高可用等特性。@hanfeng_twtSphercEx數(shù)據(jù)庫架構(gòu)師：從Oracle遷移到國產(chǎn)數(shù)據(jù)庫的選擇路線：.遷移目的：首選需要關(guān)注的是遷移目的，是為了解決性能、承載量，還是為了滿足自主可控。針對前者的話，考慮分布式架構(gòu)更多；后者，則更傾向于考慮國產(chǎn)集中式架構(gòu)產(chǎn)品。.應(yīng)用適配：次之要考慮應(yīng)用適配問題。如果應(yīng)用對Oracle有較深度的依賴，則需優(yōu)先考慮兼容度好的產(chǎn)品，相對而言集中式架構(gòu)產(chǎn)品在這方面有些優(yōu)勢；反之，則可不將此因素作為選擇要素之一。此外，針對分布式架構(gòu)，需要考慮如數(shù)據(jù)分片等問題，也需一并考慮。某些系統(tǒng)依賴外部廠商開發(fā)，出于盡量減少開發(fā)量的初衷，集中式架構(gòu)更有優(yōu)勢。.運(yùn)維適配：現(xiàn)有運(yùn)維體系是否對分布式架構(gòu)有一定經(jīng)驗(yàn)或者己具備相關(guān)人員儲備，這對于選擇這一架構(gòu)很重要。這其中包括從基礎(chǔ)設(shè)施、備份恢復(fù)、故障處理、性能調(diào)優(yōu)等多方面。.'業(yè)務(wù)連續(xù)性：相對集中式架構(gòu)而言，分布式在整體穩(wěn)定性等方面還需驗(yàn)證。因此在選擇之初，要將整體可用性作為考慮要素之一，是否有專項(xiàng)預(yù)案解決需考慮。4、正式替換原有數(shù)據(jù)庫后，如何保證國產(chǎn)數(shù)據(jù)庫寫庫的準(zhǔn)確性？是否有異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)稽核？【問題描述】在雙軌運(yùn)行過程中，如何保證國產(chǎn)數(shù)據(jù)庫寫庫的準(zhǔn)確性？我們之前測試的時候發(fā)現(xiàn)有些國產(chǎn)數(shù)據(jù)庫保存的精度與Oracle不一致。是否有異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)強(qiáng)一致性的稽核？@huawei851120江蘇省農(nóng)村信用社聯(lián)合社數(shù)據(jù)庫運(yùn)維工程師：據(jù)我了解，應(yīng)該是沒有的。木人也是希望有，這樣可以防止國產(chǎn)數(shù)據(jù)庫出現(xiàn)天大的問題（數(shù)據(jù)不一致）的時候，我們客戶能及早的發(fā)現(xiàn)，不至于釀成大錯。可是目前國內(nèi)應(yīng)該沒有這樣的異構(gòu)數(shù)據(jù)庫之間的數(shù)據(jù)稽核。小廠商都是基于MySQL和PG開發(fā)的，不值得大廠去開發(fā)工具稽核它們。大廠的數(shù)據(jù)庫核心技術(shù)都是保密的，不會給別的大廠去稽核。@我是個小胖子國泰君安：根據(jù)我們前面的應(yīng)用經(jīng)驗(yàn)，這種稽核一般是有兩種方式。一是由數(shù)據(jù)庫廠商提供相關(guān)的工具，來核對兩個庫的數(shù)據(jù)一致性，比如兩邊分別導(dǎo)出csv文件（排除自增id,時間戳等字段），然后進(jìn)行比對，也可以以oracle數(shù)據(jù)庫基準(zhǔn)，用唯一鍵定位國產(chǎn)庫的行數(shù)據(jù)，然后進(jìn)行比對。二是由業(yè)務(wù)每日導(dǎo)出當(dāng)日的增量數(shù)據(jù)，然后由業(yè)務(wù)方自行比對。5、風(fēng)險控制方面考慮，例如白名單灰度遷移，回退方案等？【問題描述】遷移過程中風(fēng)險必須是可控的，由于是對于重要在線業(yè)務(wù)系統(tǒng),一方面要確保業(yè)務(wù)系統(tǒng)盡可能短暫的影響，又要確保出現(xiàn)問題能夠快速應(yīng)對或者回退，該問題難點(diǎn)在于涉及數(shù)據(jù)庫的切換，如果只涉及應(yīng)用，那么可以通過灰度發(fā)布實(shí)現(xiàn)，出現(xiàn)問題也可以及時回退，而數(shù)據(jù)庫的遷移是否可以借鑒類似的思路去實(shí)現(xiàn)白名單灰度遷移，出現(xiàn)問題快速回退，整個過程中Oracle和國產(chǎn)數(shù)據(jù)庫之間的數(shù)據(jù)如何處理？@huawei851120江蘇省農(nóng)村信用社聯(lián)合社數(shù)據(jù)庫運(yùn)維工程師：從我們的經(jīng)驗(yàn)看，灰度遷移是個危險的想法，哈哈！真的，容易把數(shù)據(jù)搞臟掉，不建議這樣做。雖然整體數(shù)據(jù)遷移，風(fēng)險高，但是容易保持?jǐn)?shù)據(jù)一致性。一旦失敗后，可以追日志來找到數(shù)據(jù)一致點(diǎn)。至于您擔(dān)心的事情，我個人的意見是：.提前把國產(chǎn)數(shù)據(jù)的環(huán)境搭好，小庫要提前兩周，大庫要提前一個月。.在生產(chǎn)上，切換投產(chǎn)窗口前提前做幾輪的遷移測試。比如9月1日遷移，在8月中旬下旬各做兩輪的遷移，在生產(chǎn)上做的話，注意窗口，以防對現(xiàn)有系統(tǒng)造成影響?？梢赃x擇深夜交易低谷進(jìn)行。.每輪遷移完成后，對數(shù)據(jù)進(jìn)行校驗(yàn)和比對。@yata52中國人壽財險數(shù)據(jù)庫管理員：目前我們接觸到的國產(chǎn)數(shù)據(jù)庫廠商暫時還做不到同時雙向同步，即同一個表內(nèi)的數(shù)據(jù)Oracle的變更向國產(chǎn)寫，同時國產(chǎn)的變更向Oracle寫。但是目前都實(shí)現(xiàn)了單向同步，Oracle的變更向國產(chǎn)寫沒問題，切換之后國產(chǎn)的變更向Oracle回寫也沒有問題。針對快速回切，實(shí)踐中我們會用這兩種方式：.針對核心系統(tǒng)，切換后開啟反向?qū)崟r同步。上線前準(zhǔn)備好回切方案，數(shù)據(jù)庫部分主要是涉及序列的變更和數(shù)據(jù)校驗(yàn)?zāi)_本。數(shù)據(jù)庫切換之后立刻開啟反向回退，保障國產(chǎn)數(shù)據(jù)庫內(nèi)的變更可以準(zhǔn)實(shí)時的寫回原Oracle數(shù)據(jù)庫。由于中間件切換異構(gòu)數(shù)據(jù)庫的數(shù)據(jù)源需要重啟，所以切換后老應(yīng)用的中間件數(shù)據(jù)源不調(diào)整，僅從F5中摘掉，需要回切時候完成數(shù)據(jù)庫切換動作后直接把老應(yīng)用掛回F5。.針對可自行稽核并補(bǔ)錄數(shù)據(jù)的系統(tǒng)，我們是直接在新環(huán)境搭建新庫并按照業(yè)務(wù)團(tuán)隊(duì)的要求導(dǎo)入某一時間的數(shù)據(jù)，業(yè)務(wù)切換后數(shù)據(jù)庫層不提供數(shù)據(jù)實(shí)時同步服務(wù)，直接將Oracle數(shù)據(jù)庫的表空間設(shè)為只讀避免流量沒有切干凈。6、數(shù)據(jù)庫很大，遷移窗口又相對有限的數(shù)據(jù)庫遷移應(yīng)該怎么實(shí)現(xiàn)？每個數(shù)據(jù)庫用戶基本都在3T級別。@huawei851120江蘇省農(nóng)村信用社聯(lián)合社數(shù)據(jù)庫運(yùn)維工程師：這種大庫是很難辦的。常用的方法：（1）花力氣對原Oracle庫進(jìn)行改造，把表分為歷史表和當(dāng)前表。比如3個月前的數(shù)據(jù)放1個表或幾十張表里，當(dāng)前交易進(jìn)行增刪改查的作為一個表，給當(dāng)前交易用；（2）先對歷史表進(jìn)行數(shù)據(jù)遷移；（3）投產(chǎn)窗口對當(dāng)前表進(jìn)行遷移，可能3T里面只有300G~800G左右，這樣才能控制投產(chǎn)的是遷移窗口時長。@yata52中國人壽財險數(shù)據(jù)庫管理員：可以考慮采用全量+增量的方法進(jìn)行數(shù)據(jù)同步，停機(jī)窗口前將增量延時控制在分鐘級別。達(dá)夢：自有工具HS。Oceanbase：自有工具OMS。TiDB：外部工具Goldengate。7、從Oracle遷移到信創(chuàng)數(shù)據(jù)庫后的應(yīng)急預(yù)案？【問題描述】對于一些大企業(yè)的數(shù)據(jù)庫從傳統(tǒng)的Oracle遷移到信創(chuàng)。很多時候會存在一種顧慮。就是長久的性能和可靠性，比如在遷移到了信創(chuàng)數(shù)據(jù)庫，在短時間內(nèi)的性能指標(biāo)和功能都滿足了需求。但有些業(yè)務(wù)可能是周期性的。有些問題也可能是累積后出現(xiàn)的。這種情況可能會導(dǎo)致割接一段時間后數(shù)據(jù)庫出現(xiàn)問題。對于這樣的顧慮和可能發(fā)生的風(fēng)險。有那些應(yīng)急預(yù)案呢？@lulihuan1987張家港行數(shù)據(jù)庫管理員：上線是需要制定應(yīng)急預(yù)案，出現(xiàn)問題要把數(shù)據(jù)倒刷回去緊急回退，對于已經(jīng)上線并運(yùn)行一段時間出現(xiàn)問題想回退，需要滿足兩個條件。第一應(yīng)用支持兩種不同數(shù)據(jù)庫，支持Oracle和國產(chǎn)數(shù)據(jù)庫，并且應(yīng)用兩套代碼都支持同步開發(fā)，可以更改配置數(shù)據(jù)源后能切換數(shù)據(jù)庫。第二，兩個數(shù)據(jù)庫間數(shù)據(jù)準(zhǔn)實(shí)時同步。@pysx0503：理論上是這樣?？墒怯行├蠘I(yè)務(wù)因?yàn)槟甏眠h(yuǎn)，缺少技術(shù)支撐，信創(chuàng)更新是基于業(yè)務(wù)的全新開