二、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上性能指标；随着用户业务量的增加，平滑的支持业务需求。整个过程可以确保客户业务真正做到平滑迁移。

作者：stromal

本文为阿里云原创内容，未经允许不得转载