运维管理30 分钟阅读
OceanBase 租户与资源管理 100 条命令
OceanBase 的租户资源由 Unit 规格、资源池和实际分布在 OBServer 上的 Unit 一起决定。业务说某个租户 CPU 不够，直接看租户名或把 Unit 规格调大，都可能漏掉资源池绑定、Zone 布局和节点剩余容量。查清楚这几层关系，再谈扩容会稳妥得多。
2026年9月16日阅读—点赞—收藏—
dba100oceanbasescenario
DBA100
100 条命令系列文章专栏
OceanBase 租户与资源管理 100 条命令
前言
OceanBase 的租户资源由 Unit 规格、资源池和实际分布在 OBServer 上的 Unit 一起决定。业务说某个租户 CPU 不够，直接看租户名或把 Unit 规格调大，都可能漏掉资源池绑定、Zone 布局和节点剩余容量。查清楚这几层关系，再谈扩容会稳妥得多。
这篇按 root@sys 在现场核对资源的顺序整理命令：先找租户，再找资源池、规格和 Unit 的落点，最后看节点能否承接变化。日常容量巡检或扩缩容窗口可以按这个顺序查，建议收藏备用。
示例基于 OceanBase 数据库分布式版 V4.3.0。除注明外，在 MySQL 模式的 root@sys 下查询 oceanbase 视图；租户名、Zone 名和 OBServer 地址按现场替换。改动资源规格或迁移 Unit 的命令会放在只读检查之后。
OceanBase 租户资源池、Unit 规格和各 Zone Unit 落点示意
资源池指定各 Zone 的 Unit 数量，并引用 Unit 规格；实际 Unit 落在各 Zone 的 OBServer 上。看容量时既要对账配置，也要看节点能不能容纳这些 Unit。
一、租户与资源池先对上号
1. 列出用户租户的基本信息
1-- root@sys2SELECT TENANT_ID, TENANT_NAME, COMPATIBILITY_MODE,3 STATUS, PRIMARY_ZONE, LOCALITY4FROM oceanbase.DBA_OB_TENANTS5WHERE TENANT_TYPE = 'USER'6ORDER BY TENANT_ID;MySQL 和 Oracle 模式的租户都在清单里。PRIMARY_ZONE 反映 Leader 位置偏好，LOCALITY 描述副本布局；它们不是租户的 CPU/内存配额。资源额度继续查资源池和规格。
2. 查看目标租户目前绑定的资源池
1-- root@sys2SELECT t.TENANT_NAME, p.NAME AS POOL_NAME,3 p.UNIT_COUNT, p.UNIT_CONFIG_ID, p.ZONE_LIST4FROM oceanbase.DBA_OB_TENANTS AS t5JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p6 ON p.TENANT_ID = t.TENANT_ID7WHERE t.TENANT_NAME = 'app_tenant'8ORDER BY p.NAME;一个租户可能关联不止一个资源池，不能只取第一行。UNIT_COUNT 是资源池在 Zone 中的 Unit 数量，ZONE_LIST 是资源池覆盖的 Zone；扩容时先分清要加每个 Unit 的规格，还是增加 Unit 个数。
3. 找出尚未分配给租户的资源池
1-- root@sys2SELECT RESOURCE_POOL_ID, NAME, UNIT_COUNT,3 UNIT_CONFIG_ID, ZONE_LIST4FROM oceanbase.DBA_OB_RESOURCE_POOLS5WHERE TENANT_ID IS NULL6ORDER BY NAME;未绑定的资源池与已分配给租户的资源池，修改属性的约束不同。不要把这里的空租户 ID 当成数据异常；创建池后、分配租户前本来就会出现。
4. 查看资源池使用的 Unit 规格
1-- root@sys2SELECT p.NAME AS POOL_NAME, c.NAME AS CONFIG_NAME,3 c.MIN_CPU, c.MAX_CPU,4 c.MEMORY_SIZE, c.LOG_DISK_SIZE5FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p6JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c7 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID8WHERE p.TENANT_ID = 10029ORDER BY p.NAME;MEMORY_SIZE 和 LOG_DISK_SIZE 是字节，CPU 是单个 Unit 的规格；这里还没有乘上各 Zone 的 Unit 个数。改共享的规格前要找出所有引用它的资源池，避免把多个租户一起改了。
5. 查同一个 Unit 规格还被哪些资源池使用
1-- root@sys2SELECT c.NAME AS CONFIG_NAME, p.NAME AS POOL_NAME,3 p.TENANT_ID, p.ZONE_LIST4FROM oceanbase.DBA_OB_UNIT_CONFIGS AS c5JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p6 ON p.UNIT_CONFIG_ID = c.UNIT_CONFIG_ID7WHERE c.NAME = 'unit_app_4c'8ORDER BY p.NAME;多行意味着同一规格可能影响多个资源池甚至多个租户。直接修改 unit_app_4c 的 CPU 或内存，会改变所有引用它的池；扩容方案要先决定是否创建独立规格。
二、Unit 实际落在哪台 OBServer
6. 查看目标租户的 Unit 分布
1-- root@sys2SELECT TENANT_ID, UNIT_ID, ZONE,3 SVR_IP, SVR_PORT, STATUS4FROM oceanbase.GV$OB_UNITS5WHERE TENANT_ID = 10026ORDER BY ZONE, SVR_IP, UNIT_ID;资源池说覆盖某几个 Zone，真正的 Unit 还要看这里的 OBServer 落点。STATUS 不是 NORMAL 时，区分正在迁入/迁出与错误状态；计划下线节点时，先把该节点承载的 Unit 查全。
7. 查看每个 Unit 的 CPU 和内存额度
1-- root@sys2SELECT TENANT_ID, UNIT_ID, ZONE, SVR_IP,3 MIN_CPU, MAX_CPU, MEMORY_SIZE4FROM oceanbase.GV$OB_UNITS5WHERE TENANT_ID = 10026ORDER BY ZONE, SVR_IP, UNIT_ID;这是 Unit 的资源额度，不是 CPU 或内存实际用量。看租户性能瓶颈时仍需配合资源消耗指标；扩容前则用它核对每个 Zone 的 Unit 规格是否一致。
8. 查看 Unit 的日志盘额度与已用空间
1-- root@sys2SELECT TENANT_ID, UNIT_ID, ZONE, SVR_IP,3 LOG_DISK_SIZE, LOG_DISK_IN_USE,4 LOG_DISK_SIZE - LOG_DISK_IN_USE AS LOG_DISK_FREE5FROM oceanbase.GV$OB_UNITS6WHERE TENANT_ID = 10027ORDER BY LOG_DISK_FREE, ZONE, UNIT_ID;两列单位都是字节。这里看的是 Unit 的日志盘配额与占用；后续若缩小规格，不能只比目标值和当前用量是否刚好相等，还要为增长和迁移留空间。
三、目标节点还有没有资源
9. 查看 OBServer 的 CPU 与内存剩余额度
1-- root@sys2SELECT SVR_IP, SVR_PORT, ZONE,3 CPU_CAPACITY, CPU_ASSIGNED,4 CPU_CAPACITY - CPU_ASSIGNED AS MIN_CPU_HEADROOM,5 MEM_CAPACITY, MEM_ASSIGNED,6 MEM_CAPACITY - MEM_ASSIGNED AS MEM_HEADROOM_BYTES7FROM oceanbase.GV$OB_SERVERS8ORDER BY ZONE, SVR_IP;CPU_ASSIGNED 是各 Unit MIN_CPU 的总和，不是当前 CPU 使用率；内存两列单位是字节。扩容 Unit 个数或迁移 Unit 时，目标 Zone 中每台候选 OBServer 都要算自己的剩余额度，不能只看整个集群的总和。
10. 查看 OBServer 的日志盘额度与健康度
1-- root@sys2SELECT SVR_IP, ZONE,3 LOG_DISK_CAPACITY, LOG_DISK_ASSIGNED,4 LOG_DISK_IN_USE,5 LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED6 AS LOG_DISK_UNASSIGNED_BYTES,7 DATA_DISK_HEALTH_STATUS8FROM oceanbase.GV$OB_SERVERS9ORDER BY ZONE, SVR_IP;LOG_DISK_ASSIGNED 是所有 Unit 的日志盘配额合计，LOG_DISK_IN_USE 是已用空间，两个口径不能混。数据盘健康状态不是 NORMAL 的节点，先处理磁盘问题，不宜只因额度够就将新 Unit 迁入。
11. 统计租户在各 Zone 的 Unit 个数
1-- root@sys；目标租户 ID 按现场替换2SELECT TENANT_ID, ZONE, COUNT(*) AS UNIT_COUNT3FROM oceanbase.GV$OB_UNITS4WHERE TENANT_ID = 10025GROUP BY TENANT_ID, ZONE6ORDER BY ZONE;租户在每个 Zone 都要有符合规划的 Unit 个数。某个 Zone 数量少，先核对资源池的 Zone 范围、Unit 分配与迁移状态；别用全租户总数掩盖单 Zone 的缺口。
12. 查目标节点已经承载哪些租户的 Unit
1-- root@sys；目标 OBServer 地址按现场替换2SELECT ZONE, SVR_IP, SVR_PORT, TENANT_ID,3 UNIT_ID, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE4FROM oceanbase.GV$OB_UNITS5WHERE SVR_IP = '10.0.0.21'6ORDER BY TENANT_ID, UNIT_ID;下线、迁入或扩容节点时，先把上面的租户清单交给变更方核对。一个节点即使还有空闲配额，也可能已集中承载多个重要租户；容量足够只是迁入条件之一。
13. 汇总每台节点的 Unit 最小 CPU 与内存配额
1-- root@sys；与 GV$OB_SERVERS 的 CPU_ASSIGNED、MEM_ASSIGNED 对照2SELECT SVR_IP, SVR_PORT, ZONE,3 COUNT(*) AS UNIT_COUNT,4 SUM(MIN_CPU) AS SUM_MIN_CPU,5 SUM(MEMORY_SIZE) AS SUM_MEMORY_BYTES6FROM oceanbase.GV$OB_UNITS7GROUP BY SVR_IP, SVR_PORT, ZONE8ORDER BY ZONE, SVR_IP;这里按 Unit 汇总配额，不是节点的实时消耗。它可以和第 9 条的节点已分配额度对照；两边口径或采集时点不一致时，先核对 Unit 是否正在迁移，再判断是否有资源异常。
扩容前把规格和落点算明白
14. 按资源池算每个 Zone 的配置额度
1-- root@sys；UNIT_COUNT 是资源池在每个 Zone 的 Unit 数2SELECT p.NAME AS POOL_NAME, p.ZONE_LIST,3 p.UNIT_COUNT,4 p.UNIT_COUNT * c.MIN_CPU AS MIN_CPU_PER_ZONE,5 p.UNIT_COUNT * c.MAX_CPU AS MAX_CPU_PER_ZONE,6 p.UNIT_COUNT * c.MEMORY_SIZE AS MEM_BYTES_PER_ZONE7FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p8JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c9 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID10WHERE p.TENANT_ID = 100211ORDER BY p.NAME;这是每个 Zone 的配置额度，不是把所有 Zone 加在一起的实际消耗。一个租户有多个资源池时应逐池记录；算扩容影响之前还得看各 Zone 的真实 Unit 分布和目标节点余量。
15. 查看租户 Unit 规格是否混用
1-- root@sys2SELECT TENANT_ID, ZONE,3 MIN(MIN_CPU) AS LOWEST_MIN_CPU,4 MAX(MIN_CPU) AS HIGHEST_MIN_CPU,5 MIN(MEMORY_SIZE) AS LOWEST_MEMORY_BYTES,6 MAX(MEMORY_SIZE) AS HIGHEST_MEMORY_BYTES,7 COUNT(*) AS UNIT_COUNT8FROM oceanbase.GV$OB_UNITS9WHERE TENANT_ID = 100210GROUP BY TENANT_ID, ZONE11ORDER BY ZONE;上下界不同，先对照第 2 条资源池和第 6 条每个 Unit；可能是多个池的合法配置，也可能是规格调整尚未完成。不能因为某一个 Unit 比较大就说整个租户已经扩容。
16. 查看各 Zone 中余量最少的节点
1-- root@sys2SELECT ZONE,3 MIN(CPU_CAPACITY - CPU_ASSIGNED)4 AS LOWEST_MIN_CPU_HEADROOM,5 MIN(MEM_CAPACITY - MEM_ASSIGNED)6 AS LOWEST_MEMORY_HEADROOM_BYTES,7 COUNT(*) AS OBSERVER_COUNT8FROM oceanbase.GV$OB_SERVERS9GROUP BY ZONE10ORDER BY ZONE;集群总余量大，不代表目标 Zone 的每个候选节点都能承接新 Unit。这里先找最紧的 Zone；具体迁入哪台 OBServer，仍要回到第 9、10 条逐节点判断。
17. 找能容纳一份新 Unit 的候选节点
1-- root@sys；Zone 与规格名按变更方案替换2SELECT s.ZONE, s.SVR_IP, s.SVR_PORT,3 s.CPU_CAPACITY - s.CPU_ASSIGNED4 AS MIN_CPU_HEADROOM,5 s.MEM_CAPACITY - s.MEM_ASSIGNED6 AS MEMORY_HEADROOM_BYTES,7 s.LOG_DISK_CAPACITY - s.LOG_DISK_ASSIGNED8 AS LOG_HEADROOM_BYTES9FROM oceanbase.GV$OB_SERVERS AS s10CROSS JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c11WHERE s.ZONE = 'zone1'12 AND c.NAME = 'unit_app_4c'13 AND s.CPU_CAPACITY - s.CPU_ASSIGNED >= c.MIN_CPU14 AND s.MEM_CAPACITY - s.MEM_ASSIGNED >= c.MEMORY_SIZE15 AND s.LOG_DISK_CAPACITY - s.LOG_DISK_ASSIGNED16 >= c.LOG_DISK_SIZE17ORDER BY MIN_CPU_HEADROOM DESC, s.SVR_IP;只是按最小 CPU、内存和日志盘额度初筛，结果不是调度器保证可迁入的名单。还要看节点健康、负载、租户分散度与 Unit 放置约束；规格若被多个池共用，别顺手改原规格。
18. 查看资源池是否仍引用目标规格
1-- root@sys；新规格创建前后都可核对2SELECT c.UNIT_CONFIG_ID, c.NAME AS CONFIG_NAME,3 COUNT(p.RESOURCE_POOL_ID) AS REFERENCING_POOLS4FROM oceanbase.DBA_OB_UNIT_CONFIGS AS c5LEFT JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p6 ON p.UNIT_CONFIG_ID = c.UNIT_CONFIG_ID7WHERE c.NAME IN ('unit_app_4c', 'unit_app_8c')8GROUP BY c.UNIT_CONFIG_ID, c.NAME9ORDER BY c.NAME;新规格 REFERENCING_POOLS=0 时，还没有资源池使用它；旧规格引用数大于一时，改配置会影响多个池。这个计数用于确认变更范围，不表示有多少租户实际用了多少 CPU。
19. 找当前日志盘配额最紧的 Unit
1-- root@sys2SELECT TENANT_ID, UNIT_ID, ZONE,3 SVR_IP, LOG_DISK_SIZE,4 LOG_DISK_IN_USE,5 ROUND(100 * LOG_DISK_IN_USE6 / NULLIF(LOG_DISK_SIZE, 0), 2)7 AS LOG_DISK_USED_PCT8FROM oceanbase.GV$OB_UNITS9WHERE TENANT_ID = 100210ORDER BY LOG_DISK_USED_PCT DESC, ZONE, UNIT_ID;同一个租户的不同 Unit 可能空间占用相差很大，缩规格前应看最紧的一份。这里是 Unit 日志盘占配额比例，不是 OBServer 整块日志盘利用率，也不是未来增长量。
20. 找出不在正常状态的目标租户 Unit
1-- root@sys2SELECT TENANT_ID, UNIT_ID, ZONE,3 SVR_IP, SVR_PORT, STATUS4FROM oceanbase.GV$OB_UNITS5WHERE TENANT_ID = 10026 AND STATUS <> 'NORMAL'7ORDER BY ZONE, UNIT_ID;Unit 正在迁移或状态异常时，前面按节点算出的余量可能很快变化。先确认状态含义和调度任务，再决定是否继续扩容窗口；空结果只说明本次采样没看到异常状态。
21. 查看目标节点的日志盘分配与实际使用差距
1-- root@sys2SELECT SVR_IP, SVR_PORT, ZONE,3 LOG_DISK_CAPACITY,4 LOG_DISK_ASSIGNED,5 LOG_DISK_IN_USE,6 LOG_DISK_ASSIGNED - LOG_DISK_IN_USE7 AS ASSIGNED_BUT_UNUSED_BYTES8FROM oceanbase.GV$OB_SERVERS9WHERE ZONE = 'zone1'10ORDER BY ASSIGNED_BUT_UNUSED_BYTES, SVR_IP;节点可能“配额已分完”，实际文件却没用满；反过来，配额可用也不代表数据盘健康。扩容 Unit 看 LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED，运行风险还要看实际已用和增长趋势，两个口径别混。
22. 缩小日志盘规格前找超过目标值的 Unit
1-- root@sys；目标 10 GiB 只是示例2SELECT TENANT_ID, UNIT_ID, ZONE,3 SVR_IP, LOG_DISK_IN_USE,4 LOG_DISK_SIZE5FROM oceanbase.GV$OB_UNITS6WHERE TENANT_ID = 10027 AND LOG_DISK_IN_USE >= 10 * 1024 * 1024 * 10248ORDER BY LOG_DISK_IN_USE DESC;只要有一份 Unit 已用量碰到目标上限，就不能照计划直接缩到 10 GiB；即使列表为空，也要给增长和迁移留安全余量。数字须从拟定的新规格取，不能照抄示例。
23. 汇总租户各 Zone 已落地的 Unit 额度
1-- root@sys2SELECT TENANT_ID, ZONE,3 COUNT(*) AS LANDED_UNITS,4 SUM(MIN_CPU) AS LANDED_MIN_CPU,5 SUM(MAX_CPU) AS LANDED_MAX_CPU,6 SUM(MEMORY_SIZE) AS LANDED_MEMORY_BYTES7FROM oceanbase.GV$OB_UNITS8WHERE TENANT_ID = 10029GROUP BY TENANT_ID, ZONE10ORDER BY ZONE;第 14 条是资源池规划的每 Zone 配额，这里是当前各 Zone 已落地 Unit 的额度。多个资源池绑定同一租户时，要逐池取得 Unit 映射再做精确对账；租户级汇总不能证明每个池单独符合规划。
先把资源池和 Unit 一一对应
下面仍是 root@sys 的只读检查。租户挂了多个资源池时，单看租户级汇总不够；需要把每个 Unit 所属的资源池、规格和 OBServer 对出来。
24. 查看资源池中每个 Unit 的实际落点
1-- root@sys2SELECT u.RESOURCE_POOL_ID, p.NAME AS POOL_NAME,3 u.UNIT_ID, u.ZONE, u.SVR_IP, u.SVR_PORT,4 u.STATUS5FROM oceanbase.DBA_OB_UNITS AS u6JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p7 ON p.RESOURCE_POOL_ID = u.RESOURCE_POOL_ID8WHERE p.TENANT_ID = 10029ORDER BY p.NAME, u.ZONE, u.UNIT_ID;这一条把资源池配置和 Unit 落点接起来。一个池在每个 Zone 应有 UNIT_COUNT 份 Unit；数量不一致时，先看 Unit 状态和正在执行的调度任务，别马上补建资源。
25. 按资源池和 Zone 核对 Unit 数量
1-- root@sys2SELECT p.NAME AS POOL_NAME, u.ZONE,3 p.UNIT_COUNT AS CONFIGURED_PER_ZONE,4 COUNT(*) AS LANDED_UNITS5FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p6JOIN oceanbase.DBA_OB_UNITS AS u7 ON u.RESOURCE_POOL_ID = p.RESOURCE_POOL_ID8WHERE p.TENANT_ID = 10029GROUP BY p.NAME, u.ZONE, p.UNIT_COUNT10ORDER BY p.NAME, u.ZONE;CONFIGURED_PER_ZONE 是资源池配置，LANDED_UNITS 是当前落地数量。迁移期间短时不一致要结合状态判断；稳定状态仍不一致，再查 Root Service 的调度记录。
26. 查看目标规格的完整资源参数
1-- root@sys2SELECT UNIT_CONFIG_ID, NAME, MIN_CPU, MAX_CPU,3 MEMORY_SIZE, LOG_DISK_SIZE,4 MIN_IOPS, MAX_IOPS, IOPS_WEIGHT5FROM oceanbase.DBA_OB_UNIT_CONFIGS6WHERE NAME = 'unit_app_8c';切换规格不能只比 CPU 和内存。日志盘、IOPS 上下限和权重也会跟着新规格生效；查询不到记录就停止变更，不能临时把名称改成另一个相近规格。
27. 查看各节点当前的 CPU 超卖上限配置
1-- root@sys2SHOW PARAMETERS LIKE 'resource_hard_limit';resource_hard_limit 影响 MAX_CPU 可分配上限，默认值并不等于所有现场都相同。结果应逐节点核对；MIN_CPU 总和仍不能超过节点 CPU_CAPACITY，内存也不支持超卖。
28. 为应用租户创建独立的 8C 资源规格
1-- root@sys；写操作，数值按容量评估结果替换2CREATE RESOURCE UNIT unit_app_8c3 MAX_CPU 8, MIN_CPU 8,4 MEMORY_SIZE '32G',5 MAX_IOPS 10000, MIN_IOPS 10000,6 IOPS_WEIGHT 8,7 LOG_DISK_SIZE '96G';这条只创建规格，不会自动给租户扩容。V4.x 不支持内存超卖，规格也不能超过单节点可分配资源；创建前要用第 9、10、17 条确认每个目标 Zone 都有可承接的节点。
29. 回读新建的 Unit 规格
1-- root@sys2SELECT NAME, MIN_CPU, MAX_CPU, MEMORY_SIZE,3 LOG_DISK_SIZE, MIN_IOPS, MAX_IOPS, IOPS_WEIGHT4FROM oceanbase.DBA_OB_UNIT_CONFIGS5WHERE NAME = 'unit_app_8c';逐列与变更单对照，尤其注意内存和日志盘在视图中以字节显示。值写错时先修改这份尚未被使用的规格，不要带着错误参数继续绑定资源池。
30. 将目标资源池切换到新规格
1-- root@sys；写操作2ALTER RESOURCE POOL app_pool UNIT = 'unit_app_8c';这会改变 app_pool 中所有 Unit 的资源规格。执行前确认该池只属于目标租户，并保证所有落点节点都有余量；命令被接受后还要回读资源池和实际 Unit，不能把返回成功当作调整已经完成。
31. 确认资源池已经引用新规格
1-- root@sys2SELECT p.NAME AS POOL_NAME, c.NAME AS CONFIG_NAME,3 p.UNIT_COUNT, p.ZONE_LIST, p.MODIFY_TIME4FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p5JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c6 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID7WHERE p.NAME = 'app_pool';CONFIG_NAME 应为 unit_app_8c。再回到第 7 条检查每个 Unit 的额度；资源池元数据已经变化，不代表所有节点上的资源调整都已经稳定。
32. 直接调大现有规格的 CPU 和内存
1-- root@sys；写操作，会影响所有引用该规格的资源池2ALTER RESOURCE UNIT unit_app_4c3 MAX_CPU 8, MIN_CPU 8,4 MEMORY_SIZE '32G';只有第 5 条确认影响范围后才能执行。同一规格被多个资源池共用时，这条命令会一起改变它们；需要只扩一个租户时，优先创建独立规格再切换资源池。
33. 回读所有引用旧规格的资源池
1-- root@sys2SELECT p.NAME AS POOL_NAME, p.TENANT_ID,3 c.NAME AS CONFIG_NAME, c.MIN_CPU,4 c.MAX_CPU, c.MEMORY_SIZE5FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p6JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c7 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID8WHERE c.NAME = 'unit_app_4c'9ORDER BY p.TENANT_ID, p.NAME;这一步用来确认实际影响面。如果出现计划外资源池，停止后续操作并复核方案；规格已经修改时，要根据变更记录决定恢复原值还是给目标池切换独立规格。
34. 将租户每个 Zone 的 Unit 数增加到 2
1-- root@sys；写操作，目标值按现场规划替换2ALTER RESOURCE TENANT app_tenant UNIT_NUM = 2;租户正在使用资源池时，调整 UNIT_NUM 应通过 ALTER RESOURCE TENANT。目标值不能超过各 Zone 的 OBServer 数量，同一租户在同一节点最多放一份 Unit；执行前要按最紧的 Zone 计算容量。
35. 扩容后按资源池和 Zone 回读 Unit 数量
1-- root@sys2SELECT p.NAME AS POOL_NAME, u.ZONE,3 COUNT(*) AS LANDED_UNITS,4 GROUP_CONCAT(CONCAT(u.SVR_IP, ':', u.SVR_PORT)5 ORDER BY u.SVR_IP) AS OBSERVERS6FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p7JOIN oceanbase.DBA_OB_UNITS AS u8 ON u.RESOURCE_POOL_ID = p.RESOURCE_POOL_ID9WHERE p.TENANT_ID = 100210GROUP BY p.NAME, u.ZONE11ORDER BY p.NAME, u.ZONE;每个 Zone 的数量应达到变更目标，并分布在不同 OBServer。调度尚未结束时先看 Unit 状态，不要重复执行扩容；落点稳定后再检查节点余量和业务负载。
四、手动迁移 Unit
手动迁移通常用于节点下线前腾空资源，或者修正同一 Zone 内明显不均衡的 Unit 分布。迁移只在同一 Zone 内进行，目标地址填写 OBServer 的 RPC 端口。
36. 查看 sys 租户的自动均衡开关
1-- root@sys2SHOW PARAMETERS LIKE 'enable_rebalance';V4.2.0 以后该参数按租户生效。SYS 租户中的值控制租户间 Unit 均衡；手动迁移前要先记下原值，窗口结束后按原配置恢复。
37. 暂停 sys 租户的自动 Unit 均衡
1-- root@sys；写操作，先记录原值2ALTER SYSTEM SET enable_rebalance = false TENANT = 'SYS';这样可以避免后台均衡与人工迁移同时改 Unit 落点。节点处于永久下线或 DELETING 状态时，系统迁移不受该开关控制，不能把它当作绝对冻结。
38. 确认待迁移 Unit 的当前落点
1-- root@sys2SELECT UNIT_ID, TENANT_ID, RESOURCE_POOL_ID,3 ZONE, SVR_IP, SVR_PORT, STATUS4FROM oceanbase.DBA_OB_UNITS5WHERE UNIT_ID = 1012;正常状态在 DBA_OB_UNITS 中显示为 ACTIVE。先核对 Unit、租户、资源池和 Zone，避免只凭一张旧截图迁错对象。
39. 在同一 Zone 内筛选目标节点
1-- root@sys；规格名与 Zone 按现场替换2SELECT s.SVR_IP, s.SVR_PORT, s.ZONE,3 s.CPU_CAPACITY - s.CPU_ASSIGNED AS CPU_HEADROOM,4 s.MEM_CAPACITY - s.MEM_ASSIGNED AS MEM_HEADROOM,5 s.LOG_DISK_CAPACITY - s.LOG_DISK_ASSIGNED AS LOG_HEADROOM6FROM oceanbase.GV$OB_SERVERS AS s7CROSS JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c8WHERE s.ZONE = 'zone1'9 AND c.NAME = 'unit_app_8c'10 AND s.CPU_CAPACITY - s.CPU_ASSIGNED >= c.MIN_CPU11 AND s.MEM_CAPACITY - s.MEM_ASSIGNED >= c.MEMORY_SIZE12 AND s.LOG_DISK_CAPACITY - s.LOG_DISK_ASSIGNED >= c.LOG_DISK_SIZE13ORDER BY CPU_HEADROOM DESC;这只是容量初筛。目标节点还要检查磁盘健康、业务负载以及同一租户是否已有 Unit，迁移过程也会叠加源端和目标端的网络、IO 流量。
40. 检查目标节点是否已经承载该租户
1-- root@sys2SELECT UNIT_ID, TENANT_ID, ZONE, SVR_IP, STATUS3FROM oceanbase.DBA_OB_UNITS4WHERE TENANT_ID = 10025 AND SVR_IP = '10.0.0.22';同一租户在同一 OBServer 上不能重复放置 Unit。查到记录时换一台候选节点，不要依赖迁移语句报错替你做变更前检查。
41. 发起 Unit 迁移
1-- root@sys；写操作，2882 为示例 RPC 端口2ALTER SYSTEM MIGRATE UNIT = 10123 DESTINATION = '10.0.0.22:2882';目标必须与源 Unit 位于同一 Zone，端口是 RPC 端口而不是 SQL 端口。命令返回成功只表示任务已经提交，后面还要看作业进度和最终落点。
42. 查看这份 Unit 最近的迁移作业
1-- root@sys2SELECT JOB_ID, JOB_TYPE, JOB_STATUS, PROGRESS,3 RESULT_CODE, START_TIME, MODIFY_TIME,4 UNIT_ID, SQL_TEXT5FROM oceanbase.DBA_OB_UNIT_JOBS6WHERE UNIT_ID = 10127ORDER BY START_TIME DESC;INPROGRESS、SUCCESS、FAILED 分别表示执行中、成功和失败。失败时保留 RESULT_CODE、SQL_TEXT 与时间点，再结合 Root Service 日志定位原因。
43. 查看集群中仍在执行的 Unit 作业
1-- root@sys2SELECT JOB_ID, JOB_TYPE, TENANT_ID, UNIT_ID,3 PROGRESS, START_TIME, MODIFY_TIME,4 RS_SVR_IP, RS_SVR_PORT5FROM oceanbase.DBA_OB_UNIT_JOBS6WHERE JOB_STATUS = 'INPROGRESS'7ORDER BY START_TIME;一次只盯目标 Unit 容易漏掉其他并发迁移。窗口内若已有多项作业，先评估网络和 IO 压力，再决定是否继续提交新的迁移。
44. 查看最近失败的 Unit 作业
1-- root@sys2SELECT JOB_ID, JOB_TYPE, TENANT_ID, UNIT_ID,3 RESULT_CODE, EXTRA_INFO, SQL_TEXT,4 START_TIME, MODIFY_TIME5FROM oceanbase.DBA_OB_UNIT_JOBS6WHERE JOB_STATUS = 'FAILED'7ORDER BY MODIFY_TIME DESC8LIMIT 20;不要只根据 FAILED 重跑命令。先看失败码、附加信息和原 SQL，确认容量不足、目标冲突或节点状态等原因已经处理。
45. 从运行视图观察迁入和迁出状态
1-- root@sys2SELECT UNIT_ID, TENANT_ID, ZONE, SVR_IP,3 STATUS, MIN_CPU, MEMORY_SIZE, LOG_DISK_SIZE4FROM oceanbase.GV$OB_UNITS5WHERE UNIT_ID = 10126ORDER BY SVR_IP;迁移期间可能看到 MIGRATING IN 或 MIGRATING OUT。此时节点配额和落点仍在变化，不能据此开始下一个节点下线步骤。
46. 取消尚未完成的 Unit 迁移
1-- root@sys；写操作，仅在确认需要中止时执行2ALTER SYSTEM CANCEL MIGRATE UNIT 1012;取消后仍要等作业进入最终状态，并重新核对 Unit 落点。不要在迁移过程中直接停止源、目标 OBServer 来代替取消操作。
47. 确认 Unit 已稳定落到目标节点
1-- root@sys2SELECT UNIT_ID, TENANT_ID, RESOURCE_POOL_ID,3 ZONE, SVR_IP, SVR_PORT, STATUS4FROM oceanbase.DBA_OB_UNITS5WHERE UNIT_ID = 10126 AND SVR_IP = '10.0.0.22'7 AND STATUS = 'ACTIVE';查到一行才说明元数据中的最终落点符合预期。随后还要确认源节点不再承载该 Unit，并检查目标节点剩余资源。
48. 恢复 sys 租户的自动均衡
1-- root@sys；按窗口前记录的值恢复2ALTER SYSTEM SET enable_rebalance = true TENANT = 'SYS';恢复后再次执行第 36 条回读。若现场原值本来就是 false，不要机械执行本条，应按变更前记录恢复。
五、缩减租户的 Unit 数量
缩容最怕只看当前 CPU 使用率。还要确认每个 Zone 的 Unit 数、要删除的 Unit Group、日志盘占用和缩容后的节点分布。
49. 查看目标租户的均衡与 Transfer 开关
1-- root@sys2SELECT TENANT_NAME, NAME, VALUE3FROM oceanbase.GV$OB_PARAMETERS4WHERE TENANT_NAME = 'app_tenant'5 AND NAME IN ('enable_rebalance', 'enable_transfer')6ORDER BY NAME, SVR_IP;租户扩缩容需要租户内均衡可用。结果要逐节点一致；发现混值时先修正参数下发问题，不要直接执行 UNIT_NUM 变更。
50. 为目标租户开启均衡与 Transfer
1-- root@sys；写操作2ALTER SYSTEM SET enable_rebalance = true TENANT = 'app_tenant';3ALTER SYSTEM SET enable_transfer = true TENANT = 'app_tenant';两项设置立即生效，不需要重启 OBServer。它们会影响租户内的数据均衡，执行前要与业务窗口和迁移流量控制方案一起确认。
51. 查看租户现有的 Unit Group
1-- root@sys2SELECT UNIT_GROUP_ID, COUNT(*) AS UNIT_COUNT,3 GROUP_CONCAT(CONCAT(ZONE, '/', SVR_IP)4 ORDER BY ZONE) AS PLACEMENT5FROM oceanbase.DBA_OB_UNITS6WHERE TENANT_ID = 10027GROUP BY UNIT_GROUP_ID8ORDER BY UNIT_GROUP_ID;一个 Unit Group 对应各 Zone 中成组的 Unit。计划缩容时按组选择删除对象，比随机删一组更容易提前判断对每个节点和业务副本的影响。
52. 查看候选 Unit Group 的具体落点
1-- root@sys2SELECT UNIT_GROUP_ID, UNIT_ID, ZONE,3 SVR_IP, SVR_PORT, STATUS4FROM oceanbase.DBA_OB_UNITS5WHERE TENANT_ID = 10026 AND UNIT_GROUP_ID = 10037ORDER BY ZONE;每个 Zone 都应核对，不要只看其中一台节点。存在 DELETING 或迁移状态时，等当前作业结束后再制定新的缩容动作。
53. 估算删除一组 Unit 后释放的配额
1-- root@sys2SELECT UNIT_GROUP_ID,3 SUM(MIN_CPU) AS RELEASE_MIN_CPU,4 SUM(MEMORY_SIZE) AS RELEASE_MEMORY_BYTES,5 SUM(LOG_DISK_SIZE) AS RELEASE_LOG_BYTES,6 SUM(LOG_DISK_IN_USE) AS CURRENT_LOG_USED_BYTES7FROM oceanbase.GV$OB_UNITS8WHERE TENANT_ID = 10029 AND UNIT_GROUP_ID = 100310GROUP BY UNIT_GROUP_ID;释放的是配额，不等于业务立即少用这么多资源。CURRENT_LOG_USED_BYTES 也要纳入迁移耗时和空间评估，避免选中数据量最重的一组。
54. 找日志盘占用较低的候选 Unit Group
1-- root@sys2SELECT UNIT_GROUP_ID,3 SUM(LOG_DISK_IN_USE) AS LOG_USED_BYTES,4 SUM(LOG_DISK_SIZE) AS LOG_QUOTA_BYTES5FROM oceanbase.GV$OB_UNITS6WHERE TENANT_ID = 10027GROUP BY UNIT_GROUP_ID8ORDER BY LOG_USED_BYTES, UNIT_GROUP_ID;占用较低通常更容易迁完，但它不是唯一选择标准。还要检查 Leader、热点分区、目标 Unit 的承载能力和变更窗口。
55. 指定删除一个 Unit Group 完成缩容
1-- root@sys；写操作，目标数量与组 ID 按方案替换2ALTER RESOURCE TENANT app_tenant3 UNIT_NUM = 1 DELETE UNIT_GROUP = (1003);指定组可以控制缩掉哪一组 Unit；省略 DELETE UNIT_GROUP 时由系统随机选择。执行前要确认新 UNIT_NUM 仍满足可用性和负载要求。
56. 查看缩容产生的 Unit 作业
1-- root@sys2SELECT JOB_ID, JOB_TYPE, JOB_STATUS, PROGRESS,3 TENANT_ID, UNIT_ID, START_TIME, MODIFY_TIME,4 RESULT_CODE, EXTRA_INFO5FROM oceanbase.DBA_OB_UNIT_JOBS6WHERE TENANT_ID = 10027ORDER BY START_TIME DESC8LIMIT 30;缩容涉及数据迁移和 Unit 删除，不能只看 ALTER 返回。所有相关作业进入最终状态后，再做资源回收和下一步节点操作。
57. 查看仍处于删除状态的 Unit
1-- root@sys2SELECT UNIT_GROUP_ID, UNIT_ID, ZONE,3 SVR_IP, STATUS4FROM oceanbase.DBA_OB_UNITS5WHERE TENANT_ID = 10026 AND STATUS = 'DELETING'7ORDER BY UNIT_GROUP_ID, ZONE;有结果说明缩容还没收尾。此时不应删除关联资源池、规格或承载节点，也不要重复提交相同的 UNIT_NUM 变更。
58. 确认缩容后每个 Zone 的 Unit 数
1-- root@sys2SELECT ZONE, COUNT(*) AS UNIT_COUNT3FROM oceanbase.DBA_OB_UNITS4WHERE TENANT_ID = 10025GROUP BY ZONE6ORDER BY ZONE;各 Zone 的数量应与目标 UNIT_NUM 一致。总数正确但单 Zone 不一致，仍不能算缩容完成。
59. 确认资源池记录中的 Unit 数已经更新
1-- root@sys2SELECT NAME AS POOL_NAME, TENANT_ID,3 UNIT_COUNT, UNIT_CONFIG_ID, ZONE_LIST,4 MODIFY_TIME5FROM oceanbase.DBA_OB_RESOURCE_POOLS6WHERE TENANT_ID = 10027ORDER BY NAME;资源池元数据、Unit 实际落点和租户记录三处要互相对得上。只查其中一处容易把尚未完成的调度误判为成功。
60. 确认租户记录中的 Unit 数
1-- root@sys2SELECT TENANT_ID, TENANT_NAME, UNIT_NUM,3 STATUS, PRIMARY_ZONE, LOCALITY4FROM oceanbase.DBA_OB_TENANTS5WHERE TENANT_NAME = 'app_tenant';UNIT_NUM 是每个 Zone 的 Unit 数量。把它与第 58、59 条一起保存到变更记录，才能说明配置和实际落点已经一致。
六、做一份能长期用的容量报表
下面这些查询适合放进巡检脚本。它们统计的是资源配额和分布，不等同于租户的实时 CPU、内存利用率。
61. 汇总每个租户的最小 CPU 配额
1-- root@sys2SELECT t.TENANT_ID, t.TENANT_NAME,3 SUM(u.MIN_CPU) AS ALLOCATED_MIN_CPU4FROM oceanbase.DBA_OB_TENANTS AS t5JOIN oceanbase.GV$OB_UNITS AS u6 ON u.TENANT_ID = t.TENANT_ID7WHERE t.TENANT_TYPE = 'USER'8GROUP BY t.TENANT_ID, t.TENANT_NAME9ORDER BY ALLOCATED_MIN_CPU DESC;这是所有 Zone、所有 Unit 的 MIN_CPU 合计。做租户横向对比时还要结合副本布局和 Unit 数，否则不能直接拿它代表单副本业务能力。
62. 汇总每个租户的内存配额
1-- root@sys2SELECT t.TENANT_ID, t.TENANT_NAME,3 SUM(u.MEMORY_SIZE) AS ALLOCATED_MEMORY_BYTES4FROM oceanbase.DBA_OB_TENANTS AS t5JOIN oceanbase.GV$OB_UNITS AS u6 ON u.TENANT_ID = t.TENANT_ID7WHERE t.TENANT_TYPE = 'USER'8GROUP BY t.TENANT_ID, t.TENANT_NAME9ORDER BY ALLOCATED_MEMORY_BYTES DESC;内存不支持超卖，扩容计划应优先关注各 Zone 的物理余量。租户总配额只是盘点口径，不能替代逐节点容量检查。
63. 汇总每个租户的日志盘额度和占用
1-- root@sys2SELECT TENANT_ID,3 SUM(LOG_DISK_SIZE) AS LOG_QUOTA_BYTES,4 SUM(LOG_DISK_IN_USE) AS LOG_USED_BYTES,5 ROUND(100 * SUM(LOG_DISK_IN_USE)6 / NULLIF(SUM(LOG_DISK_SIZE), 0), 2) AS USED_PCT7FROM oceanbase.GV$OB_UNITS8GROUP BY TENANT_ID9ORDER BY USED_PCT DESC;先看比例，再看绝对剩余量和增长速度。小规格 Unit 的高比例与大规格 Unit 的高比例，处置优先级可能不同。
64. 查看各 Zone 已分配的最小 CPU
1-- root@sys2SELECT ZONE, SUM(MIN_CPU) AS ASSIGNED_MIN_CPU,3 SUM(MAX_CPU) AS ASSIGNED_MAX_CPU,4 COUNT(*) AS UNIT_COUNT5FROM oceanbase.GV$OB_UNITS6GROUP BY ZONE7ORDER BY ZONE;Zone 总量适合看资源是否偏斜，但扩容是否可行仍由具体 OBServer 的余量决定。不要拿 Zone 平均值掩盖某台节点已接近上限。
65. 查看各 Zone 的物理 CPU 容量和已分配量
1-- root@sys2SELECT ZONE,3 SUM(CPU_CAPACITY) AS CPU_CAPACITY,4 SUM(CPU_ASSIGNED) AS CPU_ASSIGNED,5 SUM(CPU_CAPACITY - CPU_ASSIGNED) AS CPU_HEADROOM6FROM oceanbase.GV$OB_SERVERS7GROUP BY ZONE8ORDER BY ZONE;这条与第 64 条互相校验。两边差异明显时先看采样时点和正在迁移的 Unit，再判断是否存在资源账目异常。
66. 查看各 Zone 的内存余量
1-- root@sys2SELECT ZONE,3 SUM(MEM_CAPACITY) AS MEM_CAPACITY_BYTES,4 SUM(MEM_ASSIGNED) AS MEM_ASSIGNED_BYTES,5 SUM(MEM_CAPACITY - MEM_ASSIGNED) AS MEM_HEADROOM_BYTES6FROM oceanbase.GV$OB_SERVERS7GROUP BY ZONE8ORDER BY ZONE;扩容方案必须按余量最小的 Zone 设计。三副本集群中，两个 Zone 很宽裕也不能抵消第三个 Zone 放不下新 Unit。
67. 查看各 Zone 的日志盘未分配额度
1-- root@sys2SELECT ZONE,3 SUM(LOG_DISK_CAPACITY) AS LOG_CAPACITY_BYTES,4 SUM(LOG_DISK_ASSIGNED) AS LOG_ASSIGNED_BYTES,5 SUM(LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED)6 AS LOG_UNASSIGNED_BYTES7FROM oceanbase.GV$OB_SERVERS8GROUP BY ZONE9ORDER BY ZONE;这里算的是未分配配额，不是文件系统剩余空间。节点磁盘健康和实际占用仍要另查，不能只凭这一列决定迁入。
68. 找最接近 CPU 配额上限的节点
1-- root@sys2SELECT ZONE, SVR_IP, SVR_PORT,3 CPU_CAPACITY, CPU_ASSIGNED,4 ROUND(100 * CPU_ASSIGNED5 / NULLIF(CPU_CAPACITY, 0), 2) AS CPU_ASSIGNED_PCT6FROM oceanbase.GV$OB_SERVERS7ORDER BY CPU_ASSIGNED_PCT DESC, ZONE, SVR_IP;该比例是 MIN_CPU 配额占比，不是操作系统 CPU 使用率。它适合判断还能不能分配新 Unit，不适合判断业务是否正在消耗 CPU。
69. 找最接近内存配额上限的节点
1-- root@sys2SELECT ZONE, SVR_IP, SVR_PORT,3 MEM_CAPACITY, MEM_ASSIGNED,4 ROUND(100 * MEM_ASSIGNED5 / NULLIF(MEM_CAPACITY, 0), 2) AS MEM_ASSIGNED_PCT6FROM oceanbase.GV$OB_SERVERS7ORDER BY MEM_ASSIGNED_PCT DESC, ZONE, SVR_IP;OceanBase V4.x 不支持内存超卖。接近上限的节点即使实时内存看起来空闲，也不能继续按同一口径分配 Unit。
70. 找日志盘配额最紧的节点
1-- root@sys2SELECT ZONE, SVR_IP, SVR_PORT,3 LOG_DISK_CAPACITY, LOG_DISK_ASSIGNED,4 LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED AS HEADROOM_BYTES5FROM oceanbase.GV$OB_SERVERS6ORDER BY HEADROOM_BYTES, ZONE, SVR_IP;日志盘规格调大时，最紧节点决定整个共享规格能否修改成功。共享规格落在多台机器上，不能只验证一台目标节点。
71. 查看每台节点承载的租户数量
1-- root@sys2SELECT ZONE, SVR_IP, SVR_PORT,3 COUNT(DISTINCT TENANT_ID) AS TENANT_COUNT,4 COUNT(*) AS UNIT_COUNT5FROM oceanbase.GV$OB_UNITS6GROUP BY ZONE, SVR_IP, SVR_PORT7ORDER BY TENANT_COUNT DESC, ZONE, SVR_IP;容量相同的两台节点，承载租户数量和业务重要性可能完全不同。迁入选择还应考虑故障域和关键租户集中度。
72. 找只落在一台节点上的租户和 Zone
1-- root@sys2SELECT TENANT_ID, ZONE,3 COUNT(DISTINCT SVR_IP) AS OBSERVER_COUNT,4 COUNT(*) AS UNIT_COUNT5FROM oceanbase.GV$OB_UNITS6GROUP BY TENANT_ID, ZONE7HAVING COUNT(DISTINCT SVR_IP) = 18ORDER BY TENANT_ID, ZONE;结果不一定是异常，小规格租户的 UNIT_NUM=1 本来就会如此。它提醒你节点维护时这些租户在该 Zone 没有第二个 Unit 落点可选。
73. 找规格配置相同但名称不同的 Unit 规格
1-- root@sys2SELECT MIN(NAME) AS FIRST_NAME,3 GROUP_CONCAT(NAME ORDER BY NAME) AS CONFIG_NAMES,4 COUNT(*) AS CONFIG_COUNT,5 MIN_CPU, MAX_CPU, MEMORY_SIZE,6 LOG_DISK_SIZE, MIN_IOPS, MAX_IOPS, IOPS_WEIGHT7FROM oceanbase.DBA_OB_UNIT_CONFIGS8GROUP BY MIN_CPU, MAX_CPU, MEMORY_SIZE,9 LOG_DISK_SIZE, MIN_IOPS, MAX_IOPS, IOPS_WEIGHT10HAVING COUNT(*) > 111ORDER BY CONFIG_COUNT DESC;同规格多名称会增加运维成本，但不能直接合并。先查引用关系和租户变更计划，再决定哪些规格可以逐步回收。
74. 找没有资源池引用的 Unit 规格
1-- root@sys2SELECT c.UNIT_CONFIG_ID, c.NAME,3 c.MIN_CPU, c.MAX_CPU, c.MEMORY_SIZE4FROM oceanbase.DBA_OB_UNIT_CONFIGS AS c5LEFT JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p6 ON p.UNIT_CONFIG_ID = c.UNIT_CONFIG_ID7WHERE p.RESOURCE_POOL_ID IS NULL8ORDER BY c.NAME;这些规格可能是未使用对象，也可能是下一次变更预先创建的。删除前要核对变更单和命名规范，不能仅凭“当前无引用”判断可以清理。
75. 找尚未绑定租户但已占用资源的资源池
1-- root@sys2SELECT p.RESOURCE_POOL_ID, p.NAME,3 p.UNIT_COUNT, p.ZONE_LIST,4 c.NAME AS CONFIG_NAME5FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p6JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c7 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID8WHERE p.TENANT_ID IS NULL9ORDER BY p.NAME;空闲资源池已经创建 Unit，会占用集群配额。确认不再用于建租户或扩容后，应按流程回收，避免容量报表看起来莫名被占满。
七、资源池和规格的日常维护
76. 创建一份小规格 Unit 定义
1-- root@sys；写操作，规格按资源规划替换2CREATE RESOURCE UNIT unit_app_2c3 MAX_CPU 2, MIN_CPU 2,4 MEMORY_SIZE '8G',5 MAX_IOPS 4096, MIN_IOPS 4096,6 IOPS_WEIGHT 2,7 LOG_DISK_SIZE '24G';创建规格只写入定义，不会立即占用节点资源。真正创建资源池时才按 Zone 和 Unit 数分配资源。
77. 创建覆盖三个 Zone 的资源池
1-- root@sys；写操作2CREATE RESOURCE POOL app_pool_new3 UNIT = 'unit_app_2c',4 UNIT_NUM = 1,5 ZONE_LIST = ('zone1', 'zone2', 'zone3');创建池会实际创建 Unit。每个 Zone 都必须有可承载该规格的 OBServer，同一资源池的多份 Unit 不能落到同一台节点。
78. 回读新资源池的配置
1-- root@sys2SELECT p.RESOURCE_POOL_ID, p.NAME, p.TENANT_ID,3 p.UNIT_COUNT, p.ZONE_LIST,4 c.NAME AS CONFIG_NAME5FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p6JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c7 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID8WHERE p.NAME = 'app_pool_new';新池尚未分给租户时 TENANT_ID 为空。核对名称、规格、Unit 数和 Zone 后，再进入创建或调整租户的独立流程。
79. 查看新资源池生成的 Unit
1-- root@sys2SELECT u.RESOURCE_POOL_ID, u.UNIT_ID, u.ZONE,3 u.SVR_IP, u.SVR_PORT, u.STATUS4FROM oceanbase.DBA_OB_UNITS AS u5JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p6 ON p.RESOURCE_POOL_ID = u.RESOURCE_POOL_ID7WHERE p.NAME = 'app_pool_new'8ORDER BY u.ZONE;每个目标 Zone 应出现一份 ACTIVE Unit。数量、状态或 Zone 不符合预期时，先处理资源分配问题，不要继续把池交给租户。
80. 修改空闲资源池使用的规格
1-- root@sys；写操作，确认 TENANT_ID IS NULL 后执行2ALTER RESOURCE POOL app_pool_new UNIT = 'unit_app_4c';即使资源池未绑定租户，切换规格仍会改变已创建 Unit 的配额。先检查各落点节点余量，再执行并回读实际 Unit。
81. 将空闲资源池增加到每个 Zone 两份 Unit
1-- root@sys；写操作2ALTER RESOURCE POOL app_pool_new UNIT_NUM = 2;仅适用于未被租户使用的资源池；已绑定租户时应使用 ALTER RESOURCE TENANT ... UNIT_NUM。目标值不能超过相关 Zone 的 OBServer 数量。
82. 为资源池增加一个 Zone
1-- root@sys；写操作，一次只调整一个 Zone2ALTER RESOURCE POOL app_pool_new3 ZONE_LIST = ('zone1', 'zone2', 'zone3', 'zone4');新增 Zone 会按当前规格和 UNIT_NUM 分配 Unit。执行前确认新 Zone 的节点数量和容量，完成后检查 Unit 是否全部落地。
83. 从空闲资源池移除一个 Zone
1-- root@sys；写操作，一次只调整一个 Zone2ALTER RESOURCE POOL app_pool_new3 ZONE_LIST = ('zone1', 'zone2', 'zone3');移除 Zone 会回收该 Zone 的 Unit。绑定租户后的 Zone 与副本布局相关，不能把这条当作普通容量清理命令直接套用。
84. 查看资源池最近修改时间
1-- root@sys2SELECT NAME, TENANT_ID, UNIT_COUNT,3 UNIT_CONFIG_ID, ZONE_LIST,4 CREATE_TIME, MODIFY_TIME5FROM oceanbase.DBA_OB_RESOURCE_POOLS6ORDER BY MODIFY_TIME DESC;发现计划外变化时，用时间点去对应变更单和审计记录。时间只说明元数据何时修改，不能证明后台调度何时全部完成。
85. 删除确认未使用的资源池
1-- root@sys；写操作，先确认 TENANT_ID IS NULL2DROP RESOURCE POOL app_pool_new;删除资源池会回收其中的 Unit。执行前保存池配置和 Unit 落点，并确认没有待执行的建租户或扩容计划引用它。
86. 确认资源池已经删除
1-- root@sys2SELECT RESOURCE_POOL_ID, NAME, TENANT_ID3FROM oceanbase.DBA_OB_RESOURCE_POOLS4WHERE NAME = 'app_pool_new';空结果后还要检查对应 Unit 是否消失、节点配额是否释放。不要只凭 DROP 返回成功结束变更记录。
87. 删除没有资源池引用的 Unit 规格
1-- root@sys；写操作2DROP RESOURCE UNIT unit_app_2c;仍被资源池引用的规格不能删除。先执行第 74 条和精确名称查询，确认无引用且没有后续变更计划再清理。
88. 确认 Unit 规格已经删除
1-- root@sys2SELECT UNIT_CONFIG_ID, NAME3FROM oceanbase.DBA_OB_UNIT_CONFIGS4WHERE NAME = 'unit_app_2c';空结果说明规格定义已不存在。节点资源是否释放取决于引用它的资源池和 Unit 是否已先回收，不能把删规格当作释放资源的唯一证据。
八、变更后怎么验收
89. 检查目标租户是否存在异常 Unit 状态
1-- root@sys2SELECT UNIT_ID, UNIT_GROUP_ID, ZONE,3 SVR_IP, STATUS4FROM oceanbase.GV$OB_UNITS5WHERE TENANT_ID = 10026 AND STATUS <> 'NORMAL'7ORDER BY ZONE, UNIT_ID;稳定状态下应为空。若窗口结束前仍有迁入、迁出或错误状态，不能只在工单里写“SQL 执行成功”。
90. 检查目标租户是否仍有 Unit 作业运行
1-- root@sys2SELECT JOB_ID, JOB_TYPE, UNIT_ID,3 PROGRESS, START_TIME, MODIFY_TIME4FROM oceanbase.DBA_OB_UNIT_JOBS5WHERE TENANT_ID = 10026 AND JOB_STATUS = 'INPROGRESS'7ORDER BY START_TIME;空结果只说明当前没有 Unit 作业，还要继续核对落点、资源池和节点余量。存在任务时应等到最终状态再验收。
91. 检查最近一小时失败的 Unit 作业
1-- root@sys2SELECT JOB_ID, JOB_TYPE, UNIT_ID,3 RESULT_CODE, EXTRA_INFO, MODIFY_TIME4FROM oceanbase.DBA_OB_UNIT_JOBS5WHERE TENANT_ID = 10026 AND JOB_STATUS = 'FAILED'7 AND MODIFY_TIME >= NOW() - INTERVAL 1 HOUR8ORDER BY MODIFY_TIME DESC;有失败记录不一定代表最终变更失败，但必须说明失败原因、重试动作和最终成功作业，不能只截最后一条成功结果。
92. 对账资源池配置与实际 Unit 数
1-- root@sys2SELECT p.NAME AS POOL_NAME, p.UNIT_COUNT,3 u.ZONE, COUNT(*) AS ACTUAL_UNITS4FROM oceanbase.DBA_OB_RESOURCE_POOLS AS p5JOIN oceanbase.DBA_OB_UNITS AS u6 ON u.RESOURCE_POOL_ID = p.RESOURCE_POOL_ID7WHERE p.TENANT_ID = 10028GROUP BY p.NAME, p.UNIT_COUNT, u.ZONE9HAVING COUNT(*) <> p.UNIT_COUNT10ORDER BY p.NAME, u.ZONE;稳定后应为空。调度过程中短暂出现不一致并不罕见，所以这条要与 Unit 状态和作业进度一起看。
93. 检查同一租户是否在同一节点落了多份 Unit
1-- root@sys2SELECT TENANT_ID, ZONE, SVR_IP,3 COUNT(*) AS UNIT_COUNT4FROM oceanbase.DBA_OB_UNITS5WHERE TENANT_ID = 10026GROUP BY TENANT_ID, ZONE, SVR_IP7HAVING COUNT(*) > 1;正常规划下一般应为空。查到记录时先确认是否为特殊版本或调度状态，再结合官方限制和作业记录处理，不要直接手工删 Unit。
94. 检查租户各 Zone 的 Unit 规格是否一致
1-- root@sys2SELECT ZONE,3 COUNT(DISTINCT CONCAT(MIN_CPU, '/', MAX_CPU, '/',4 MEMORY_SIZE, '/', LOG_DISK_SIZE))5 AS SPEC_VARIANTS6FROM oceanbase.GV$OB_UNITS7WHERE TENANT_ID = 10028GROUP BY ZONE9HAVING SPEC_VARIANTS > 1;结果需要结合多资源池设计判断。单一资源池租户出现多种规格，通常说明调整未完成或配置需要复核。
95. 检查所有 OBServer 的数据盘健康状态
1-- root@sys2SELECT ZONE, SVR_IP, SVR_PORT,3 DATA_DISK_HEALTH_STATUS4FROM oceanbase.GV$OB_SERVERS5WHERE DATA_DISK_HEALTH_STATUS <> 'NORMAL'6ORDER BY ZONE, SVR_IP;资源变更结束后仍要确认节点健康。容量够但磁盘状态异常的节点，不能算作可靠的目标落点。
96. 重新计算目标节点的资源余量
1-- root@sys2SELECT ZONE, SVR_IP,3 CPU_CAPACITY - CPU_ASSIGNED AS CPU_HEADROOM,4 MEM_CAPACITY - MEM_ASSIGNED AS MEM_HEADROOM_BYTES,5 LOG_DISK_CAPACITY - LOG_DISK_ASSIGNED AS LOG_HEADROOM_BYTES6FROM oceanbase.GV$OB_SERVERS7WHERE SVR_IP IN ('10.0.0.21', '10.0.0.22')8ORDER BY SVR_IP;把变更前后结果放在一起，才能说明资源实际从哪里移到哪里。只记录租户规格变化，无法证明目标节点仍有安全余量。
97. 核对租户、资源池和规格的最终关系
1-- root@sys2SELECT t.TENANT_NAME, p.NAME AS POOL_NAME,3 p.UNIT_COUNT, p.ZONE_LIST,4 c.NAME AS CONFIG_NAME,5 c.MIN_CPU, c.MAX_CPU, c.MEMORY_SIZE,6 c.LOG_DISK_SIZE7FROM oceanbase.DBA_OB_TENANTS AS t8JOIN oceanbase.DBA_OB_RESOURCE_POOLS AS p9 ON p.TENANT_ID = t.TENANT_ID10JOIN oceanbase.DBA_OB_UNIT_CONFIGS AS c11 ON c.UNIT_CONFIG_ID = p.UNIT_CONFIG_ID12WHERE t.TENANT_NAME = 'app_tenant'13ORDER BY p.NAME;这张结果适合放进变更验收单。它说明配置关系，实际落点还要附上下一条查询。
98. 导出目标租户的最终 Unit 落点
1-- root@sys2SELECT UNIT_GROUP_ID, UNIT_ID, ZONE,3 SVR_IP, SVR_PORT, STATUS,4 MIN_CPU, MAX_CPU, MEMORY_SIZE, LOG_DISK_SIZE5FROM oceanbase.GV$OB_UNITS6WHERE TENANT_ID = 10027ORDER BY UNIT_GROUP_ID, ZONE, UNIT_ID;保存完整结果，不要只截一两行。后续容量复盘、节点维护和故障排查都会用到这份基线。
99. 回读与变更有关的均衡参数
1-- root@sys2SELECT TENANT_NAME, SVR_IP, NAME, VALUE3FROM oceanbase.GV$OB_PARAMETERS4WHERE TENANT_NAME IN ('sys', 'app_tenant')5 AND NAME IN ('enable_rebalance', 'enable_transfer')6ORDER BY TENANT_NAME, NAME, SVR_IP;人工暂停过的参数必须恢复到变更前状态。逐节点值不一致时不要关单，先查参数下发和节点状态。
100. 生成一份租户资源验收汇总
1-- root@sys2SELECT t.TENANT_ID, t.TENANT_NAME,3 COUNT(u.UNIT_ID) AS TOTAL_UNITS,4 COUNT(DISTINCT u.ZONE) AS ZONE_COUNT,5 COUNT(DISTINCT u.SVR_IP) AS OBSERVER_COUNT,6 SUM(u.MIN_CPU) AS TOTAL_MIN_CPU,7 SUM(u.MEMORY_SIZE) AS TOTAL_MEMORY_BYTES,8 SUM(u.LOG_DISK_SIZE) AS TOTAL_LOG_QUOTA_BYTES,9 SUM(u.LOG_DISK_IN_USE) AS TOTAL_LOG_USED_BYTES10FROM oceanbase.DBA_OB_TENANTS AS t11JOIN oceanbase.GV$OB_UNITS AS u12 ON u.TENANT_ID = t.TENANT_ID13WHERE t.TENANT_NAME = 'app_tenant'14GROUP BY t.TENANT_ID, t.TENANT_NAME;这条适合做最后的汇总，不代替前面的异常检查。验收至少要同时保留资源关系、Unit 落点、进行中作业、节点余量和参数回读。
总结
OceanBase 租户扩缩容不是改完一个数字就结束。资源池引用哪份规格、每个 Unit 落在哪台 OBServer、各 Zone 是否都有余量、迁移任务是否真正完成，这几项必须一起核对。
建议把只读查询做成日常巡检基线，写操作则按“变更前取证—执行—作业跟踪—配置与落点回读”的顺序留档。遇到容量问题时，先把资源关系查清楚，再决定调规格、加 Unit 还是迁移 Unit。
如果这份清单对你有用，欢迎点赞、收藏并转发给需要维护 OceanBase 的同事。
更多数据库运维专题会继续整理到 ORA100 · DBA100：
微信里也可以搜索小程序 「三笠的百令册」，随时查常用命令。
ORA100 DBA100 数据库命令手册