RM新时代国际平台

  • 

    • <div id="r605l"></div>
  • 

        <th id="r605l"></th>
        3. 






        
    
        
        
    
        

        











        
    
        
        
        
            
        
                
        
                    
        
                        
        
                            

                            
        
                               
        Oracle 遷移至 MySQL、PG等分布式數(shù)據(jù)庫，可能遇到的12個典型問題
        


        1、不同數(shù)據(jù)庫之間的異構(gòu)數(shù)據(jù)如何做到無損遷移？Oracle存量數(shù)據(jù)如何成功遷移至MYSQL、PG等分布式數(shù)據(jù)庫？
        

        @anonym DBA：
        

        如果是遷移至PG的話，可以采用ora2pg+oracle_fdw，可以保證正確性，效率也還可以?；蛘哂肈SG的同步軟件也能進行數(shù)據(jù)的遷移，但是在實際使用中，用DSG的來做全庫的初始化效率稍微有點差
        

        @韓成亮 KE 數(shù)據(jù)庫管理員：
        

        首先需要確定遷移到數(shù)據(jù)庫的類型，不同的數(shù)據(jù)庫內(nèi)部結(jié)構(gòu)都是不一樣的，需要非常熟悉彼此的差別，其次是需要考慮遷移后的維護問題，高可用的方案，而不是單純的說 無損遷移。
        

        如果真純粹是想無損遷移，直接二進制文件導出導入，保證數(shù)據(jù)不會丟。010101 這種的，數(shù)據(jù)百分百不會丟失，無非是讀取的問題。
        

        如果單純的考慮表的數(shù)據(jù)，那么需要詳細對比不同數(shù)據(jù)的字段類型的兼容性。
        

        @standiviny 某保險：
        

        無損遷移存量數(shù)據(jù)，首先不同數(shù)據(jù)庫有不同的數(shù)據(jù)類型和支持的功能，遷移前需要梳理清楚，應(yīng)該就不會有太大問題
        



        2、Oracle數(shù)據(jù)庫遷移至MYSQL、PG等分布式數(shù)據(jù)庫過程中如何保障系統(tǒng)穩(wěn)定性？如何設(shè)置異構(gòu)數(shù)據(jù)庫并行過渡期？
        

        @泊涯 高偉達公司 系統(tǒng)測試工程師：
        

        系統(tǒng)運營的穩(wěn)定性，是不是切換過去有一定時間的試運行吧，如果客戶允許可以嘗試切割方式，分幾次遷移，兩邊都同步運行一小段時間。
        

        @samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫管理員：
        

        通過應(yīng)用雙寫，在應(yīng)用控制一致性，確保異構(gòu)數(shù)據(jù)庫都能運行正常，最后停掉遷移之前的DB。
        

        @standiviny 某保險：
        

        是否接受義務(wù)中斷？業(yè)務(wù)是否不同的場景方式不同，建議將場景描述清楚一些，會更容易答復。
        



        3、將業(yè)務(wù)邏輯實現(xiàn)方從Oracle數(shù)據(jù)庫上移至應(yīng)用，那么如何評估改造量和改造難度？兼容性如何保障？
        

        【問題描述】Oracle數(shù)據(jù)庫往往和應(yīng)用耦合度較高，遷移過程還會涉及到應(yīng)用遷移和改造，特別是存儲過程、觸發(fā)器、自定義函數(shù)等方面的改造，將業(yè)務(wù)邏輯實現(xiàn)方從數(shù)據(jù)庫上移至應(yīng)用，那么如何評估改造量和改造難度？兼容性如何保障？
        

        @岳彩波 產(chǎn)品經(jīng)理：
        

        不管系統(tǒng)大小，都要遵循以下原則：
        

        一 、應(yīng)用評估
        

        確定項目的要求
        

        估計工作量
        

        業(yè)務(wù)需求分析
        

        分析應(yīng)用
        

        計劃遷移項目
        

        二、應(yīng)用移植
        

        應(yīng)用數(shù)據(jù)遷移
        

        應(yīng)用軟件遷移
        

        應(yīng)用軟件適配新環(huán)境
        

        數(shù)據(jù)庫從開發(fā)環(huán)境移動到生產(chǎn)環(huán)境
        

        應(yīng)用從開發(fā)環(huán)境移動到生產(chǎn)環(huán)境
        

        實施部署策略
        

        三、性能調(diào)優(yōu)
        

        測試數(shù)據(jù)庫和應(yīng)用程序遷移
        

        進行性能測試和調(diào)優(yōu)
        

        樓主所說的工作量都要經(jīng)過詳細的評估以后才能確定，另外現(xiàn)在有開源的遷移工具和兼容插件，基本上能節(jié)省數(shù)據(jù)和語法遷移的60%時間，可以試試。
        



        4、數(shù)據(jù)庫遷移完成后如何成功建轉(zhuǎn)運？
        

        【問題描述】數(shù)據(jù)庫遷移完成后如何成功建轉(zhuǎn)運？或者說，在數(shù)據(jù)庫設(shè)計階段如何設(shè)計運維方案？除了分布式數(shù)據(jù)庫的高可用、負載均衡設(shè)計，傳統(tǒng)運維方案中的網(wǎng)絡(luò)、存儲、監(jiān)控告警、備份恢復等等應(yīng)該如何規(guī)劃？
        

        @ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理：
        

        這是個很大的問題了，涉及到運維的規(guī)范和流程等問題。從我們的經(jīng)驗來看，是盡可能的融入到現(xiàn)有的運維體系中，盡量避免大的改造；然后盡早進行培訓，以使人員盡快適應(yīng)變化。
        



        5、Oracle、DB2 遷移至 MYSQL、PG 的 表的限制、數(shù)據(jù)類型映射關(guān)系，如何處理？
        

        【問題描述】（問題來自@馮巖 銀行 數(shù)據(jù)庫管理員） 在 Oracle、DB2 到 MySQL的遷移過程中，大家主要關(guān)注應(yīng)用層面的兼容問題。但是，數(shù)據(jù)類型的映射轉(zhuǎn)換如何處理呢？
        

        我就拿簡單的字符串數(shù)據(jù)類型舉個例子吧：
        

        Oracle、DB2 與 MySQL，同樣的 utf-8 編碼格式，同樣的表定義，都包含一個 數(shù)據(jù)類型 char(10) 的字段。
        

        我要將 “一二三四五上山打老虎” 這個字符串 insert 到這個字段，猜猜會發(fā)生什么？
        

        您肯定會說 “一二三四五上山打老虎” 占了 30 byte ，肯定報錯的。
        

        但人家 MySQL的 char(10) 就是把這個含著“老虎”的字符串給“吃”了， 而只有 Oracle、DB2 拋出了類似 “ value is too long ”的錯誤。
        

        為什么呢？因為 Oracle、DB2的 char(10) 最多只能接收10 字節(jié)的字符串長度，而 MySQL 人家的 char(10) 的含義是可以存儲 10個字符。
        

        看到了吧，其實數(shù)據(jù)類型的不同之處，還是很值得大家關(guān)注的。
        

        MySQL5.7 內(nèi)置數(shù)據(jù)類型
        


        DB2 10.1 內(nèi)置數(shù)據(jù)類型
        


        @ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理：
        

        DSG的同步工具也能做類型的映射和轉(zhuǎn)換，效果也還不錯
        

        @anonym DBA：
        

        兩種辦法：
        

        1.使用工具做轉(zhuǎn)換。譬如：Oracle -> MySQL 的工具: ora2mysql；Oracle->PG: ora2pg
        

        2.對照表梳理出來手工做。
        

        Oracle->MySQL的對照表:
        


        Oralce->PG的對照表：
        

        varchar2 -> varchar
        

        number -> numeric
        

        sysdate -> now()
        

        clob -> text/BYTEA
        

        BLOB -> BYTEA
        



        6、Oracle、DB2 與 MySQL、PG 的 SQL語法有很多不兼容的地方，有什么工具可以完成 SQL的轉(zhuǎn)換嗎？
        

        【問題描述】Oracle、DB2傳統(tǒng)關(guān)系型數(shù)據(jù)庫的 SQL語法 與 MySQL、PG 有很多不兼容的地方。
        

        例如：實現(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的自動轉(zhuǎn)換嗎？
        

        @ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理：
        

        要完全兼容Oracle的語法是一件非常困難的事，目前業(yè)內(nèi)兼容Oracle做的比較好的應(yīng)該是EDB了，阿里云號稱兼容Oracle的PPAS實際上就是EDB，DB2的Oracle兼容也是EDB提供的技術(shù)，但是從我們實際的測試來看，也還是有很多不盡如人意的地方。所以想完全實現(xiàn)自動轉(zhuǎn)換，基本上沒這個可能。不過部分的兼容是可能的，如果是PostgreSQL體系，可以使用諸如orafce這樣的插件，還有ora2pg這樣的工具，可以實現(xiàn)類型的自動映射，以及存儲過程代碼部分自動轉(zhuǎn)換，而且ora2pg是perl編寫的，很容易實現(xiàn)定制化。
        

        @馮巖 銀行 數(shù)據(jù)庫管理員：
        

        EDB 的確是個好動西，之前用過 MKT，遷移 Oracle 到 DB2 的神器。
        

        Oracle 遷移到 DB2，IBM就有類似的工具，實在無法轉(zhuǎn)換，還可以直接啟用 DB2 的兼容特性，直接兼容 Oracle的語法。
        



        7、Oracle與mysql 、PG等有些語法、數(shù)據(jù)類型等略有不同，遷移過去后是否必須要逐條修正？
        

        @馮巖 銀行 數(shù)據(jù)庫管理員：
        

        遷移前期，Oracle 與 MySQL 、PG 的 SQL語法兼容性，數(shù)據(jù)類型間的映射關(guān)系就要提前測試驗證好。
        

        然后，在測試環(huán)境使用準生產(chǎn)數(shù)據(jù)進行 不斷地 遷移演練，不斷改善遷移中越到的類似問題。
        

        zymh_zy 國內(nèi)某公司 IT顧問：
        

        都是關(guān)系型數(shù)據(jù)庫，SQL都是共通的。所以，遷移過去，大部份85%都兼容，估計15%要后期調(diào)整一下。
        



        8、Oracle數(shù)據(jù)庫遷移至MySQL、PG等分布式數(shù)據(jù)庫后，上層應(yīng)用是否需要修改，修改的方面有哪些？
        

        @anonym DBA：
        

        是否需要修改，修改那些，多大工作量，這些都非常依賴你目前應(yīng)用是如何使用Oracle的，具體來說就是使用多少，Oralce中MySQL不擅長或功能弱的東西，譬如過渡依賴數(shù)據(jù)去解決業(yè)務(wù)問題，過渡依賴數(shù)據(jù)庫解決大事務(wù)問題，觸發(fā)器等等。
        

        不管什么業(yè)務(wù)和使用情況，都需要修改幾點是：
        

        1.數(shù)據(jù)類型。Oracle和MySQL不一樣的地方。
        

        2.訪問數(shù)據(jù)源驅(qū)動。譬如JDBC。
        

        3.部分SQL寫法。
        

        zymh_zy 國內(nèi)某公司 IT顧問：
        

        估計大部份的工作都是放在數(shù)據(jù)端里修改，應(yīng)用里會比較少改。因為，是遷移數(shù)據(jù)庫，不是遷移應(yīng)用。除非是數(shù)據(jù)庫端不能修改，或者修改風險大于修改應(yīng)用端，才修改應(yīng)用端。一般都是修改數(shù)據(jù)庫端。
        



        9、如何保證在運行過程中MySQL的高可靠性及高可用性？
        

        【問題描述】1、數(shù)據(jù)庫遷移應(yīng)該不難，我經(jīng)歷過數(shù)據(jù)庫的遷移2、難的是遷移到mysql數(shù)據(jù)庫后，應(yīng)該提供怎樣的mysql部署架構(gòu)來提供高可靠性及高可用性？3、mysql的運維認證與oracle相比，應(yīng)該要弱一些。怎樣在生產(chǎn)系統(tǒng)遇到數(shù)據(jù)庫問題的時候，能夠得到有效的解決？
        

        @guoxilin 某科技公司 高級非功能測試專家：
        

        我們這邊為了保證數(shù)據(jù)庫的健壯性，有針對性做了一些健壯性測試， 比如流水庫異常下通應(yīng)用程序客戶端是否迅速得到故障通知，并立即與數(shù)據(jù)庫的正常實例建立新連接，爛SQL下業(yè)務(wù)健壯性測試，可能存在臟讀一些異常場景驗證等，目的通過這些健壯性測試和優(yōu)化，最終實現(xiàn)以下健壯性目標：1. 實際觀察故障影響面符合預(yù)期 2. 監(jiān)控告警有效 3. 報錯提示和原因的關(guān)聯(lián)性有效 4. 恢復手段有效（若有） 5. 應(yīng)急手段有效
        



        10、Oracle數(shù)據(jù)庫遷移至MySQL、PG等分布式數(shù)據(jù)庫后，還能逆向回遷至Oracle數(shù)據(jù)庫么？
        

        @ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理：
        

        理論上和實踐上都是可以的，我們目前的做法就是先用同步工具將Oracle的數(shù)據(jù)實時同步至PG，切換后，數(shù)據(jù)同步也反向，即PG數(shù)據(jù)實時同步至Oracle，這樣能保證應(yīng)用能隨時在兩套系統(tǒng)中切換，且數(shù)據(jù)保持一致。不過對開發(fā)人員要求就會比較高，需要同時針對兩套系統(tǒng)做開發(fā)和測試。
        



        11、有沒有簡單方便的方法將Pg遷移到MySQL？
        

        背景：多個應(yīng)用由于歷史原因有些用pg有些用MySQL。云平臺部署后發(fā)現(xiàn)pg在自動切換，容災(zāi)當面不夠完善，運維人員配置mycat只做成MySQL。做主備切換時pg還需人工介入。急切找一種簡單方便的方法遷移pg到mysql。
        

        @standiviny 某保險：
        

        1、可用DATAX 類的ETL工具，使用方便，效率還可以，對于不太熟悉其他工具的，建議此方法
        

        2、部分客戶端軟件支持異構(gòu)同步
        

        @劉建清 中國建材 系統(tǒng)運維工程師：
        

        簡單的方法就是直接用postgre導出sql，用sql再導入MySQL，也可以用外部dblink的方式引入外部數(shù)據(jù)源試試。
        

        復雜可靠一點的可以用第三方工具。支持異構(gòu)數(shù)據(jù)庫備份和恢復和同步的工具很多，DSG，OGG等。
        

        遷移時主要注意幾點：
        

        一、數(shù)據(jù)量大?。?/p>

        如果數(shù)據(jù)量很小，且只有簡單的幾個表的話，直接用表導出sql的方式，就可以實現(xiàn)。
        

        數(shù)據(jù)量大的話，需要考慮導出文件的大小和存儲方式，要不備份時間會很長。
        

        二、 遷移數(shù)據(jù)傳輸方式；
        

        遷移時，是否用外部存儲，網(wǎng)絡(luò)傳輸？或都其它方式都影響效率。
        

        三、 應(yīng)用兼容支持情況；
        

        遷移到mysql后看是否有新的應(yīng)用支持,需要做好測試工作。
        

        @ThinkJ 信泰人壽保險股份有限公司 技術(shù)經(jīng)理：
        

        pgpool除了能做PG的負載均衡、讀寫分離，也能做主備的自動切換。而且更強大的是pgpool對使用了函數(shù)的sql也能做負載和讀寫分離，建議可以嘗試使用下
        



        12、MySQL、PG屬于分布式數(shù)據(jù)庫嗎？怎么區(qū)分數(shù)據(jù)庫是否為分布式？
        

        @samkingno 北京去哪兒網(wǎng) 數(shù)據(jù)庫管理員：
        

        應(yīng)該這么說，基于MySQL 和 postgresql 數(shù)據(jù)庫的分布式架構(gòu)
        

        類似的產(chǎn)品有 citus 和 greenplum，都是基于postgresql 的分布式數(shù)據(jù)庫產(chǎn)品
        

        @fengshaoyi JSHBANK 應(yīng)用保障工程師：

        
下一篇：SSD硬盤白菜價？2000元就能買到4TB，但我勸你碰都別碰
                            
        
                        
        
                    
        
                
        
            
        
            
        
        
    
        

        







    














RM新时代国际平台

      3. 

        5. <div id="r605l"></div>
      6. 

            <th id="r605l"></th>
            3. 

            


            

          3. 

            5. <div id="r605l"></div>
          6. 

                <th id="r605l"></th>
                3. 

                

                

新时代RM|国际平台
新时代软件下载
RM新时代官网网址
rm新时代是正规平台
新时代rm平台入口