摘要：“让技术被看见 | OceanBase 布道师计划”由 OceanBase 主办，CSDN 协办，面向广大开发者的年度征文活动。

“让技术被看见 | OceanBase 布道师计划”由 OceanBase 主办，CSDN 协办，面向广大开发者的年度征文活动。

全年 4 轮，以季度为周期进行优秀文章评比，每年 1 届，以年为单位进行最佳布道师评选。

目前，首轮技术征文获奖文章已评选出炉，本篇内容为「OceanBase 布道师计划」优秀

稿：https://open.oceanbase.com/blog/essay-competition。

评委有话说

屠敏（CSDN 资讯主编、《新程序员》特约专栏记者）：通过详尽的对比和实际操作示例，作者不仅深入分析了oracle PDB与OceanBase在多租户管理上的差异，还结合实际案例展示了各自的优势和局限，是一篇对数据库管理员和技术爱好者极具价值的分析文章。

封仲淹（OceanBase 开源生态总监、OceanBase 开源社区负责人）：这篇介绍多租户的文章，非常出彩。多租户本身是用户需要的一个高频功能，是用户非常关注的一个功能，这篇文章分别就Oracle和Oceanbase做了非常详细的介绍，详细的介绍Oracle和Oceanbase如何使用多租户，并且基于2个系统的多租户能力对比，最后文章还给出了自己对国产数据库的很多思考，值得推荐。

章芋文（墨天轮社区负责人）：这篇文章主要探讨了从Oracle PDB到OceanBase多租户特性的国产数据库核心特性体验。文章从存储计算资源分配与隔离、用户权限分配与隔离、运维管理与可观测性三个方面，对比分析了Oracle和Oceanbase在多租户管理上的差异和特点。通过详尽的对比测试，充分展示了Oceanbase在资源分配、用户权限隔离、高可用性、备份恢复等方面具有与Oracle相似甚至更优的特性，为数据库选型提供了非常有力的参考价值，同时也体现出国产数据库在多租户管理能力上的进步和潜力。

数据库是一个要实操的软件，仅仅停留在纸面上的理论，终究要落地到实际操作中。在本篇文章中，我以自己的实际操作，进一步来体验分析多租户这一数据库的新特性。

细粒度的资源分配与隔离

存算与权限，PDB与Oceanbase各自能做到什么样的细粒度？

1.1 存储资源的隔离

Oracle除了表空间文件的限制，也有pdb上限存储空间的管理，其中参数STORAGE(MAXSIZE n)来控制，可以在创建时显式指定，也可以再修改。

以当前主流的Oracle19c为例，首先我们创建一个PDB叫testpdb，存储上限1GB，并且表空间文件只有100MB：

除了Oracle一直有的可以精准控制表空间的上限，在pdb的存储上限中，也有一个参数MAXSIZE可以控制整个PDB的存储资源上限。如果超过限制会报错：

1.2 计算资源的隔离

计算资源每个产品的定义可能不一样，本文的计算资源主要是指IO、CPU与内存三种资源。

1.2.1 内存管理

Oracle在非PDB架构下已经很成熟，PDB架构也基本继承了SGA与PGA的参数管理，既可以为所有PDB统一规划内存分配，也可以单独为某一个PDB规划：

在这一步里，因为我先切到了testpdb，因此后面所有对SGA与PGA的操作，全部都是对testpdb做的。如果不执行第一条，在sqplus进入之后直接执行四条ALTER SYSTEM，就可以对所有PDB做操作。完成之后，可以验证我们分配的结果，实例如下：

1.2.2 IO管理

和内存的管理有点相似的是，Oracle同样可以对每个的IOPS做上限的控制，也是一条命令：

如果不切到指定的pdb，那么后两条命令的生效范围就是所有pdb。同样可以用查询来验证结果，因为我测试过程没有跑什么业务，所以这两个指标都没有触达上限：

1.2.3 CPU管理

CPU的管理，Oracle19c既可以通过cpu_count和内存以及IO一样直接分配pdb的cpu，同样引入了资源计划的概念，通过资源计划绑定pdb来实现cpu的资源隔离。

资源计划是一个比较大的功能，如果有机会我写一篇文章详解，这里我们主要介绍一下用参数直接调整。假设现在我们有一台服务器，一共16个逻辑CPU，我们要通过资源计划限制上限4个给它。

此时testpdb能够使用的cpu上限就是4个逻辑CPU，如果不在PDB中指定这几个参数，那么每个PDB默认可以使用的上限就是根容器的cpu_count上限。可以通过查询可以看到结果：

1.3 用户权限的分配与隔离

在Oracle的pdb架构下，创建用户进一步被细分，一部分是pdb下的用户，这些用户仅仅被特定的pdb可见，不会出现在其他pdb或者根容器cdb$root下。而根容器下禁止创建本地用户，只能创建c##开头的用户，通过授权，这类用户可以在不同pdb之间登陆。

例如我在testpdb下，创建一个新用户test1，并查询：

在根容器下同样不会出现。

在根容器下创建一个多租户通用的用户c##test1，创建和授权，都可以指定在具体某个pdb中生效，或者是所有pdb。

这里需要注意的是，执行了这两条语句，虽然c##test1已经可存在于所有pdb，但是除了testpdb没有任何权限，所以除了testpdb，其他pdb是连登录都没有的。

1.4 小结

Oracle在PDB中的细粒度资源隔离，我来做一个小结：

实现了PDB级别的权限隔离，同样名称的用户，可以存在于不同的PDB中，互不干扰。

根容器的高权限用户，例如sys可以对所有pdb做所有操作，权限不受影响。

根容器中可以创建跨pdb的用户，可以指定pdb范围，可以实现在不同pdb下的不同权限。

存算资源，都做到了细粒度的资源分配，可以通过参数配置上限下限，从而做到不同pdb之间的资源分配。

提供了更加复杂且精确的资源计划功能，需要更多的配置，后续如果有机会展开描述。

在PDB层面，确实是实现了权限的隔离，但其实这并不是完全严格的权限隔离，根容器的SYS用户仍然可以干扰pdb下的数据库运维管理。

2. Oceanbase的资源分配与隔离

Oceanbase的多租户之间的资源隔离，是通过两个方式来实现的，一个是在租户创建中定义的资源规格与资源池，另一个就是类似Oracle的资源管理计划。我们着重介绍前者。

2.1 资源规格

资源规格（Unit）是对 CPU、内存、磁盘空间、IOPS 等资源项进行的定义。包含了CPU、内存、日志盘空间、IOPS 等资源项。具体的创建语法如下：

我们能看见的是，这里面实际包含的项目有内存上限、CPU上限下限、日志盘大小、IOPS上限下限与权重。一个数据库集群，允许拥有多种资源规格。实际上这个思想更加接近云原生，能够通过自定义，创建不同规格的资源组，根据实际业务需求分配不同数量的资源组：

2.2 资源池

顾名思义，资源池是在创建多租户时可以使用的资源集合，而其中资源分配的最小粒度就是资源规格，语法如下：

2.3 创建租户

创建资源组与资源池是创建租户的先决条件，实际上创建租户是从资源池里获取资源，完成租户的创建，租户的资源取决于资源池里的资源数量，而通过修改资源组的资源，可以直接对租户做扩缩容。

例如我们创建一个租户tenant1，使用资源池rp1：

2.4 权限分配与隔离

租户创建完成之后，会自动生成超级用户root或者sys，根据是mysql模式还是oracle模式有所不同，第一次登录没有密码，需要用户自行修改。

与Oracle不同的是，Oceanbase的多租户权限分配与隔离，更加严格。不同租户之间的用户是完全隔离的，而且就连重置租户的管理员密码功能，也无法通过系统租户来实现。这一点上更为严格，集群管理员无从得知租户管理员的密码，相当程度上减少了密码的人为泄露风险。

我们以MySQL模式为例，首先我们在租户tenant1创建一个用户test

登录到系统租户，是不会看到这个用户的

在系统租户中，创建一个用户root_test

登录到tenant1，同样也没有

虽然两个租户都有同一个用户root，但是彼此之间也是完全不同的两个用户，通过加入租户名称来区分，如果用其中一个租户的root登录另一个root租户，一定会报错（当然如果两个密码一样也是可以成功的）

2.5 小结

接下来我来对Oceanbase的多租户资源分配与隔离做一个小结：

1. Oceanbase基于云原生的思路，所有租户的创建，都必须经过unit、pool、租户三个级别，缺一不可。

2. unit的引入，让租户的资源分配以及扩缩容更加灵活，更方便地管理不同租户之间的资源分配。

3. Oceanbase实现了严格意义上的用户权限隔离，安全性非常好，与Oracle模式相比，各有千秋。

4. 与Oracle相比，Oceanbase的资源分配模式更注重更少地人工干预，尽量实现标准化的资源分配。

这部分思量再三，还是决定放到同一个大标题下一起写，这两者有时候是你中有我，我中有你的关系。

3.1 租户管理

Oracle的pdb，可以实现对租户的非常细粒度的管理，从语法树可见一斑

pdb_unplug_clause，顾名思义，就是pdb的插拔选项。unplug的pdb，以XML与PDB等文件的方式保存在存储中，可以通过复制到其他地方，实现pdb的快速迁移

pdb_settings_clauses，对pdb的各个参数做调整，包含临时表空间、默认表空间、重命名、日志管理、时区、端口等内容

pdb_datafile_clause，pdb数据文件的维护，主要功能是对特定数据文件的online与offline操作

pdb_recovery_clauses，pdb级别的热备份或者dataguard恢复功能

pdb_change_state，对pdb状态的操作，与非pdb架构的oracle实例相似，除了close, mounted与open三种状态，还有一个migrate用于升级

pdb_change_state_from_root，在根容器中，批量修改一个或多个pdb状态的子句，与上一个状态范围一样

application_clauses，对pdb单独维护，包括更新application，application补丁的安装与升级

snapshot_clauses，快照管理，包括对pdb做快照、删除快照、将快照克隆成为新pdb等功能

prepare_clause，准备pdb的镜像副本，例如将某个pdb变成HIGH REDUNDANCY，用过ASM的话对这个应该不陌生

drop_mirror_copy，删除镜像副本

lost_write_protection，写丢失保护功能，在打开之后，如果文件进入写丢失保护的恢复状态，会告警

我们几个例子，有关这些命令的：

3.2 租户的高可用

在Oracle19c中，暂时不支持PDB级别的dataguard，在21c之后才支持。然而在19c中，RMAN已经支持了pdb级别的备份恢复，这一点大大提升了日常管理的便利性。

例如，我们使用sys用户登录RMAN

同样，也可以使用pdb的用户直接登录RMAN，使用熟悉的BACKUP DATABASE;

PDB的恢复，同样可以使用sys或者pdb的管理员来执行，例如

3.3 租户的克隆

Oracle19c提供了pdb的克隆，而19c甚至支持了热克隆，在源库能够继续保持可用的情况下，完成pdb的克隆，当然这期间pdb的性能也会受到影响。例如

3.4 可观测性

Oracle的可观测性，一直在诸多数据库中是独一档的。19c在pdb中，提供了如下几种手段：

1. 动态视图。这个在非pdb架构之前，就是很多dba一直津津乐道的，在pdb时代，除了增加了一些v$pdb开头的视图，也增加了一些原有视图关于pdb的字段，例如查看pdb可更新的参数

3. AWR报告。在pdb环境中，已经可以允许pdb的dba单独生成pdba的awr报告，诊断内容与原有的Oracle AWR基本一致，过往的经验可以平移过来。很多针对pdb的性能指标，也有所体现。

3.5 小结

针对Oracle19c提供的运维与可观测特性，我做一个总结：

1. 对pdb的细粒度管理非常到位，在非pdb架构下能做的维护，基本在pdb都能实现。

2. 支持了RMAN对pdb的备份恢复，而且放权给了pdb的dba，在多租户的架构下解放了集群dba。

3. 19c不支持pdb级别的dataguard，后续版本支持，这是这个版本的一个遗憾。

4. 可观测性做的依旧非常优秀，针对pdb的各项优化都很好。

5. 非常重要的是，过往的运维管理经验，都可以迁移到pdb。

4.1 租户管理

这一部分，我们依旧通过ALTER TENANT命令来解析，在Oceanbase中，该命令的语法树如下：

我们先看tenant_option的几个选项，都包含了哪些功能。

LOCALITY，修改租户副本在各个zone之间分布的情况，作为多副本的分布式数据库，这是在Oceanbase中特有的功能

PRIMARY_ZONE，修改租户的 Primary Zone，这个zone负责储存该租户的所有副本，来确保数据的高可用

RESOURCE_POOL_LIST，修改租户的资源池，通过该命令，可以对租户做扩缩容

ENABLE_ARBITRATION_SERVICE，部署了仲裁服务的场景下，修改租户仲裁服务的开启状态，分布式事务相关的参数

[DEFAULT] TABLEGROUP，修改租户的表组，可以控制一组表在物理存储上的邻近关系

ENABLE_EXTENDED_ROWID，指定是否为租户内所有表开启Extended ROWID模式，开启rowid的上限则会大幅提高

system_var_name，修改租户的系统变量，可以涵盖的参数非常多

RENAME GLOBAL_NAME TO，修改租户名称

LOCK | UNLOCK，锁定或解锁租户，租户锁定后，不能在该租户上创建新的连接，已有连接保持不变

从参数列表来看，Oceanbase作为云原生的分布式数据库，相当多的管理命令是集中在分布式的管理，比如zone相关就占了相当高的比例。除此之外，Oceanbase的系统租户，可以对普通租户的参数直接做调整而不需要登录，这一点和Oracle最终实现的结果是一样的。要找出与Oracle的差异，可能没有批量对租户参数做调整的功能。我们照样来看几个例子：

4.2 租户的高可用

Oceanbase的高可用，涉及到了多副本、多zone等因素，实际想要描述清楚，就要比Oracle难一些。我尝试着总结提炼，有可能有总结不当，还请指正。

1.高可用与多副本。可以实现多地多副本的数据一致性，这就提供了租户在不同地区的数据高可用，与Dataguard的异地灾备有着接近的效果。这里与Oracle19c不一样的是，可以通过ALTER TENANT命令来实现单个租户的不同副本数，不同的租户可以以不同的副本数量来存在，这一点更为灵活。

2.备用租户。Oceanbase确实是在租户级别实现了主备的逻辑区分。语法树如下：

语法树来看，备租户的创建其实和普通租户创建步骤差不多，先创建unit在创建resource_pool，最后创建租户时，需要加关键字standby，而效果与Dataguard十分相似，就连用户和权限都可以保持一模一样，唯独角色是STANDBY：

如果我们将这个备租户激活，那么状态会发生变化：

3.备份与恢复。Oceanbase能够实现租户级别的备份与恢复，而且备份目标端，可以支持低成本的对象存储。例如在集群中，我们有一个nfs路径，将租户备份至此，备份的历史信息可以通过视图DBA_OB_BACKUP_STORAGE_INFO去查询

4.3 租户的克隆

同样，Oceanbase也提供了租户克隆的功能，语法树如下：

语法与Oracle的pdb克隆也有相似之处，new from old的模式。两个参数分别对应了新租户的资源池与资源组，需要在克隆时显式指定资源池的名称，以及资源组的配置。例如，我们创建一个租户tenant2，资源池命名为rp3，而使用的资源规格，仍然是unit1：

而克隆这一过程，需要时间，根据租户的大小耗时不等，好在Oceanbase提供了取消克隆命令，以及查看克隆历史的视图DBA_OB_CLONE_HISTORY，例如，我们重新登录一个会话，可以取消克隆，并查看结果：

4.4 可观测性

截止到Oceanbase4.3，一共有如下几种手段能够提高我们对数据库的可观测性：

1. 各类视图。和Oracle类似，Oceanbase提供了v$或gv$开头的大量视图。这些视图包含了按照租户级别统计的各类动态指标，例如V$SESSTAT，就包含了一列CON_ID，代表租户ID，通过与租户列表join，就可以获取到所有租户的会话等等。

2. OCP。OCP是Oceanbase开发的WEB管理系统，定位和Oracle的EMCC很像，既包含了实时监控的动态指标，又可以对数据库做比较多的操作。其中对于多租户之间的资源占比、租户内部的统计信息，都有不同维度的可视化参考，基本上涵盖了常用的多租户可视化运维需求。

3. ASH。Oceanbase除了具有Oracle兼容的语法与管理模式，还开发了自己的ASH报告。而工作负载库的名称DBMS_WORKLOAD_REPOSITORY也与Oracle保持一致。ASH作为抓取短期内性能指标用于分析的工具，在性能监控和优化中使用频繁。Oceanbase的版本，基本涵盖了Oracle中对应的概念与指标，也是DBA所关注的。

4.5 小结

最后做一个总结，Oceanbase在多租户运维和可观测性方面的特点：

1. 因为架构上的差异，Oceanbase提供了针对分布式、资源池、zone、租户克隆等特性对应的多租户管理方式，能够覆盖到多租户的日常管理需求。

2. 提供了类似Dataguard的Standby模式，并且支持激活或者主备切换standby的运维，这一点与Oracle Dataguard有着相同的思路。

3. 备份恢复这里，我个人认为，Oceanbase的产品能力，距离RMAN还有差距，备份恢复仍然需要一定的学习门槛。

4. OCP作为自研的管理平台，易用性方面较为不错，而且系统响应的时间，我认为好于Oracle的EMCC，期待后续功能继续增加。

5. Oracle过往的pdb管理经验，能够大部分平移过来，需要适应的是语法和架构差异带来的变化。

通过比较两个产品，实际上Oceanbase的多租户特性以及管理能力，已经在诸多方面不亚于Oracle的pdb，而且基于自己分布式和云原生的特性，在许多方面都有自己的见解和路线，比如创建资源池和资源规格的方式，打破了过去大家的思维定势，用另一种方式去解释去定义资源的分配与隔离。而有些地方我认为甚至超越了Oracle19c，例如租户级别的switchover。当然也一些地方，仍然需要努力，比如RMAN一样简单上手，几个命令就能完成的备份恢复工具。还有一些使用体验上的小地方。而且本文没有涉及到两个点，一个是同等配置下的性能对比，另一个是系统的可靠性稳定性的对比，时间所限，我只能从功能层面上来尽力完成。我相信后续，会有更多的DBA去做比我更详细更可靠的对比分析。留给Oceanbase团队的各种考验和挑战，其实并没有结束。

这篇文章写到这里，已经写了八千多字，还是想说点个人情绪相关的。本来还想要不要继续拆成两篇文章，纠结之后还是选择了一篇完成。从9月开始准备，国庆期间断断续续完成操作，终于今天完成落笔。期间因为黑神话悟空的游玩，一度中断，好在假期没有出去玩，不断督促自己完成了。不能不说，还是存在虎头蛇尾的情况，在这里给各位道个歉。实际上在这一个月多月的过程里，我阅读了很多Oracle以及Oceanbase的官方文档。好在Oceanbase的多位朋友一直给予各种帮助，以及Oceanbase文档内容的翔实、产品力的健壮，后面很多例子干脆就拿了官方文档，让我能够完成这篇流水账。

期间我也翻了Oceanbase的历史版本，如同看一个人的成长历程，如何从一个孩子慢慢长大一般。也为我们国产数据库有这样的成长感到喝彩。平心而论，Oceanbase在多租户管理方面的能力和进步，超出了我做整个系列文章之前的预期。从产品设计到研发测试再到文档支持，中间任何一个环节的缺失，都不可能有今天的Oceanbase。曾几何时，我也希望自己你作为国产数据库从业者，开发一款让自己、让客户、让同行感觉很酷的产品。而在Oceanbase这里，我仿佛看到了曾经梦想中的产品。

当然，我仍然像泼一盆冷水。Oracle也在不断演进，很多pdb的特性在21c或者21ai中，也让我眼前一亮。这些新特性在Oceanbase上或者还没有，或者让我感觉做的还不够好。高标准严要求，我希望有一天，Oceanbase也能实现那样的能力和特性，而不是躺在今天的功劳簿上偷懒。国产数据库的和新特性，需要的是十年如一日，持之以恒的投入。

同样我也期望，有一天有更多国产数据库品牌，能够创造更多的惊喜给这个行业。面对滥竽充数的东西，平时我没少骂，而面对好的东西，我也一定会用尽我的言辞去夸奖。每个人都是自己人生路上的天命人，每个成功的数据库品牌，都是自己剧本里的孙大圣。

完结之前，突然想到我的师爷，有着当代毕升之称的王选院士，毕生的遗憾之一，就是没有见过他本人，我入学的时候，他已经作古。然而他的汉字激光排版技术，却照亮了一代又一代后辈。——他走之后，我们不必记挂着他，因为我们就是他。国产数据库这座高峰，就是我们这代人攀登的目标。

来源：CSDN