從一款工具談異構遷移評估那些事
原創(chuàng)近期關注到云和恩墨發(fā)布的一款工具-SCA,它可以協(xié)助用戶評估異構數(shù)據(jù)庫遷移。近些年個人參與了不少異構數(shù)據(jù)庫遷移,自己也曾有想法做個工具用來評估異構遷移的兼容性及性能等問題。這一工具也給出一種實現(xiàn),可以對很多面臨數(shù)據(jù)庫遷移的用戶帶來現(xiàn)實參考意義。本文就嘗試從此工具的功能著手,談談異構數(shù)據(jù)庫遷移的那些事。
1. SCA 產(chǎn)品功能說明
(1)功能概述
讓我們先來看看發(fā)布的此款工具的功能,下面信息取自部分 SCA 工具官網(wǎng)描述。SCA 全稱 SQL Compatible Analysis,是一款異構數(shù)據(jù)庫遷移前的 SQL 兼容和性能評估工具。可用于異構數(shù)據(jù)遷移前的兼容性評估,評估源數(shù)據(jù)庫中的實際業(yè)務 SQL 在目標庫中是否存在語法問題,以及評估兩款異構數(shù)據(jù)庫中的 SQL 實際執(zhí)行的性能差異。目前此工具支持五種源端數(shù)據(jù)庫,包括:Oracle、MySQL、DB2、PostgreSQL、Informix、SQL Server。此工具執(zhí)行分為四個步驟,也包含很多執(zhí)行選項。簡單整理如下:

(2)輸出解讀
這里我們重點看看其輸出報告,報告采用網(wǎng)頁或EXCEL文件的格式,內(nèi)部包含了豐富的信息。下面逐一說明下:?數(shù)據(jù)庫畫像這部分通過掃描源庫,收集到源數(shù)據(jù)庫基本信息、性能、對象、SQL等各類信息。在基本信息部分,又包括有主機資源層面信息(CPU、MEM、NET)、數(shù)據(jù)庫信息(版本、角色、架構、歸檔狀態(tài)、字符集)。

在性能部分,則包括有多維度數(shù)據(jù)庫性能指標,如 Oracle 數(shù)據(jù)庫就包括有 DB time、CPU time、連接數(shù)、TPS、QPS、Redo Size、邏輯讀,物理讀等。

在對象部分,則包括各對象類型統(tǒng)計、非標/保留對象列表、大對象統(tǒng)計以及各對象明細的統(tǒng)計信息。

對象兼容度匯總
這部分通過對比源庫與目標庫的兼容能力,分析出對象層面的兼容情況,并分類展示。在展示中按照用戶名、對象類型、狀態(tài)進行匯總,展示相關分類的對象總數(shù)以及兼容情況。針對不兼容的對象,就需要考慮在真正遷移中進行修改。

SQL 兼容度匯總
這部分通過對比源庫與目標庫的SQL兼容情況,評估給出SQL兼容(直接兼容、改寫兼容)及不兼容的情況。展示中按照用戶名、程序名、模塊名匯總,展示系統(tǒng)中采集到的所有 SQL,以及這些 SQL 在目標庫支持情況。這些信息對于后續(xù)評估改造的工作量評估,有非常直觀的指導意義。

SQL 改寫規(guī)則
這部分內(nèi)容根據(jù)掃描后的結果,結合系統(tǒng)內(nèi)置的改寫規(guī)則,給出該條規(guī)則的觸發(fā)情況,包括該規(guī)則在 SQL 中的命中數(shù)量及為規(guī)則匹配的 SQL 數(shù)量。

SQL 復雜度分布
這部分則是通過復雜度評估標準,判斷出復雜 SQL 的分布情況。這些復雜的 SQL 也是在遷移過后需要重點關注性能問題,這樣可以有效避免性能問題可能導致的業(yè)務故障。目前復雜度的評判標準包括有表關聯(lián)的數(shù)量、Connect By語法使用、自定義函數(shù)數(shù)量、函數(shù)執(zhí)行耗時。針對每條SQL的復雜度都會按照上述標準進行匯總評估,給出SQL復雜度。

SQL 性能對比
這部分是在結構、數(shù)據(jù)遷移完畢后,真實執(zhí)行SQL,采集源端和目標端的執(zhí)行性能進行比較。按照執(zhí)行性能的總體情況及分列情況的展示。其中總體部分,可以簡單評估下遷移完成后在目標庫的整體運行狀態(tài),包括性能有提升的SQL比例、性能下降的SQL比例、不支持的SQL比例等。

在分列的部分則可以按照工作負載、SQL、超時維度展示具體的TOP SQL的情況,包括此SQL的性能變化情況及對整體負載的影響情況。這一能力很贊,可以篩選出影響大的SQL,優(yōu)先優(yōu)化解決。

此外針對每條SQL可以詳細展開,包括SQL文本、綁定變量、執(zhí)行計劃、執(zhí)行詳情、關聯(lián)對象、統(tǒng)計信息等。

2. 異構遷移評估的若干難點
SCA,這一工具給我們異構數(shù)據(jù)庫遷移的一個很好的工程化實踐范例。那這一工具的實現(xiàn)功能上,也反映出遷移評估的若干難點問題。這些問題也正是困擾著用戶如何快速替換一款數(shù)據(jù)庫。這些難點問題,簡單整理如下:
(1)全面詳實地收集源庫各類信息
在我們談異構遷移之前,首要問題就是如何全面詳實地收集源端庫的各類信息。SCA 工具幫我們收集了如硬件、操作系統(tǒng)、數(shù)據(jù)庫基本信息、對象、SQL類的信息,但從遷移角度來說這些信息還是不夠的。之前筆者也曾經(jīng)寫過一個模板,方便用收集源庫的信息,具體參見“調(diào)研模板”,這也是結合之前工作經(jīng)歷整理所得。但在實際使用中,收集效果往往大打折扣,原因一方面是因為很多信息用戶也不清楚,另一方面也是覺得填寫繁瑣、不愿意花精力填寫。但按照以往的經(jīng)驗,這個過程是值得的。本人就曾經(jīng)遇到多次因為收集信息不完整導致遷移方案失敗,甚至到上線之前才知悉,再選擇其他方案代價很大。那么簡化這一過程的最好方式就是工具化、自動化,類似 SCA 這樣的工具能夠幫助用戶極大簡化這一過程。
(2)對目標數(shù)據(jù)庫能力有充分理解
異構數(shù)據(jù)庫遷移,一方面要盡量詳實地了解源數(shù)據(jù)庫的情況,另一方面也要對目標數(shù)據(jù)庫的能力有個全面理解。特別是目標庫如果采用的新架構、新技術等,與源數(shù)據(jù)庫通常不能簡單一一比對。例如之前源數(shù)據(jù)庫采用集中式架構、目標數(shù)據(jù)庫采用分布式架構,那么原有很多源庫的能力就不能簡單照搬過來,需要新的做法、甚至是在應用、架構層面做更多的考慮。
(3)正確理解“兼容”的概念
很多用戶理解兼容,是一個很美好的狀態(tài)。在應用不需要任何修改的情況下,就可以全面照搬過來。其實兼容是個很復雜的事,本人之前也寫過一篇關于兼容性的文章,參考“Oracle兼容性面面觀”。僅就 SQL 的兼容性問題,就需要一方面考慮語法、語義的兼容情況,一方面考慮不同的兼容方式(完全兼容、等價兼容),還要考慮如性能表現(xiàn)、異常處理等情況。SCA 工具這方面做的不錯,給出了不同兼容的統(tǒng)計及性能數(shù)據(jù)的對比。
(4)復雜對象和語句的遷移問題
很難有兩個數(shù)據(jù)庫是可以完美兼容適配的,針對源庫那些復雜對象和語句,如不能在目標庫上有對等實現(xiàn)也要給出必要的解決路徑。從對象來看,如庫內(nèi)計算(包、存儲過程、觸發(fā)器、函數(shù))、視圖(含物化視圖)、序列(自增類型)、特殊字段(大對象、JSON)等,是需要考慮目標庫的實現(xiàn)機理和能力及是否有其他替代方案。例如很多存儲過程,就可以轉(zhuǎn)化為外置過程來解決。從SQL語句來看,復雜SQL的處理是容易出現(xiàn)問題的,SCA 工具也意識到這點給出了專項的統(tǒng)計。即使在目標庫可以實現(xiàn),也建議盡量簡化語句邏輯,避免潛在的執(zhí)行風險。
(5)從“仿真”角度評估遷移結果
如何真實地還原源庫的工作負載,在目標庫上進行仿真重演,進而評估遷移后的結果,這是最為準確的評估。這里不僅是單一對象、語句的遷移評估,而是真實的、帶有業(yè)務負載的、有數(shù)據(jù)質(zhì)量差異(甚至是錯誤數(shù)據(jù))下的測試結果,這樣才能真實反映出評估后的結果。很多時候,單一對象或語句都是可以很“完美”的跑出結果,但是放在真實環(huán)境下就會出現(xiàn)各種問題。其結果的反饋,可以通過與源庫的結果對比來進行評估。有的時候往往是一些很細節(jié)的地方非常容易出現(xiàn)問題,例如空值的處理、精度問題、時區(qū)問題等。
寫在最后
隨著國產(chǎn)化替換浪潮涌現(xiàn),正有越來越多的企業(yè)在計劃或正在進行數(shù)據(jù)庫替換工作。異構數(shù)據(jù)庫遷移評估,成為用戶實現(xiàn)替換的必備條件之一,也是困擾很多用戶的一點。SCA 工具做了一個很好的嘗試,大大方便了用戶的遷移評估工作,有效地降低了遷移成本。國內(nèi)有很多廠商也有類似的實現(xiàn),通過獨立的小工具完成此類評估。從產(chǎn)品角度來講,也是一個不錯的“引流”產(chǎn)品,并吸引用戶最終選擇自家數(shù)據(jù)庫。在這里也希望各廠商能夠更加關注這一能力的構建,加速用戶落地實踐。




























