摘要：Oracle兼容性是業務客戶從Oracle生態遷移到PolarDB生態的第一步也是至關重要的一步，PolarDB通過不斷沉澱支持大量實際業務的真實Oracle兼容性功能，確保客戶業務可以真正做到平滑遷移。同時PolarDB帶給Oracle生態客戶的不僅僅是上的來的問題，PolarDB在成本、性能、可用性、擴展性等雲能力方面也給用戶帶來更高的業務價值。在DTCC 2020大會分佈式數據庫實踐專場上，阿里巴巴高級數據庫專家趙殿奎為大家介紹阿里巴巴電PolarDB的Oracle平滑遷移之路。
演講嘉賓簡介：趙殿奎，阿里巴巴高級數據庫專家，從事OLTP數據庫和OLAP數據庫產品的研發工作10餘年，現為阿里雲PolarDB數據庫內核北京研發負責人。
以下內容根據演講視頻以及PPT整理而成。
本次分享主要圍繞以下四個方面：
一、PolarDB架構
二、PolarDB兼容性
三、PolarDB增強
四、PolarDB遷移
一、PolarDB架構
PolarDB架構組件 —— CM
PolarDB架構是基於共享存儲的架構，下圖是PolarDB整體架構視圖，其中CM主要負責的工作包括整個Polar集群的管理，Top管理，高層管理、備份管理及審計管理。CM是一個管控鏈路的核心組件，這意味著CM組件本身對於PolarDB的整個數據的可用性沒有任何影響，PolarDB的可用性完全獨立於整個數據鏈路。由於PolarDB會面向大量的用戶來使用，因此對整個架構的設計中需要把可用性放在第一位，因此每一個組件的設計也都要滿足PolarDB高可用性要求。
PolarDB架構組件 —— Agent
下圖中另一個比較重要的組件是Agent，Agent主要做什麼？很多常見數據庫會將部分功能都集成到數據庫內核裡面。但PolarDB是將很多功能放在Agent中，例如審計、數據採集、監控、備份數據發送等等。相當於將一部分輔助性功能獨立出來，做成一個核心的組件，同時放在數據管控鏈路裡面。
其餘的還有Proxy，是讀寫路由的組件。PFSD是阿里雲的分佈式文件系統。
PolarDB既可以運行在裸機上面，就是傳統的物理機，還可以跑在國產的芯片，國產的操作系統，以及原生的 k8s上。此外阿里雲基於 k8s做了很多的增強，PolarDB同樣可以運行。這幾種形態上PolarDB都是支持的。
二、PolarDB兼容性
下圖列出了在阿里巴巴很多業務場景中，用戶的用例中使用較多的功能上的兼容性，目前PolarDB的研發上也是在重點支持這些功能的兼容性。
PolarDB兼容性 —— 接口兼容
驅動接口中使用比較多的是OIC，JDBC以及ProC，基本上可以佔據99%以上。Java的是JDBC，但是可能很少碰到ProC，尤其在公共雲上的用戶可能比較少見。但線下的傳統的客戶中，如金融類的客戶會大量的使用ProC進行開發的業務程序。PolarDB基本上都可以兼容OCI裡面的接口。ECPG裡面包含Oracle的ProC代碼的兼容。ECPG兼容最重要的並不是在於對ProC的支持，而在於C的代碼的兼容。為什麼？因為Oracle裡面ProC所支持的各種C語言的標準是無法獲取到的。大量的SQL92，SQL2008的標準，以及目前還在不停的更新的標準都在增加對C代碼語法的支持。PolarDB投入了很多人力做這件事情。XA C接口與ECPG中的Proc接口是結合起來使用的。目前很多PolarDB線下的客戶大量使用了基於XA C、ProC、Oracle Tuxedo結合的方式。下圖羅列了XA C接口的一些功能，目前PolarDB基本上都可以支持。其中最難的是tpsuspend，目前已經解決了。
PolarDB兼容性 —— 語法兼容性
語法的兼容性中包括數據類型、系統函數、偽列、PL/SQL、系統圖以及系統包是比較常用的。但用戶最常用的是空串，每一個使用Oracle數據庫的業務應用都會用到這個特點，但是這個特點往往是很多的數據庫產品並沒有支持到的，導致這些數據庫產品往往可能會在業務的運行的過程中出現很多數據性的問題。到目前為止，Oracle裡面的 PL/SQL，PolarDB大概已經接入了80%多。在Oracle整個的遷移的過程中，大量的業務對 PL/SQL的代碼幾乎是一行都不需要更改。這意味著是PolarDB對於 Oracle PL/SQ的兼容性已經非常精準，可以滿足大多數的業務場景。系統函數、視圖和系統包，PolarDB大概可以支持30多個，這基本上足夠了，下圖中還列出來比較常用的偽列。
PolarDB兼容性 —— 功能兼容性
功能兼容性中分區非常常用。主要的一些分區功能PolarDB都是支持的。對於大規模用戶來說，較為常用的是多層次查詢，大家可能以為層次查詢支持起來比較簡單，但後來發現這往往是用戶非常關心的特性，因此對性能要求非常高。很多數據庫產品層次查詢的實踐方法基本一致，通過WITH語句的迭代，遞歸來實現，但這種方法的性能往往比較差。因此PolarDB在層次查詢功能的實現上從算子層面做了大量的工作。表函數也是用戶使用的特別多的功能，類似於一個pipeline，一個表的輸出作為另一個表的輸入。用戶在DBLINK功能上的使用特別多。公有云產品和線下打通之後，發現反而在安全性的保障上難度難道非常大。線上和線下，公有云和混合雲之間能夠做到數據相互訪問，最大的一個困難就在於安全。資源管理，Oracle裡面有一個Resource Manager，PolarDB也在逐步的完善這個功能，PolarDB現在能夠做到CPU和內存的隔離，同時可以做到數據庫級別、甚至到用戶級別的資源的隔離和限制。DBLINK方面，現在可以支持與Oracle DBLINK， 與PG的DBLINK，與阿里雲 PolarDB DBLINK，以及公雲上的PolarDB和PolarDB之間的DBLINK，可以支持線上的PolarDB與線下的Oracle之間的DBLINK。
PolarDB兼容性 —— 生態兼容性
生態兼容性 —— AWR
2020年上半年阿里雲花了很多人力在PolarDB生態兼容性上。目前公有云的性能監控已經可以做到秒級，為什麼還需要做AWR？AWR其實相當於是兩次狀態之間的快照，用戶可以查看中間的Workload是什麼樣子的。阿里雲在走訪了很多的客戶之後發現用戶在進行大量業務遷移的時候，很多的運維同學和DBA同學對AWR需求非常強烈。由於線下用戶對業務以及整個的遷移運行過程中穩定性要求非常高，因此他們很少會開細粒度的監控。而且也不允許監控的數據能夠對外展示。這時就需要利用AWR將兩個時間差之間負載數據拿到，根據整體負載情況判斷系統的健康情況。如果客戶的生產系統之前使用的是Oracle，那麼也會在Oracle上跑AWR上，與PolarDB上的AWR進行對比，分析數據庫性能在遷移之前和之後的差異。AWR中可以看到內存、CPU、IO的負載情況，甚至還有IO的吞吐、磁盤佔用、IOPS、網絡等資源數據。數據收集上來之後進行分析，哪些負載較高，分析負載高的原因。基於負載情況分析SQL狀態，是否有慢查詢，連接狀態中是否有空載。目前大多數數據庫性能數據都可以通過AWR展示出來。之後，基於AWR數據，比如慢查詢，會給用戶提供優化的建議。目前這部分功能還在迭代，通過整個運行的過程中所發生的事件，展示到AWR，分析是否有HA切換，或者出現硬件故障，以及網絡延遲。同時在AWR中展示硬件、主機的信息。
生態兼容 —— DataMax（ADG）
生態兼容DataMax類似於Oracle的ADG。這個功能已經在線下的大量的公共雲上都發布完成。目前公有云的主備已經做得很好了，那PolarDB為什麼還要做DataMax？而且是類似於Oracle的ADG？事實上PolarDB關注的Oracle的ADG中的Far Sync能力，它可以極大地降低對主庫的讀寫負載。Far Sync可以首先將數據同步到 DataMax。因此可用性可以比原來的主備模式更高。DataMax這個節點變成了一個非常特殊的節點，DataMax節點只有日誌沒有數據，而且日誌只負責轉發。DataMax計算非常簡單，只需要將日誌進行解析，然後轉發出去，因此可以做到更高的可用性，DataMax工作非常輕量，因此延遲較低，可以做到更高的RTO，同時又可以提高性能。DataMax可以同時掛很多Replication節點。可以發現，目前PolarDB很多工作一直在圍繞幾件事情，一個是提高兼容性，第二個是可用性，提高PolarDB整個系統的可用性，使得RPO接近零。
生態兼容 —— DTS（OGG）
DTS是數據同步工具，DTS支持數據數據全量遷移、數據增量同步、數據訂閱SDK以及多種主流異構數據庫，如MySQL，SQL Server、雲上、雲下、自建數據庫。目前數據同步也支持雙向的數據同步。用戶生產系統同步的時候，並不是一次性同步過來的，而是一部分一次，一點一點同步。因此數據同步也是雙向的，可以將一部分業務數據寫到PolarDB，一部分業務寫到Oracle。用戶從Oracle數據同步到PolarDB，還有PolarDB的數據同步到Oracle上面，這類用戶非常多。他們的數據同步可以通過DTS來完成。
生態兼容 —— DBS（RMAN）
DBS類似於Oracle RMAN，備份管理工具。DBS支持全量備份，增量備份，差異備份。基於DBS能力可以做到源端重刪、本地緩存、存儲驅動。DBS具備自己的指紋庫，從而提升數據備份的安全性。備份的數據可以存到DBS支持的源端，包括NAS、磁帶庫，OSS。很多線下大b和大g的客戶經常使用磁帶庫，這是在做大量的線下客戶的支持的過程中發現的。
生態兼容 —— PolarPlus（SQLPlus）
PolarPlus與SQL Plus非常相似。感興趣的同學可以參考PolarDB的官方文檔。
生態兼容 —— 開發工具(DBNavigator)
開發工具主要是通過DBNavigator做的。目前開發工具用戶使用的比較多，尤其是PG生態同學。當然還有很多其它的工具，但是DBNavigator好處在於集成了驅動之後，可以與DBMS_Debug的包連起來，支持 PL/SQL的Debug，使用起來非常方便。
上面總體上介紹了PolarDB在兼容性方面做的工作，包括接口、語法、功能以及生態方面。尤其在生態兼容方面PolarDB做了支持數據庫健康狀態監控的AWR工具、DataMax數據節點、DTS數據同步工具、DBS備份管理工具、DBNavigator開發工具等。那麼在Oracle的兼容性之上，PolarDB還做了哪些增強？
三、PolarDB增強
1. PolarDB增強 —— 性能優化CSN
性能優化方面PolarDB做了CSN快照，對PG社區關注的比較多的話，會看到在2012年的時候，PG社區就提出要做CSN快照。什麼是快照？PolarDB快照獲取方式是比較特殊。與MySQL相似，叫做XID快照，既獲取當前系統的活躍事務鏈表，加上XMIN、XMAX，構造成一個快照，判斷哪些數據是可見的，哪些是不可見的。PolarDB CSN快照同理，CSN快照是在CSN上加了一個XMINXMAX。CSN快照可以提供更高的性能。在高併發情況下，活躍事務特別多，快照的動作非常慢，因為需要做內存拷貝。內存拷貝的動作有一個鎖，這會造成整個業務系統併發的衝突問題。通過測試發現，在沒有使用CSN快照之前，大概最多到40萬TPMC，再往上增加規格時，獲取事務的表的衝突非常嚴重。通過CSN快照，目前在32c之上，一直到128c，大概基本上可以做到線性。用戶在公有云上在業務系統變化越來越大的情況下，可以通過升級用戶業務的規格，為他們帶來性能上的收益。
那麼PG社區自從2012年提出來，到現在還沒做出來，技術上難點在什麼地方？其實在於CSN的設計非常複雜，它涉及到事務、存儲、日誌等。但阿里大概花費了一年的時間就做出來了，這是因為可以將CSN快照與差異快照結合起來，所有與生態相關、或影響生態的功能繼續保留，那麼最大的技術難點在於如何找到CSN快照與差異快照的映射關係。這是阿里做成CSN快照的主要原因。但之後再繼續設計的時候還是會遇到很多的問題，如做成插件或者工具的話，插件或者工具的兼容問題如何解決，與生態的兼容性問題如何解決，備份恢復如何處理？
PolarDB增強 —— DMA高可用
DMA高可用，既基於Raft三節點做的高可用的提升。Raft三節點可以做到RPO等於0，Follower副本只讀，支持容器化部署，兼容主備高可用，CM一體化架構，同城三節點達到同城可能性。
PolarDB增強 —— Ganos
Ganos是一款包含管理，空間幾何數據、時空軌跡、專題柵格、遙感影像的時空大數據引擎系統。系統內置了高效的時空索引算法、空間拓撲幾何算法、遙感影像處理算法等。廣泛應用於空間、時空、遙感大數據存儲。Ganos系統在很多的實際場景中被投入使用，如高德地圖。
PolarDB增強 —— Performance Insight
大家在公有云上使用PolarDB的時候會發現性能指標非常完整，大量的性能指標通過圖表的形式非常清晰的展示給用戶，包括連接Connections、CPU使用率、內存使用率、IOPS負載等數據。目前這些性能數據在線上和線下，公有云和混合雲上都是同步的。
四、PolarDB遷移
PolarDB遷移 —— ADAM
數據庫和應用遷移（Advanced Database & Application Migration, 以下簡稱ADAM）。目前PolarDB的遷移過程中，用戶幾乎不需要修改代碼，遷移的時間越來越短的主要的原因是ADAM。ADAM是阿里雲結合阿里巴巴多年內部業務系統數據庫和應用異構遷移的經驗，自主研發的、遷移Oracle數據庫和應用上雲的企業級遷雲產品和解決方案，能幫助企業最大限度降低Oracle數據庫和應用遷移上雲的風險、技術難度和實施週期。ADAM可以做到線上，線下的用戶直接部署到自己的用戶端，通過對用戶端的代碼進行掃描，採集用戶數據，分析用戶代碼中Oracle的部分哪些是兼容的，哪些是不兼容的，分析如何改進。ADAM還可以自動的對不兼容的代碼進行改寫，包括SQL翻譯、數據庫改造、應用改造、PL/SQL改寫成JAVA。ADAM在用戶遷移到PolarDB的過程中，採集了大量的用戶的特徵，當然用戶已經授權了，分析用戶在遷移過程中哪些功能PolarDB不支持。通過近兩年的不斷的對Oracle功能的兼容性迭代，PolarDB基本已經支持調研的Top 100以內的功能。這使得大多數業務系統遷移到PolarDB越來越快，越來越方便。
PolarDB遷移週期
下圖是用戶業務系統從開始準備遷移，到最後遷移完成會經歷的過程以及會使用到的PolarDB生態中的工具。最開始使用ADAM接入，在業務系統上運行，獲取到兼容性指標、用戶數據庫中各項性能指標負載情況、評估技術可行性；然後在新的Polar上通過Benchmark做測試；滿足用戶性能要求之後，通過DTS數據全量和增量遷移，完成雙向的數據同步；再通過DMS&Console完成數據庫的管理，包括備份、審計等；使用Performance Insight監控用戶的在PolarDB上性能指標；隨著用戶業務量的增加，平滑的支持業務需求。整個過程可以確保客戶業務真正做到平滑遷移。