去O是一個系統工程，有一定的技術門檻。而業務系統的情況多種多樣，有的業務系統資料量少、業務邏輯簡單、系統壓力也不大，而有的業務系統資料量龐大、業務邏輯複雜、對效能要求也比較高。本文主要是簡要介紹在通常情況下（在不考慮一些特殊場景和需求的情況下），開展去O工作的一個常規步驟。

1、界定範圍

明確去O所涉及的系統範圍是第一要務。只有清晰的界定好範圍，才能保證後續的工作不會產生偏差。

具體來說，需要收集下列資訊：

1. 涉及的系統功能和使用人員

2. 涉及系統執行的業務高峰時段和低峰時段

3. 涉及的應用伺服器的資訊，包括CPU、記憶體、磁碟空間、網路卡等

4. 涉及的Oracle資料庫伺服器的資訊，包括CPU、記憶體、磁碟空間、網路卡等

5. 涉及的Oracle上的資料庫物件資訊

a) schema清單

b) 表清單（使用大物件欄位(BLOB\CLOB\LONG RAW\BFILE)的要單獨標註出來）

c) 索引清單

d) Package清單

e) 儲存過程清單

f) 自定義函式清單

g) dblink清單

h) trigger清單

i) job清單

j) 檢視清單

k) 分割槽表清單

l) 物化檢視清單

m) 同義詞清單

n) Sequence清單

6. 涉及的Oracle上的資料庫物件所佔磁碟空間的資訊，主要是表和索引所佔的磁碟空間情況

7. 涉及的Oracle上的每個表中記錄總數的統計資訊

8. 涉及的Oracle資料庫是否存在邏輯備庫，物理備庫是否對外提供讀服務

9. 涉及的Oracle資料庫的查詢和計算是什麼型別的，是OLAP統計報表型別的還是OLTP交易查詢型別的

2、系統架構初步最佳化

以下兩種情況在傳統O架構中明視訊記憶體在，我們需要考慮在去O過程中是否要採取新的架構來進行實現：

1. 圖片、文件、大文字物件等被儲存在Oracle資料庫大欄位中，一方面到會導致單表所需的磁碟空間急劇膨脹，另一方面對含大欄位的庫表進行讀寫的時候，也會產生大量IO，造成資料庫系統總體效能下降。

2. OLAP型別的統計計算和OLTP型別的交易查詢計算混合在Oracle上執行。

由於傳統O架構和雲架構不同，因此在去O之後需要考慮是否要做架構調整和最佳化。

推薦的方案是：

1. 將Oracle大欄位型別存放到”共享檔案系統”中，資料庫中只儲存”共享檔案系統”中的訪問路徑。這樣在應用真的需要讀取這些大物件進行展示的時候，才進行兩次查詢獲取大物件。這樣的好處是資料庫所需儲存空間會下降很多，讀寫表的IO也會明顯下降。

2. 對於單表資料量較大（記錄數千萬級）的表、Oracle儲存容量較大或併發訪問量超過萬級以上的schema，需使用分散式MySQL叢集進行分庫分表。

3. 對於實時性要求不高的統計分析需求，可以透過ETL工具自動將資料同步到大資料平臺上進行離線計算，並待離線計算完成之後，將計算結果回寫MYSQL中支援實時查詢的需求。

需要注意的事，採取上述架構調整，會導致資料流發生變化，也需要進行更多的應用改造。因此需要結合應用改造、工期、資料流變化所帶來的業務影響等因素找到一個平衡點。

3、資料流梳理

去O本質上會導致資料流的走向發生變化，因此要梳理清楚資料是從何而來，到哪裡而去。具體的說，就是資料都是誰寫入到Oracle中，誰從Oracle中獲取資料，並且評估去O對會對資料的寫入、讀取產生什麼影響。

主要要梳理以下方面：

1. 資料的來源方

a) 第一步界定的資料庫表中的資料是否有來源於外部系統的

b) 外部系統是如何將資料寫入到本系統資料庫中的，是直接訪問資料庫寫入資料，還是透過呼叫本系統的對外介面寫入資料

c) 是實時寫入還是定時寫入

d) 去O之後，外部系統是否需要配合進行程式修改，如果需要修改，都需要哪些修改

2. 資料的讀取方

a) 第一步界定的資料庫表中的資料是否有外部系統需要讀取的

b) 外部系統是如何讀取資料的，是直接訪問庫表讀取，亦或者是透過同義詞、檢視、dblink的方式進行讀取，還是透過呼叫本系統的對外介面進行讀取

c) 是實時讀取還是定時dump資料

d) 去O之後，外部系統是否需要配合進行程式修改，如果需要修改，都需要哪些修改

3. 架構最佳化調整所導致的資料流變化

a) “共享檔案系統”的寫入和讀取方都有哪些系統，需要考慮應用改造

b) 確定需要同步到大資料平臺進行OLAP計算的資料範圍，確定需要從大資料平臺離線計算後迴流到MYSQL中進行實時查詢的資料範圍

4、Oracle的功能適配

作為一款成熟的商業軟體，Oracle提供了很多強大的功能。在去O的過程，為了得到更好的效能，Oracle的一些特性需要考慮進行適配，具體見下表格：

常見的資料型別對應如下：

其他與Oracle特性相關的問題也需要考慮：

1. SQL語法、限制字元(escape code)及保留字

2. 物件命名是否大小寫敏感

3. 大欄位的支援(CLOB、BLOB、BFILE等)

4. JOIN型別的支援（影響到SQL效能）

5. 資料量或效能上限（是否要拆表、拆庫）

5、去O應用程式改造

透過前面的系統改造分析，可以逐步明確去O過程中應用系統的改造點，一般情況下會包含以下幾方面：

1. 本系統應用程式的改造

a) 讀寫Oracle改造為讀寫MySQL/分散式MySQL叢集

b) 根據第五章所述，Oracle適配方案做相應應用改造

c) 大物件讀寫到”共享檔案系統”的應用改造，以及存量資料遷移到”共享檔案系統”的應用改造

d) 統計型別的OLAP計算遷移到大資料平臺上的應用改造，以及相關資料流變化帶來的資料同步任務配置

2. 外部系統的應用改造

a) 針對直接訪問Oracle庫的應用需要配合進行應用改造和遷移

b) 資料流發生變化導致的介面適配改造，例如介面檔案投遞位置發生變化

3. 資料庫物件遷移

a) 表結構遷移

b) 非表物件的遷移（檢視/物化檢視/函式/儲存過程/觸發器/JOB等）

4. J2EE應用遷移

a) 同構J2EE應用伺服器。例如從AIX作業系統中的Weblogic Server遷移到部署在CentOS作業系統中的Weblogic Server. 這種情況比較簡單，就是應用打包後重新部署，只需要簡單的測試。

b) 異構J2EE應用伺服器。例如從AIX作業系統中的Weblogic Server遷移到部署在CentOS作業系統中的Tomcat應用伺服器，這種情況一般不會有什麼問題。最好首先檢查一下JDK版本，重新打包部署成功後進行一段時間的測試，避免出現一些異常現象。另外如果原來用到Weblogic Server Cluster功能，則需要配置多臺應用伺服器，可以配置SLB連線後端多臺Tomcat Server來達到應用伺服器叢集的效果。

6、功能和效能測試

去O本質是應用系統進行重構,因此一定要在上線前指定好測試方案，並進行充分的功能測試和效能測試。安排熟悉業務的人員進行功能測試驗證，並根據業務對系統的效能要求進行充分的效能壓測。

7、存量資料遷移及應用切換上線

去O相關應用改造開發完成，並透過功能測試和效能測試之後，需要考慮新版應用切換上線以及存量歷史資料遷移到雲平臺的方案。由於Oracle和MySQL是兩種異構的資料庫，因此無法透過Oracle資料檔案磁碟複製的方式進行資料遷移，而必須採用應用從Oracle讀取資料在寫入到MYSQL的方式完成存量歷史資料的遷移工作。

一般情況下，有如下兩個方案：

方案一：

當資料量比較大的情況下，第二部耗時會很長，會導致停業務時間過長。因此比較適合在資料量比較小，而且業務可以接受停服務的情況使用。

方案二：

此方案的特點是在第一階段用ETL工具進行資料遷移時，業務是不停的。當處於基本追上狀態的時候，意味著MYSQL上的資料和Oracle上的資料只差分鐘級別的變化量。只需要在Oracle上停寫幾分鐘，完成這部分增量資料的同步，就可以達成Oracle和MySQL中資料處於最終一致的狀態。此時，啟動新版應用就可以快速恢復業務。全程下來，停業務的時間只是在分鐘級別。

遷移過程中需要考慮以下問題：

1. 表數量及資料量（遷移工作量）

2. 頻寬（遷移時間）

3. 網路環境（源、目的資料庫是否同時可達）

4. 是否有停應用遷移視窗（效能影響、增量遷移需求）

5. 意外中斷（OGG支援斷點續遷）

6. 遷移效率（併發，讀取最佳化，寫入最佳化）

7. 資料準確性（資料比對及校驗）

8. 帳戶許可權

9. 外來鍵等約束的遷移

MySQL去O的實施技術

相關文章