Oracle 遷移至 MySQL、PG等分布式數(shù)據(jù)庫(kù)，可能遇到的12個(gè)典型問題
1、不同數(shù)據(jù)庫(kù)之間的異構(gòu)數(shù)據(jù)如何做到無(wú)損遷移？Oracle存量數(shù)據(jù)如何成功遷移至MYSQL、PG等分布式數(shù)據(jù)庫(kù)？
@anonym DBA：
如果是遷移至PG的話，可以采用ora2pg+oracle_fdw，可以保證正確性，效率也還可以?；蛘哂肈SG的同步軟件也能進(jìn)行數(shù)據(jù)的遷移，但是在實(shí)際使用中，用DSG的來(lái)做全庫(kù)的初始化效率稍微有點(diǎn)差
@韓成亮 KE 數(shù)據(jù)庫(kù)管理員：
首先需要確定遷移到數(shù)據(jù)庫(kù)的類型，不同的數(shù)據(jù)庫(kù)內(nèi)部結(jié)構(gòu)都是不一樣的，需要非常熟悉彼此的差別，其次是需要考慮遷移后的維護(hù)問題，高可用的方案，而不是單純的說(shuō) 無(wú)損遷移。
如果真純粹是想無(wú)損遷移，直接二進(jìn)制文件導(dǎo)出導(dǎo)入，保證數(shù)據(jù)不會(huì)丟。010101 這種的，數(shù)據(jù)百分百不會(huì)丟失，無(wú)非是讀取的問題。
如果單純的考慮表的數(shù)據(jù)，那么需要詳細(xì)對(duì)比不同數(shù)據(jù)的字段類型的兼容性。
@standiviny 某保險(xiǎn)：
無(wú)損遷移存量數(shù)據(jù)，首先不同數(shù)據(jù)庫(kù)有不同的數(shù)據(jù)類型和支持的功能，遷移前需要梳理清楚，應(yīng)該就不會(huì)有太大問題
2、Oracle數(shù)據(jù)庫(kù)遷移至MYSQL、PG等分布式數(shù)據(jù)庫(kù)過(guò)程中如何保障系統(tǒng)穩(wěn)定性？如何設(shè)置異構(gòu)數(shù)據(jù)庫(kù)并行過(guò)渡期？
@泊涯 高偉達(dá)公司 系統(tǒng)測(cè)試工程師：
系統(tǒng)運(yùn)營(yíng)的穩(wěn)定性，是不是切換過(guò)去有一定時(shí)間的試運(yùn)行吧，如果客戶允許可以嘗試切割方式，分幾次遷移，兩邊都同步運(yùn)行一小段時(shí)間。
@samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫(kù)管理員：
通過(guò)應(yīng)用雙寫，在應(yīng)用控制一致性，確保異構(gòu)數(shù)據(jù)庫(kù)都能運(yùn)行正常，最后停掉遷移之前的DB。
@standiviny 某保險(xiǎn)：
是否接受義務(wù)中斷？業(yè)務(wù)是否不同的場(chǎng)景方式不同，建議將場(chǎng)景描述清楚一些，會(huì)更容易答復(fù)。
3、將業(yè)務(wù)邏輯實(shí)現(xiàn)方從Oracle數(shù)據(jù)庫(kù)上移至應(yīng)用，那么如何評(píng)估改造量和改造難度？兼容性如何保障？
【問題描述】Oracle數(shù)據(jù)庫(kù)往往和應(yīng)用耦合度較高，遷移過(guò)程還會(huì)涉及到應(yīng)用遷移和改造，特別是存儲(chǔ)過(guò)程、觸發(fā)器、自定義函數(shù)等方面的改造，將業(yè)務(wù)邏輯實(shí)現(xiàn)方從數(shù)據(jù)庫(kù)上移至應(yīng)用，那么如何評(píng)估改造量和改造難度？兼容性如何保障？
@岳彩波 產(chǎn)品經(jīng)理：
不管系統(tǒng)大小，都要遵循以下原則：
一 、應(yīng)用評(píng)估
確定項(xiàng)目的要求
估計(jì)工作量
業(yè)務(wù)需求分析
分析應(yīng)用
計(jì)劃遷移項(xiàng)目
二、應(yīng)用移植
應(yīng)用數(shù)據(jù)遷移
應(yīng)用軟件遷移
應(yīng)用軟件適配新環(huán)境
數(shù)據(jù)庫(kù)從開發(fā)環(huán)境移動(dòng)到生產(chǎn)環(huán)境
應(yīng)用從開發(fā)環(huán)境移動(dòng)到生產(chǎn)環(huán)境
實(shí)施部署策略
三、性能調(diào)優(yōu)
測(cè)試數(shù)據(jù)庫(kù)和應(yīng)用程序遷移
進(jìn)行性能測(cè)試和調(diào)優(yōu)
樓主所說(shuō)的工作量都要經(jīng)過(guò)詳細(xì)的評(píng)估以后才能確定，另外現(xiàn)在有開源的遷移工具和兼容插件，基本上能節(jié)省數(shù)據(jù)和語(yǔ)法遷移的60%時(shí)間，可以試試。
4、數(shù)據(jù)庫(kù)遷移完成后如何成功建轉(zhuǎn)運(yùn)？
【問題描述】數(shù)據(jù)庫(kù)遷移完成后如何成功建轉(zhuǎn)運(yùn)？或者說(shuō)，在數(shù)據(jù)庫(kù)設(shè)計(jì)階段如何設(shè)計(jì)運(yùn)維方案？除了分布式數(shù)據(jù)庫(kù)的高可用、負(fù)載均衡設(shè)計(jì)，傳統(tǒng)運(yùn)維方案中的網(wǎng)絡(luò)、存儲(chǔ)、監(jiān)控告警、備份恢復(fù)等等應(yīng)該如何規(guī)劃？
@ThinkJ 信泰人壽保險(xiǎn)股份有限公司 技術(shù)經(jīng)理：
這是個(gè)很大的問題了，涉及到運(yùn)維的規(guī)范和流程等問題。從我們的經(jīng)驗(yàn)來(lái)看，是盡可能的融入到現(xiàn)有的運(yùn)維體系中，盡量避免大的改造；然后盡早進(jìn)行培訓(xùn)，以使人員盡快適應(yīng)變化。
5、Oracle、DB2 遷移至 MYSQL、PG 的 表的限制、數(shù)據(jù)類型映射關(guān)系，如何處理？
【問題描述】（問題來(lái)自@馮巖 銀行 數(shù)據(jù)庫(kù)管理員） 在 Oracle、DB2 到 MySQL的遷移過(guò)程中，大家主要關(guān)注應(yīng)用層面的兼容問題。但是，數(shù)據(jù)類型的映射轉(zhuǎn)換如何處理呢？
我就拿簡(jiǎn)單的字符串?dāng)?shù)據(jù)類型舉個(gè)例子吧：
Oracle、DB2 與 MySQL，同樣的 utf-8 編碼格式，同樣的表定義，都包含一個(gè) 數(shù)據(jù)類型 char(10) 的字段。
我要將 “一二三四五上山打老虎” 這個(gè)字符串 insert 到這個(gè)字段，猜猜會(huì)發(fā)生什么？
您肯定會(huì)說(shuō) “一二三四五上山打老虎” 占了 30 byte ，肯定報(bào)錯(cuò)的。
但人家 MySQL的 char(10) 就是把這個(gè)含著“老虎”的字符串給“吃”了， 而只有 Oracle、DB2 拋出了類似 “ value is too long ”的錯(cuò)誤。
為什么呢？因?yàn)?Oracle、DB2的 char(10) 最多只能接收10 字節(jié)的字符串長(zhǎng)度，而 MySQL 人家的 char(10) 的含義是可以存儲(chǔ) 10個(gè)字符。
看到了吧，其實(shí)數(shù)據(jù)類型的不同之處，還是很值得大家關(guān)注的。
MySQL5.7 內(nèi)置數(shù)據(jù)類型
DB2 10.1 內(nèi)置數(shù)據(jù)類型
@ThinkJ 信泰人壽保險(xiǎn)股份有限公司 技術(shù)經(jīng)理：
DSG的同步工具也能做類型的映射和轉(zhuǎn)換，效果也還不錯(cuò)
@anonym DBA：
兩種辦法：
1.使用工具做轉(zhuǎn)換。譬如：Oracle -> MySQL 的工具: ora2mysql；Oracle->PG: ora2pg
2.對(duì)照表梳理出來(lái)手工做。
Oracle->MySQL的對(duì)照表:
Oralce->PG的對(duì)照表：
varchar2 -> varchar
number -> numeric
sysdate -> now()
clob -> text/BYTEA
BLOB -> BYTEA
6、Oracle、DB2 與 MySQL、PG 的 SQL語(yǔ)法有很多不兼容的地方，有什么工具可以完成 SQL的轉(zhuǎn)換嗎？
【問題描述】Oracle、DB2傳統(tǒng)關(guān)系型數(shù)據(jù)庫(kù)的 SQL語(yǔ)法 與 MySQL、PG 有很多不兼容的地方。
例如：實(shí)現(xiàn)字符拼接的 SQL
Oracle、DB2：
select name || ' is work at ' || dept from employee where empid=10;
而 MySQL：
select concat ( name, ' is work at ', dept ) from employee where empid=10;
有什么工具可以完成 SQL的自動(dòng)轉(zhuǎn)換嗎？
@ThinkJ 信泰人壽保險(xiǎn)股份有限公司 技術(shù)經(jīng)理：
要完全兼容Oracle的語(yǔ)法是一件非常困難的事，目前業(yè)內(nèi)兼容Oracle做的比較好的應(yīng)該是EDB了，阿里云號(hào)稱兼容Oracle的PPAS實(shí)際上就是EDB，DB2的Oracle兼容也是EDB提供的技術(shù)，但是從我們實(shí)際的測(cè)試來(lái)看，也還是有很多不盡如人意的地方。所以想完全實(shí)現(xiàn)自動(dòng)轉(zhuǎn)換，基本上沒這個(gè)可能。不過(guò)部分的兼容是可能的，如果是PostgreSQL體系，可以使用諸如orafce這樣的插件，還有ora2pg這樣的工具，可以實(shí)現(xiàn)類型的自動(dòng)映射，以及存儲(chǔ)過(guò)程代碼部分自動(dòng)轉(zhuǎn)換，而且ora2pg是perl編寫的，很容易實(shí)現(xiàn)定制化。
@馮巖 銀行 數(shù)據(jù)庫(kù)管理員：
EDB 的確是個(gè)好動(dòng)西，之前用過(guò) MKT，遷移 Oracle 到 DB2 的神器。
Oracle 遷移到 DB2，IBM就有類似的工具，實(shí)在無(wú)法轉(zhuǎn)換，還可以直接啟用 DB2 的兼容特性，直接兼容 Oracle的語(yǔ)法。
7、Oracle與mysql 、PG等有些語(yǔ)法、數(shù)據(jù)類型等略有不同，遷移過(guò)去后是否必須要逐條修正？
@馮巖 銀行 數(shù)據(jù)庫(kù)管理員：
遷移前期，Oracle 與 MySQL 、PG 的 SQL語(yǔ)法兼容性，數(shù)據(jù)類型間的映射關(guān)系就要提前測(cè)試驗(yàn)證好。
然后，在測(cè)試環(huán)境使用準(zhǔn)生產(chǎn)數(shù)據(jù)進(jìn)行 不斷地 遷移演練，不斷改善遷移中越到的類似問題。
zymh_zy 國(guó)內(nèi)某公司 IT顧問：
都是關(guān)系型數(shù)據(jù)庫(kù)，SQL都是共通的。所以，遷移過(guò)去，大部份85%都兼容，估計(jì)15%要后期調(diào)整一下。
8、Oracle數(shù)據(jù)庫(kù)遷移至MySQL、PG等分布式數(shù)據(jù)庫(kù)后，上層應(yīng)用是否需要修改，修改的方面有哪些？
@anonym DBA：
是否需要修改，修改那些，多大工作量，這些都非常依賴你目前應(yīng)用是如何使用Oracle的，具體來(lái)說(shuō)就是使用多少，Oralce中MySQL不擅長(zhǎng)或功能弱的東西，譬如過(guò)渡依賴數(shù)據(jù)去解決業(yè)務(wù)問題，過(guò)渡依賴數(shù)據(jù)庫(kù)解決大事務(wù)問題，觸發(fā)器等等。
不管什么業(yè)務(wù)和使用情況，都需要修改幾點(diǎn)是：
1.數(shù)據(jù)類型。Oracle和MySQL不一樣的地方。
2.訪問數(shù)據(jù)源驅(qū)動(dòng)。譬如JDBC。
3.部分SQL寫法。
zymh_zy 國(guó)內(nèi)某公司 IT顧問：
估計(jì)大部份的工作都是放在數(shù)據(jù)端里修改，應(yīng)用里會(huì)比較少改。因?yàn)椋沁w移數(shù)據(jù)庫(kù)，不是遷移應(yīng)用。除非是數(shù)據(jù)庫(kù)端不能修改，或者修改風(fēng)險(xiǎn)大于修改應(yīng)用端，才修改應(yīng)用端。一般都是修改數(shù)據(jù)庫(kù)端。
9、如何保證在運(yùn)行過(guò)程中MySQL的高可靠性及高可用性？
【問題描述】1、數(shù)據(jù)庫(kù)遷移應(yīng)該不難，我經(jīng)歷過(guò)數(shù)據(jù)庫(kù)的遷移2、難的是遷移到mysql數(shù)據(jù)庫(kù)后，應(yīng)該提供怎樣的mysql部署架構(gòu)來(lái)提供高可靠性及高可用性？3、mysql的運(yùn)維認(rèn)證與oracle相比，應(yīng)該要弱一些。怎樣在生產(chǎn)系統(tǒng)遇到數(shù)據(jù)庫(kù)問題的時(shí)候，能夠得到有效的解決？
@guoxilin 某科技公司 高級(jí)非功能測(cè)試專家：
我們這邊為了保證數(shù)據(jù)庫(kù)的健壯性，有針對(duì)性做了一些健壯性測(cè)試， 比如流水庫(kù)異常下通應(yīng)用程序客戶端是否迅速得到故障通知，并立即與數(shù)據(jù)庫(kù)的正常實(shí)例建立新連接，爛SQL下業(yè)務(wù)健壯性測(cè)試，可能存在臟讀一些異常場(chǎng)景驗(yàn)證等，目的通過(guò)這些健壯性測(cè)試和優(yōu)化，最終實(shí)現(xiàn)以下健壯性目標(biāo)：1. 實(shí)際觀察故障影響面符合預(yù)期 2. 監(jiān)控告警有效 3. 報(bào)錯(cuò)提示和原因的關(guān)聯(lián)性有效 4. 恢復(fù)手段有效（若有） 5. 應(yīng)急手段有效
10、Oracle數(shù)據(jù)庫(kù)遷移至MySQL、PG等分布式數(shù)據(jù)庫(kù)后，還能逆向回遷至Oracle數(shù)據(jù)庫(kù)么？
@ThinkJ 信泰人壽保險(xiǎn)股份有限公司 技術(shù)經(jīng)理：
理論上和實(shí)踐上都是可以的，我們目前的做法就是先用同步工具將Oracle的數(shù)據(jù)實(shí)時(shí)同步至PG，切換后，數(shù)據(jù)同步也反向，即PG數(shù)據(jù)實(shí)時(shí)同步至Oracle，這樣能保證應(yīng)用能隨時(shí)在兩套系統(tǒng)中切換，且數(shù)據(jù)保持一致。不過(guò)對(duì)開發(fā)人員要求就會(huì)比較高，需要同時(shí)針對(duì)兩套系統(tǒng)做開發(fā)和測(cè)試。
11、有沒有簡(jiǎn)單方便的方法將Pg遷移到MySQL？
背景：多個(gè)應(yīng)用由于歷史原因有些用pg有些用MySQL。云平臺(tái)部署后發(fā)現(xiàn)pg在自動(dòng)切換，容災(zāi)當(dāng)面不夠完善，運(yùn)維人員配置mycat只做成MySQL。做主備切換時(shí)pg還需人工介入。急切找一種簡(jiǎn)單方便的方法遷移pg到mysql。
@standiviny 某保險(xiǎn)：
1、可用DATAX 類的ETL工具，使用方便，效率還可以，對(duì)于不太熟悉其他工具的，建議此方法
2、部分客戶端軟件支持異構(gòu)同步
@劉建清 中國(guó)建材 系統(tǒng)運(yùn)維工程師：
簡(jiǎn)單的方法就是直接用postgre導(dǎo)出sql，用sql再導(dǎo)入MySQL，也可以用外部dblink的方式引入外部數(shù)據(jù)源試試。
復(fù)雜可靠一點(diǎn)的可以用第三方工具。支持異構(gòu)數(shù)據(jù)庫(kù)備份和恢復(fù)和同步的工具很多，DSG，OGG等。
遷移時(shí)主要注意幾點(diǎn)：
一、數(shù)據(jù)量大?。?/p>
如果數(shù)據(jù)量很小，且只有簡(jiǎn)單的幾個(gè)表的話，直接用表導(dǎo)出sql的方式，就可以實(shí)現(xiàn)。
數(shù)據(jù)量大的話，需要考慮導(dǎo)出文件的大小和存儲(chǔ)方式，要不備份時(shí)間會(huì)很長(zhǎng)。
二、 遷移數(shù)據(jù)傳輸方式；
遷移時(shí)，是否用外部存儲(chǔ)，網(wǎng)絡(luò)傳輸？或都其它方式都影響效率。
三、 應(yīng)用兼容支持情況；
遷移到mysql后看是否有新的應(yīng)用支持,需要做好測(cè)試工作。
@ThinkJ 信泰人壽保險(xiǎn)股份有限公司 技術(shù)經(jīng)理：
pgpool除了能做PG的負(fù)載均衡、讀寫分離，也能做主備的自動(dòng)切換。而且更強(qiáng)大的是pgpool對(duì)使用了函數(shù)的sql也能做負(fù)載和讀寫分離，建議可以嘗試使用下
12、MySQL、PG屬于分布式數(shù)據(jù)庫(kù)嗎？怎么區(qū)分?jǐn)?shù)據(jù)庫(kù)是否為分布式？
@samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫(kù)管理員：
應(yīng)該這么說(shuō)，基于MySQL 和 postgresql 數(shù)據(jù)庫(kù)的分布式架構(gòu)
類似的產(chǎn)品有 citus 和 greenplum，都是基于postgresql 的分布式數(shù)據(jù)庫(kù)產(chǎn)品
@fengshaoyi JSHBANK 應(yīng)用保障工程師：
下一篇：SSD硬盤白菜價(jià)？2000元就能買到4TB，但我勸你碰都別碰