8.1 多租户架构：CDB与PDB
8.1 多租户架构：CDB与PDB
本节摘要：多租户是 12c 以来 Oracle 架构层面最大的变化：一个容器数据库（CDB）承载多个可插拔库（PDB），每个 PDB 对应用完全透明、像独立库一样使用。本节讲清 CDB 与 PDB 的分工、租户的插拔与搬迁操作、以及"共享故障域"这个必须正面回答的代价。
一、一台服务器养一百个库的难题
8.1 的瘦身计划算过账：十几套库的运维成本与套数成正比。传统解法是"一台机器装多个实例"——省了硬件，省不了补丁与监控，而且实例之间抢内存抢 CPU 全靠自觉。多租户从内核层面换了解法：**容器数据库（CDB）**只装一份内核与共享组件（SYSTEM、UNDO、临时表空间等公共设施），**可插拔库（PDB）**装各自的业务数据与用户，插进 CDB 即可用。对应用来说，连 PDB 和连一个独立库毫无区别——连接串、表名、账号原样不变；对运维来说，十二套库收进两个 CDB 后，补丁打两次、备份策略配两套、监控面板两张。
二、租户的操作：插、拔、克隆、搬迁
PDB 的精髓在"可插拔"：一个 PDB 本质是一组数据文件加数据字典，拔出（unplug）后只是脱离容器注册，文件原样保留；插入（plug）到另一个 CDB 就能继续服务。这组操作让"库的搬迁"从导出导入（按天计）变成文件级操作（按小时计）：
-- 查看容器结构与租户状态 SELECT con_id, name, open_mode FROM v$containers; -- 克隆：一秒级复制一个租户（开发测试环境的标准做法） CREATE PLUGGABLE DATABASE sales_dev FROM sales ADMIN USER dev_admin IDENTIFIED BY "口令"; ALTER PLUGGABLE DATABASE sales_dev OPEN; -- 拔出：脱离当前容器（XML 描述文件记录文件清单） ALTER PLUGGABLE DATABASE sales CLOSE; ALTER PLUGGABLE DATABASE sales UNPLUG INTO '/tmp/sales.xml'; -- 插入到另一个 CDB：目标库上核对兼容性后注册 CREATE PLUGGABLE DATABASE sales USING '/tmp/sales.xml' NOCOPY; ALTER PLUGGABLE DATABASE sales OPEN; -- 跨 CDB 搬迁的现代表达：relocate 子句在线迁移（源库保持在线） CREATE PLUGGABLE DATABASE sales_new FROM sales@源库链接 RELOCATE AVAILABILITY MAX; -- 租户级日常运维：单独开关、单独资源限额 ALTER PLUGGABLE DATABASE sales CLOSE IMMEDIATE; ALTER SYSTEM SET resource_manager_plan = 'PDB_PLAN' CONTAINER = ALL;
搬迁的两个工程细节决定成败。兼容性核对：插入前用 DBMS_PDB.CHECK_PLUG_COMPATIBILITY 校验源 PDB 与目标 CDB 的版本与参数，别等到 OPEN 时报一堆错。角色隔离：PDB 里的用户、角色、表空间互相独立，但 CDB 层的参数修改（CONTAINER=ALL）会波及全部租户——这是便利也是风险，生产 CDB 上"影响全租户的操作"要走变更审批。
图 8-1：CDB 容器与 PDB 租户的结构与共享边界
三、案例：十二套库收进两个容器的全过程
背景。 8.1 开头的瘦身计划进入实施：12 套库（最大 1.8TB，最小 30GB）要收进 2 个 CDB。分组原则定了两条——按补丁窗口分组（核心与边缘分开），按故障域分组（核心租户不与边缘租户同居）。
操作。 分四批搬迁，每批的动作相同：目标 CDB 预建并校验版本兼容、源库做 0 级备份、用 RELOCATE 在线搬迁（30GB 小库直接拔插）、搬迁后核对数据字典与应用连接、观察 48 小时。第三批遇到一个例外：某库用了废弃的旧式复制特性，版本升级后无法在线搬迁，改为 Data Pump 逻辑迁移，该库的窗口从 2 小时变成 9 小时。
结果。 六周完成 12 套到 2 套的收敛：季度补丁从 12 次降到 2 次，服务器从 12 台缩到 5 台，备份窗口总长缩短 40%。唯一没达到预期的是 CPU 收缩——原以为 12 台机器的负载能压进 4 台，实际 5 台：多租户共享内核省的是"每库一份后台进程"的开销，省不出业务本身的算力。解读。 这笔账的教训是预期管理：多租户的收益在运维密度（补丁、监控、备份套数），不在硬件总量的等比例缩减。变式。 若租户间性能互踩严重（邻租户问题），升级手段有三档：租户级资源配额、关键租户迁往独立 CDB、或上 21c 之后的每 PDB 独立 UNDO——按冲突烈度选档，别一步跳到全拆。
四、常见问题
⚠️ 常见坑：把 CDB 当成"更大的单库"来管。容器的全局操作（改参数、打补丁、动公共组件）会波及所有租户，必须有变更评审；反之租户级操作要习惯性带上 CONTAINER 限定，误把租户操作打到 CDB 根上的事故，恢复成本按全租户计。
问题一：CDB 里的公共用户和本地用户怎么区分？ 公共用户（C## 开头）建在容器根上、在所有租户里可见，用于跨租户管理；本地用户建在各自 PDB 里、只在本租户有效。设计原则是公共用户越少越好——只留管理与监控需要的两三个，业务账号一律本地建。公共用户权限泄漏的爆炸半径是全部租户，这个风险要与它的便利性放上天平。
问题二：一个 CDB 该装多少个 PDB？ 技术上限很高，工程答案取决于三个约束：补丁窗口（一个 CDB 的租户共享升级窗口，租户越多窗口协调越难）、故障域半径（CDB 崩溃影响全部租户）、资源总量（共享 SGA 与进程对租户总数的承载）。多数生产环境的答案是十到二十个——超过这个数量级，就该按业务线拆第二个 CDB，而不是无限装填。
问题三：PDB 能做细粒度资源隔离吗？ 能，且有专门的机制：租户级配额（对共享资源的使用比例）加租户内的会话与并行度限制，配合资源计划按租户分配 CPU 与 I/O 份额。但隔离的上限要清醒——所有租户仍共享一个实例的内存与进程，"吵闹邻居"只能被限流，不能被物理隔开。需要物理级隔离的租户，答案是独立 CDB 或 8.2 的云端形态，这不是配额能解决的。
问题四：多租户的许可怎么算？ 这是收编项目预算评审的必答题：多租户是企业版选件，按容器库的处理器许可计费，与租户数量无关。测算时把"省下的服务器与运维成本"和"新增的选件许可"放进同一张表，多数规模下收编是划算的，但小规模环境（两三套小库）可能算不平——工具的价值永远跟着规模走。
问题五：收编前要给应用方交代什么？ 三件事：连接串不变（应用零改造是 PDB 的核心卖点）、各自的维护窗口可能合并（同一容器统一打补丁）、出现共享边界告警时配合排查。应用方最关心的第一条要在评估阶段就当面验证——拿测试环境连一次新容器，消除"动了连接就是大改造"的误解，收编阻力会小很多。
本节要点回顾
- 分工一句话：CDB 管内核与公共设施，PDB 管业务与用户；应用视角 PDB 就是独立库。
- 插拔是文件级搬迁：unplug 加 plug 按小时计，RELOCATE 在线搬迁零中断；搬前必跑兼容性校验。
- 共享边界是代价：故障域一起停、参数一起改——分组原则（补丁节奏、故障域）在收编前就要定。
- 收益在运维密度：补丁与备份套数等比缩减；硬件总量按业务算力算，别指望等比例缩。
容器把库变轻了，下一节把机房也变轻：三种云形态的账怎么算、责任怎么分。