运维管理26 分钟阅读
OceanBase 运维命令 100 条
OceanBase 的日常运维和传统单机数据库有明显区别。它不仅需要管理数据库对象和 SQL,还需要同时关注集群、Zone、OBServer、租户、资源单元、资源池、日志流、合并任务以及备份恢复。
2026年7月24日阅读—点赞—收藏—
dba100oceanbase墨力计划
在知识库中专注阅读,并随时返回相关工具与课程
OceanBase 的日常运维和传统单机数据库有明显区别。它不仅需要管理数据库对象和 SQL,还需要同时关注集群、Zone、OBServer、租户、资源单元、资源池、日志流、合并任务以及备份恢复。
OceanBase 的日常运维和传统单机数据库有明显区别。它不仅需要管理数据库对象和 SQL,还需要同时关注集群、Zone、OBServer、租户、资源单元、资源池、日志流、合并任务以及备份恢复。
对于刚接触 OceanBase 的 DBA 来说,最容易出现的问题不是某条 SQL 不会写,而是没有建立起完整的运维视角:在 OceanBase 中,集群是基础设施层,租户是数据库服务层,资源池和 Unit 是资源隔离层。很多看似普通的连接失败、SQL 变慢或磁盘空间异常,最终都可能与租户资源分配、OBServer 状态或者集群合并任务有关。
本文整理了 OceanBase DBA 日常工作中比较实用的 100 条命令,覆盖以下场景:
OceanBase 社区版主要提供 MySQL 兼容模式,系统租户通常使用 root@sys 登录,租户级运维则应连接到具体业务租户。OceanBase 的系统视图大部分位于 oceanbase 数据库下。
本文以 OceanBase 4.x 为基础。不同的小版本可能存在视图字段或语法差异,执行前建议先在测试环境验证。
命令中的集群名、租户名、IP、端口、目录和密码均为示例,需要根据实际环境替换。
标记为“高危”的命令可能停止服务、删除租户或者改变集群状态,生产环境必须谨慎执行。
OceanBase Database Proxy、OBServer 和集群配置通常可以通过 OBD 统一管理。对于使用 OBD 部署的社区版环境,下面这些命令是最基础的运维入口。OBD 官方提供了集群部署、启动、停止、扩容、升级和租户查看等完整命令。
1obd --version用于确认当前服务器安装的 OBD 版本。
1obd cluster list可以查看集群名称、部署状态以及对应组件版本。
1obd cluster display obcluster用于查看集群内 OBServer、OBProxy、Prometheus 等组件的节点地址和运行状态。
1obd cluster start obcluster启动指定集群中的 OceanBase 相关组件。
1obd cluster stop obcluster高危命令。
该命令会停止整个集群,生产环境执行前必须确认业务已经停止访问。
1obd cluster restart obcluster重启集群内所有受 OBD 管理的组件。
生产环境不建议在未分析故障原因的情况下直接执行集群重启。
1obd cluster edit-config obcluster进入集群配置编辑界面。
修改完成后,通常需要执行配置重载或者重启对应组件。
1obd cluster deploy obcluster -c deploy.yaml高危命令。
根据 YAML 配置文件创建新的 OceanBase 集群。
1obd cluster scale_out obcluster -c scale_out.yaml根据扩容配置文件向现有集群增加 OBServer 或其他组件节点。
扩容前需要检查新节点的磁盘、端口、用户、目录、时钟同步和网络连通性。
1obd cluster upgrade obcluster \2 -c oceanbase-ce \3 -V <目标版本>高危命令。
升级前必须核对版本兼容矩阵、备份状态、集群健康状态以及升级路径。
OceanBase 默认常见端口包括:
具体端口仍应以实际部署配置为准。
1obd cluster tenant show obcluster用于查看 OBD 管理集群中的租户列表和连接信息。
1obclient \2 -h 192.168.10.11 \3 -P 2881 \4 -u root@sys \5 -p直接连接指定 OBServer 的系统租户。
系统租户主要用于集群、资源、租户和备份管理,不建议承载业务数据。
1obclient \2 -h 192.168.10.20 \3 -P 2883 \4 -u root@sys#obcluster \5 -p通过 OBProxy 连接时,用户名一般采用:
1用户名@租户名#集群名1obclient \2 -h 192.168.10.20 \3 -P 2883 \4 -u app_user@app_tenant#obcluster \5 -p业务应用通常也应通过 OBProxy 访问 OceanBase,以避免直接依赖某个 OBServer 节点。
1obclient \2 -h 192.168.10.20 \3 -P 2883 \4 -u root@sys#obcluster \5 -p \6 < init.sql适合执行初始化脚本、巡检脚本或者批量 SQL。
1SELECT VERSION();用于确认当前连接节点对应的 OceanBase 数据库版本。
1ps -ef | grep -E 'observer|obproxy' | grep -v grep检查 OBServer 和 OBProxy 进程是否存在。
1ss -lntp | grep -E '2881|2882|2883'可以快速检查 SQL、RPC 和 OBProxy 端口是否正常监听。
1tail -f /home/admin/oceanbase/log/observer.logobserver.log 是排查 OBServer 启动失败、参数问题、内部错误和性能异常的重要日志。
1grep -E 'ERROR|WDIAG|WARN' \2 /home/admin/oceanbase/log/rootservice.log \3 | tail -100RootService 负责租户管理、资源调度、合并、负载均衡等核心管理工作,其日志对集群级故障排查非常重要。
GV$OB_SERVERS 可以查看集群中所有 OBServer 的 CPU、内存、日志盘和数据盘使用情况,是 OceanBase 集群巡检中最重要的视图之一。
1SELECT *2FROM oceanbase.GV$OB_SERVERS\G用于查看每个 OBServer 的地址、Zone、资源容量和磁盘状态。
1SELECT *2FROM oceanbase.DBA_OB_ZONES;重点关注 Zone 的状态、类型和区域分布。
1SELECT2 SVR_IP,3 SVR_PORT,4 ZONE,5 CPU_CAPACITY,6 CPU_ASSIGNED,7 CPU_CAPACITY - CPU_ASSIGNED AS CPU_FREE,8 ROUND(MEM_CAPACITY / 1024 / 1024 / 1024, 2) AS MEM_CAPACITY_GB,9 ROUND(MEM_ASSIGNED / 1024 / 1024 / 1024, 2) AS MEM_ASSIGNED_GB10FROM oceanbase.GV$OB_SERVERS11ORDER BY ZONE, SVR_IP;如果 CPU_ASSIGNED 或 MEM_ASSIGNED 已接近总容量,后续创建租户、扩容 Unit 或资源迁移可能失败。
1SELECT2 SVR_IP,3 SVR_PORT,4 ROUND(DATA_DISK_CAPACITY / 1024 / 1024 / 1024, 2)5 AS DATA_CAPACITY_GB,6 ROUND(DATA_DISK_IN_USE / 1024 / 1024 / 1024, 2)7 AS DATA_USED_GB,8 ROUND(9 DATA_DISK_IN_USE /10 NULLIF(DATA_DISK_CAPACITY, 0) * 100,11 212 ) AS DATA_USED_PCT13FROM oceanbase.GV$OB_SERVERS14ORDER BY DATA_USED_PCT DESC;OceanBase 数据盘空间不足可能影响转储、合并、数据迁移和正常写入。
1SELECT2 SVR_IP,3 SVR_PORT,4 ROUND(LOG_DISK_CAPACITY / 1024 / 1024 / 1024, 2)5 AS LOG_CAPACITY_GB,6 ROUND(LOG_DISK_IN_USE / 1024 / 1024 / 1024, 2)7 AS LOG_USED_GB,8 ROUND(9 LOG_DISK_IN_USE /10 NULLIF(LOG_DISK_CAPACITY, 0) * 100,11 212 ) AS LOG_USED_PCT13FROM oceanbase.GV$OB_SERVERS14ORDER BY LOG_USED_PCT DESC;日志盘空间与 OceanBase 的事务日志、日志流和副本同步直接相关,需要单独监控。
1SELECT2 SVR_IP,3 SVR_PORT,4 ZONE,5 DATA_DISK_HEALTH_STATUS6FROM oceanbase.GV$OB_SERVERS7WHERE DATA_DISK_HEALTH_STATUS <> 'NORMAL';正常情况下,该查询不应返回异常节点。
1pidstat -p "$(pidof observer)" 1适合观察 observer 进程 CPU、上下文切换和运行状态。
1iostat -x 1重点关注:
%utilawaitr_awaitw_awaitaqu-szOceanBase 对磁盘延迟较为敏感,尤其是日志盘和数据盘发生持续高延迟时。
1df -hT除了数据盘,还要检查:
1SELECT *2FROM oceanbase.DBA_OB_ROOTSERVICE_EVENT_HISTORY3LIMIT 100;可以用于排查租户创建、资源调度、Unit 迁移、节点上下线以及合并相关事件。
OceanBase 的租户资源通常由三层对象组成:
1Resource Unit Config2 ↓3Resource Pool4 ↓5Tenant创建租户时,一般先创建 Unit 配置,再创建资源池,最后将资源池分配给租户。
1SELECT *2FROM oceanbase.DBA_OB_TENANTS;在系统租户执行,可以查看当前集群中的用户租户、系统租户和 Meta 租户。
1SELECT2 TENANT_ID,3 TENANT_NAME,4 TENANT_TYPE,5 COMPATIBILITY_MODE,6 STATUS,7 TENANT_ROLE,8 PRIMARY_ZONE,9 LOCALITY10FROM oceanbase.DBA_OB_TENANTS11ORDER BY TENANT_ID;重点关注租户状态、兼容模式、主 Zone 和副本分布。
1SELECT *2FROM oceanbase.DBA_OB_UNIT_CONFIGS;Unit 配置定义单个资源单元可使用的 CPU、内存、IOPS 和日志盘资源。
1SELECT *2FROM oceanbase.DBA_OB_RESOURCE_POOLS;资源池是 Unit 的集合,并最终分配给租户。
1SELECT *2FROM oceanbase.DBA_OB_UNITS;可以查看每个 Unit 当前分配到哪个租户、资源池、Zone 和 OBServer。
1SELECT2 P.RESOURCE_POOL_ID,3 P.NAME AS RESOURCE_POOL_NAME,4 P.TENANT_ID,5 P.UNIT_COUNT,6 C.UNIT_CONFIG_ID,7 C.NAME AS UNIT_CONFIG_NAME,8 C.MAX_CPU,9 ROUND(C.MEMORY_SIZE / 1024 / 1024 / 1024, 2)10 AS MEMORY_GB11FROM oceanbase.DBA_OB_RESOURCE_POOLS P12JOIN oceanbase.DBA_OB_UNIT_CONFIGS C13 ON P.UNIT_CONFIG_ID = C.UNIT_CONFIG_ID14ORDER BY P.RESOURCE_POOL_ID;不同版本的字段名称可能略有差异,执行前可先使用 DESC 查看视图结构。
1CREATE RESOURCE UNIT app_unit2 MAX_CPU = 4,3 MEMORY_SIZE = '8G',4 MAX_IOPS = 10000,5 MIN_IOPS = 5000,6 IOPS_WEIGHT = 1,7 LOG_DISK_SIZE = '20G';Unit 配置决定租户单个 Unit 可使用的资源上限。
1ALTER RESOURCE UNIT app_unit2 MAX_CPU = 8,3 MEMORY_SIZE = '16G';调整 Unit 资源前,需要确认集群 OBServer 是否仍有足够的可分配资源。
1CREATE RESOURCE POOL app_pool2 UNIT = 'app_unit',3 UNIT_NUM = 1,4 ZONE_LIST = ('zone1', 'zone2', 'zone3');资源池中的 Unit 会按照 Zone 分布。
1ALTER RESOURCE POOL app_pool2 UNIT_NUM = 2;增加 UNIT_NUM 可以扩展租户在每个 Zone 中的资源单元数量。
租户是 OceanBase 对外提供数据库服务的基本单位。租户拥有独立的用户、数据库对象、系统变量、资源配额和事务环境。
1CREATE TENANT IF NOT EXISTS app_tenant2 CHARSET = 'utf8mb4',3 PRIMARY_ZONE = 'zone1;zone2;zone3',4 RESOURCE_POOL_LIST = ('app_pool')5SET6 ob_tcp_invited_nodes = '%';创建完成后,可以通过下面的用户名登录:
1root@app_tenant1ALTER TENANT app_tenant2 PRIMARY_ZONE = 'zone2;zone1;zone3';Primary Zone 会影响租户领导副本的优先分布。
1ALTER TENANT app_tenant2 LOCALITY = 'F@zone1,F@zone2,F@zone3';高危配置变更。
Locality 决定租户副本类型和副本分布。修改前必须确认目标 Zone 和资源池能够满足新的副本要求。
1ALTER TENANT app_tenant LOCK;锁定后,该租户的普通用户通常不能正常登录。
1ALTER TENANT app_tenant UNLOCK;用于恢复被锁定租户的登录能力。
1ALTER TENANT app_tenant2SET VARIABLES3 ob_tcp_invited_nodes = '10.0.0.0/8';用于限制允许访问该租户的客户端网段。
修改访问白名单前,应确认 DBA 管理地址不会被误排除。
1SHOW CREATE TENANT app_tenant\G适合核对租户的资源池、Locality、Primary Zone 和系统变量配置。
1DROP TENANT app_tenant;高危命令。
删除租户前应确认:
1DROP TENANT app_tenant PURGE;极高危命令。
PURGE 会跳过回收站保留逻辑,执行后通常无法通过租户回收站恢复。
1DROP RESOURCE POOL app_pool;23DROP RESOURCE UNIT app_unit;必须先确保资源池已经不再分配给任何租户。
删除顺序通常为:
1删除租户2 ↓3删除资源池4 ↓5删除 Unit 配置下面这些命令应在具体业务租户中执行,而不是在 sys 租户执行。
1SHOW TABLES FROM appdb;用于快速查看数据库对象。
1SHOW CREATE TABLE appdb.orders\G可以检查分区、索引、字符集、压缩方式和表属性。
1SHOW INDEX FROM appdb.orders;重点关注:
1SELECT *2FROM oceanbase.DBA_OB_TABLE_SPACE_USAGE3WHERE DATABASE_NAME = 'appdb';DBA_OB_TABLE_SPACE_USAGE 可以查看当前租户中表和索引的空间使用情况。
1SELECT2 DATABASE_NAME,3 TABLE_NAME,4 SIZE5FROM oceanbase.DBA_OB_TABLE_SPACE_USAGE6ORDER BY SIZE DESC7LIMIT 20;适合快速定位大表。
不同版本中 SIZE 的单位和视图字段可能存在差异,应结合当前版本文档确认。
1SELECT2 TABLE_SCHEMA,3 TABLE_NAME,4 TABLE_TYPE,5 ENGINE,6 TABLE_ROWS,7 CREATE_TIME,8 UPDATE_TIME9FROM information_schema.TABLES10WHERE TABLE_SCHEMA = 'appdb'11ORDER BY TABLE_NAME;TABLE_ROWS 通常属于统计估算值,不应直接作为精确行数使用。
1SELECT2 TABLE_SCHEMA,3 TABLE_NAME,4 PARTITION_NAME,5 PARTITION_METHOD,6 PARTITION_EXPRESSION,7 PARTITION_DESCRIPTION,8 TABLE_ROWS9FROM information_schema.PARTITIONS10WHERE TABLE_SCHEMA = 'appdb'11 AND TABLE_NAME = 'orders'12ORDER BY PARTITION_ORDINAL_POSITION;适合检查分区数量、分区表达式和分区边界。
1SELECT *2FROM oceanbase.DBA_OB_TABLE_LOCATIONS3WHERE DATABASE_NAME = 'appdb'4 AND TABLE_NAME = 'orders';可以查看表对应 Tablet、日志流以及副本所在 OBServer。
1ANALYZE TABLE appdb.orders;当表数据发生大幅变化、执行计划明显异常或者索引选择不合理时,可以考虑重新收集统计信息。
1ALTER TABLE appdb.orders2ADD INDEX idx_orders_status(status);在大表上创建索引前,需要评估:
GV$OB_PROCESSLIST 可以从集群维度查看租户会话,GV$OB_TRANSACTION_PARTICIPANTS 可以查看事务参与者及事务上下文。
1SHOW FULL PROCESSLIST;适合快速查看当前连接节点上的用户会话和正在执行的 SQL。
1SELECT *2FROM oceanbase.GV$OB_PROCESSLIST;与 SHOW PROCESSLIST 相比,GV$OB_PROCESSLIST 更适合集群级会话排查。
1SELECT *2FROM oceanbase.GV$OB_PROCESSLIST3WHERE COMMAND <> 'Sleep'4ORDER BY TIME DESC;可以快速筛选正在执行 SQL 的会话。
1SELECT2 SVR_IP,3 SVR_PORT,4 ID,5 USER,6 HOST,7 DB,8 COMMAND,9 TIME,10 STATE,11 INFO12FROM oceanbase.GV$OB_PROCESSLIST13WHERE TIME > 6014ORDER BY TIME DESC;对于长时间运行 SQL,还需要结合 SQL Audit、执行计划和等待情况进一步判断。
1KILL QUERY <SESSION_ID>;适合中止异常查询,但保留客户端连接。
1KILL CONNECTION <SESSION_ID>;执行后客户端连接会断开,未提交事务通常会回滚。
1ALTER SYSTEM KILL SESSION '<SESSION_ID>';部分版本还支持立即终止模式:
1ALTER SYSTEM KILL SESSION '<SESSION_ID>' IMMEDIATE;OceanBase 官方提供了 ALTER SYSTEM KILL SESSION 语法用于终止会话。
1SELECT *2FROM oceanbase.GV$OB_TRANSACTION_PARTICIPANTS;可以查看事务 ID、会话 ID、事务上下文创建时间以及待写入日志大小等信息。
1SELECT2 SVR_IP,3 SVR_PORT,4 TENANT_ID,5 SESSION_ID,6 TX_ID,7 CTX_CREATE_TIME,8 TIMESTAMPDIFF(9 SECOND,10 CTX_CREATE_TIME,11 NOW()12 ) AS TX_SECONDS,13 PENDING_LOG_SIZE14FROM oceanbase.GV$OB_TRANSACTION_PARTICIPANTS15ORDER BY TX_SECONDS DESC;对于长事务,要进一步确认:
1SHOW VARIABLES LIKE 'ob_trx_timeout';ob_trx_timeout 通常以微秒为单位,修改前必须确认单位。
例如,设置事务超时为 120 秒:
1SET SESSION ob_trx_timeout = 120000000;OceanBase 的 SQL Audit 是性能排查的重要入口,它记录 SQL 的执行耗时、CPU 时间、逻辑读、物理读、返回码、Trace ID 和执行文本等信息。相关时间字段通常以微秒为单位。
1SELECT *2FROM oceanbase.GV$OB_LOCK_WAIT_STAT;该视图在部分 OceanBase 版本中可用于查看锁等待关系。
如果当前版本不存在该视图,可以先检查:
1SHOW TABLES2FROM oceanbase3LIKE '%LOCK%';1SELECT *2FROM oceanbase.DBA_OB_DEADLOCK_EVENT_HISTORY;该视图可以用于查询 OceanBase 记录的死锁事件。
1SELECT2 SVR_IP,3 SVR_PORT,4 SQL_ID,5 TRACE_ID,6 ELAPSED_TIME,7 EXECUTE_TIME,8 CPU_TIME,9 RETURN_CODE,10 QUERY_SQL11FROM oceanbase.GV$OB_SQL_AUDIT12WHERE ELAPSED_TIME > 100000013ORDER BY ELAPSED_TIME DESC14LIMIT 20;1000000 微秒等于 1 秒。
1SELECT2 SQL_ID,3 COUNT(*) AS EXECUTIONS,4 ROUND(SUM(ELAPSED_TIME) / 1000000, 2)5 AS TOTAL_SECONDS,6 ROUND(AVG(ELAPSED_TIME) / 1000, 2)7 AS AVG_MS,8 MIN(QUERY_SQL) AS QUERY_SQL9FROM oceanbase.GV$OB_SQL_AUDIT10WHERE IS_INNER_SQL = 011GROUP BY SQL_ID12ORDER BY SUM(ELAPSED_TIME) DESC13LIMIT 20;这类 SQL 比单纯按单次耗时排序更有价值,因为高频、小耗时 SQL 也可能消耗大量集群资源。
1SELECT2 SVR_IP,3 SQL_ID,4 TRACE_ID,5 ROUND(CPU_TIME / 1000, 2) AS CPU_MS,6 ROUND(ELAPSED_TIME / 1000, 2) AS ELAPSED_MS,7 QUERY_SQL8FROM oceanbase.GV$OB_SQL_AUDIT9WHERE IS_INNER_SQL = 010ORDER BY CPU_TIME DESC11LIMIT 20;如果 CPU 时间接近总耗时,通常说明 SQL 主要消耗在计算过程,而不是等待磁盘或网络。
1SELECT2 SQL_ID,3 TRACE_ID,4 LOGICAL_READS,5 ELAPSED_TIME,6 QUERY_SQL7FROM oceanbase.GV$OB_SQL_AUDIT8WHERE IS_INNER_SQL = 09ORDER BY LOGICAL_READS DESC10LIMIT 20;逻辑读高通常意味着扫描的数据块较多,需要重点检查:
1SELECT2 SQL_ID,3 TRACE_ID,4 PHYSICAL_READS,5 ELAPSED_TIME,6 QUERY_SQL7FROM oceanbase.GV$OB_SQL_AUDIT8WHERE IS_INNER_SQL = 09ORDER BY PHYSICAL_READS DESC10LIMIT 20;物理读高可能说明缓存命中率较低或者 SQL 访问了大量冷数据。
1SELECT2 REQUEST_TIME,3 SVR_IP,4 SQL_ID,5 TRACE_ID,6 RETURN_CODE,7 QUERY_SQL8FROM oceanbase.GV$OB_SQL_AUDIT9WHERE RETURN_CODE <> 010ORDER BY REQUEST_TIME DESC11LIMIT 50;RETURN_CODE 是内部返回码,排查时还需要结合客户端错误、observer 日志和 Trace ID。
1SELECT *2FROM oceanbase.GV$OB_SQL_AUDIT3WHERE TRACE_ID = '<TRACE_ID>'\GTrace ID 是串联客户端请求、SQL Audit 和 OBServer 日志的重要标识。
1SELECT2 REQUEST_TIME,3 SVR_IP,4 SVR_PORT,5 TRACE_ID,6 ELAPSED_TIME,7 CPU_TIME,8 LOGICAL_READS,9 PHYSICAL_READS,10 RETURN_CODE,11 QUERY_SQL12FROM oceanbase.GV$OB_SQL_AUDIT13WHERE SQL_ID = '<SQL_ID>'14ORDER BY REQUEST_TIME DESC15LIMIT 100;适合分析同一条 SQL 在不同时间、不同 OBServer 上的性能波动。
1SELECT *2FROM oceanbase.GV$OB_PLAN_CACHE_STAT;用于查看各 OBServer 上租户 Plan Cache 的内存使用和缓存状态。
1SELECT *2FROM oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT3WHERE SQL_ID = '<SQL_ID>'\G可以获取:
1SELECT DBMS_XPLAN.DISPLAY_SQL_PLAN_BASELINE(2 '<SVR_IP>',3 <SVR_PORT>,4 <TENANT_ID>,5 <PLAN_ID>6);不同 OceanBase 小版本的执行计划查看函数和参数可能存在差异,应以当前版本的 DBMS_XPLAN 文档为准。较新的版本通常需要同时提供服务器、租户和计划 ID。
1EXPLAIN2SELECT *3FROM appdb.orders4WHERE status = 1;重点关注:
1SET ob_enable_show_trace = ON;该设置仅对当前会话生效。
1SELECT COUNT(*)2FROM appdb.orders3WHERE status = 1;45SHOW TRACE;SHOW TRACE 可以查看 SQL 在 OceanBase 内部的执行阶段和耗时分布,是分析响应时间的重要工具。
1SHOW PARAMETERS LIKE 'syslog_level';也可以直接查询参数视图:
1SELECT *2FROM oceanbase.GV$OB_PARAMETERS3WHERE NAME = 'syslog_level';1ALTER SYSTEM SET syslog_level = 'WDIAG';开启更详细日志可能明显增加日志量,只应在问题排查期间使用。
排查结束后应及时恢复:
1ALTER SYSTEM SET syslog_level = 'INFO';1ALTER SYSTEM MAJOR FREEZE;高危运维命令。
Major Freeze 会推动集群进入下一轮大版本冻结和合并流程,不建议在集群负载较高、磁盘空间紧张或者正在执行其他重大任务时随意触发。
1SELECT *2FROM oceanbase.DBA_OB_MAJOR_COMPACTION;还可以查看冻结历史:
1SELECT *2FROM oceanbase.DBA_OB_FREEZE_INFO;巡检时应重点关注:
OceanBase 物理备份以租户为单位。执行备份前,通常需要先配置日志归档目的端和数据备份目的端,并启动归档。
1ALTER SYSTEM SET LOG_ARCHIVE_DEST =2'LOCATION=file:///data/obbackup/archive3 BINDING=Optional4 PIECE_SWITCH_INTERVAL=1d'5TENANT = app_tenant;实际环境也可以使用对象存储作为归档介质,具体格式取决于 OceanBase 版本和存储类型。
1ALTER SYSTEM ARCHIVELOG2TENANT = app_tenant;停止日志归档:
1ALTER SYSTEM NOARCHIVELOG2TENANT = app_tenant;启动后必须检查归档状态,不能仅以命令执行成功作为判断依据。
1ALTER SYSTEM SET DATA_BACKUP_DEST =2'file:///data/obbackup/data'3TENANT = app_tenant;备份目录需要满足:
1ALTER SYSTEM BACKUP2TENANT = app_tenant;备份并包含归档日志:
1ALTER SYSTEM BACKUP2TENANT = app_tenant3PLUS ARCHIVELOG;OceanBase 官方支持针对指定租户执行全量或增量备份。
1SELECT *2FROM oceanbase.DBA_OB_ARCHIVELOG;启动备份前,应确认归档状态正常推进,而不是处于停止、异常或卡住状态。
1SELECT *2FROM oceanbase.DBA_OB_BACKUP_JOBS;在系统租户中,也可以查看集群范围的备份任务视图:
1SELECT *2FROM oceanbase.CDB_OB_BACKUP_JOBS;1SELECT *2FROM oceanbase.DBA_OB_BACKUP_TASKS;查看已结束的备份任务:
1SELECT *2FROM oceanbase.DBA_OB_BACKUP_JOB_HISTORY;OceanBase 提供当前任务、任务明细和历史任务等多类备份视图。
1ALTER SYSTEM RESTORE restore_tenant2FROM3'file:///data/obbackup/data,4 file:///data/obbackup/archive'5UNTIL TIME = '2026-07-20 10:00:00'6WITH7'pool_list=restore_pool8&locality=F@zone1,F@zone2,F@zone39&primary_zone=zone1';极高危命令。
恢复前必须确认:
OceanBase 的租户恢复需要指定备份路径、恢复终点以及用于承载恢复租户的资源池。
1CREATE USER 'app_user'@'%'2IDENTIFIED BY 'StrongPassword_2026!';生产环境不建议允许所有来源地址访问,可以限制具体网段:
1CREATE USER 'app_user'@'10.%'2IDENTIFIED BY 'StrongPassword_2026!';1GRANT2 SELECT,3 INSERT,4 UPDATE,5 DELETE6ON appdb.*7TO 'app_user'@'%';查看用户权限:
1SHOW GRANTS2FOR 'app_user'@'%';回收权限:
1REVOKE DELETE2ON appdb.*3FROM 'app_user'@'%';生产环境应遵循最小权限原则,避免直接向业务账号授予:
1GRANT ALL PRIVILEGES ON *.*掌握命令只是第一步。真正遇到 OceanBase 故障时,建议按照从集群到租户、从资源到 SQL 的顺序进行排查。
首先判断是:
故障范围判断错误,后续排查很容易走偏。
优先检查:
1OBServer 是否全部在线2Zone 状态是否正常3CPU 和内存资源是否耗尽4数据盘和日志盘是否接近满载5大合并是否长时间未完成6是否存在资源迁移或副本异常租户异常时重点检查:
1Unit 资源是否充足2资源池分布是否合理3是否存在长事务4是否存在锁等待或死锁5SQL Audit 中是否出现高耗时 SQL6Plan Cache 是否异常7执行计划是否发生变化OceanBase 参数数量较多,但生产问题通常不能仅靠修改参数解决。
尤其不建议在没有明确证据的情况下直接执行:
1重启集群2重启 OBServer3修改租户资源4修改 Locality5手动触发 Major Freeze6提高日志级别后长期不恢复7强制终止大量会话这些操作可能暂时缓解现象,但也可能掩盖真正的问题,甚至扩大故障影响。
OceanBase DBA 与传统 MySQL DBA 最大的区别,是不能只盯着数据库实例和 SQL。OceanBase 是一个原生分布式数据库,日常运维必须同时理解:
1集群2OBServer3Zone4租户5资源池6Unit7副本8日志流9合并10SQL Audit11备份与归档对于刚接触 OceanBase 的 DBA,建议优先掌握以下几个核心入口:
1oceanbase.GV$OB_SERVERS2oceanbase.DBA_OB_ZONES3oceanbase.DBA_OB_TENANTS4oceanbase.DBA_OB_UNITS5oceanbase.DBA_OB_RESOURCE_POOLS6oceanbase.GV$OB_PROCESSLIST7oceanbase.GV$OB_TRANSACTION_PARTICIPANTS8oceanbase.GV$OB_SQL_AUDIT9oceanbase.GV$OB_PLAN_CACHE_PLAN_STAT10oceanbase.DBA_OB_MAJOR_COMPACTION如果这些视图能够熟练使用,绝大多数 OceanBase 日常巡检、租户资源检查、SQL 性能分析和故障定位工作都能够找到较明确的排查方向。
更多 Oracle、MySQL、PostgreSQL、OceanBase DBA 实战内容,可以访问 ora100.com。