当前位置：首页 > news >正文

【OceanBase系列】—— 运维实战：从集群状态到SQL性能的常用诊断SQL

news 2026/4/25 17:20:58

1. OceanBase运维实战：集群与租户健康检查

作为一款企业级分布式数据库，OceanBase的稳定运行离不开日常的健康检查。我见过太多因为忽视基础检查而导致的故障案例，这里分享几个最实用的诊断SQL，帮你快速掌握集群脉搏。

先看集群基本信息，这是运维的起点。执行show variables like 'version_comment'能立即获取当前OceanBase版本，这个命令简单但关键，不同版本的特性差异很大。记得有次升级后性能异常，就是靠这个命令发现测试环境版本与生产环境不一致。

集群拓扑检查更重要。SELECT * FROM dba_ob_zones会列出所有Zone信息，包括状态、合并版本等。重点关注STATUS字段，正常应该是ACTIVE，如果出现INACTIVE就要警惕了。配合select * from DBA_OB_SERVERS查看各节点状态，我习惯用这个命令做每日巡检，5秒就能掌握全局。

租户健康检查是另一重点。这条SQL我用了三年依然实用：

SELECT tenant_id,tenant_name,primary_zone,compatibility_mode FROM oceanbase.__all_tenant;

它能显示所有租户的分布情况和兼容模式。特别是primary_zone字段，能快速定位主副本分布是否均衡。上周就靠它发现某个租户的主副本全集中在同一个机柜，及时避免了单点风险。

内存检查也不能忽视。运行：

select TENANT_ID,SVR_IP,SVR_PORT,HOLD/1024/1024/1024,FREE/1024/1024/1024 from oceanbase.GV$OB_TENANT_MEMORY where tenant_id =1002;

这个命令按GB显示租户内存使用情况，HOLD是已用内存，FREE是剩余内存。当FREE低于总内存的20%时就需要关注了，我设置了个定时任务每小时检查这个指标。

2. 资源与容量精细监控实战

资源监控是保证OceanBase稳定运行的关键。先说CPU资源监控，这个复杂查询我优化过多次：

select t1.name resource_pool_name, t2.`name` unit_config_name, t2.max_cpu, t2.min_cpu, round(t2.memory_size/1024/1024/1024,2) mem_size_gb, round(t2.log_disk_size/1024/1024/1024,2) log_disk_size_gb from __all_resource_pool t1 join __all_unit_config t2 on (t1.unit_config_id=t2.unit_config_id) order by t1.`resource_pool_id`;

它能清晰展示每个资源池的CPU和内存配置，max_cpu和min_cpu的差值过大可能引发资源争抢，这个经验来自去年的一次性能调优。

磁盘空间监控更实用。这个统计租户大小的SQL我几乎每天用：

select t.tenant_name, round(sum(t2.data_size)/1024/1024/1024,2) as data_size_gb, round(sum(t2.required_size)/1024/1024/1024,2) as required_size_gb from dba_ob_tenants t,cdb_ob_table_locations t1,cdb_ob_tablet_replicas t2 where t.tenant_id=t1.tenant_id and t1.svr_ip=t2.svr_ip and t1.tenant_id=t2.tenant_id and t1.ls_id=t2.ls_id and t1.tablet_id=t2.tablet_id group by t.tenant_name;

data_size_gb是实际数据大小，required_size_gb是包含副本的预估空间。当required_size接近磁盘总空间的80%时，就该考虑扩容了。

对于表级空间监控，这个命令帮我们发现了多个大表：

select t1.table_name, round(sum(t2.data_size)/1024/1024/1024,2) as data_size_gb from dba_ob_tenants t,cdb_ob_table_locations t1,cdb_ob_tablet_replicas t2 where t.tenant_name='生产租户' and t1.database_name='核心库' group by t1.table_name order by data_size_gb desc;

去年用这个命令找出了几个可以归档的历史表，直接节省了30%的存储空间。

3. SQL性能分析与优化技巧

SQL性能是DBA最常遇到的问题。先说如何找问题SQL，这个查询是我的首选：

select SQL_ID, avg(ELAPSED_TIME), avg(QUEUE_TIME), count(*) cnt, avg(execute_time) avg_exec_time from v$OB_SQL_AUDIT where tenant_id=1001 and request_time > (time_to_usec(now()) - 3600000000) group by 1 order by avg_exec_time * cnt desc limit 10;

它找出最近1小时内执行耗时最长的TOP10 SQL，按总耗时排序。avg_exec_time是平均执行时间，cnt是执行次数，两者乘积能真实反映SQL对系统的整体影响。

拿到SQL_ID后，用这个命令看详细执行计划：

select * from GV$OB_PLAN_CACHE_PLAN_STAT where sql_id='刚才查到的SQL_ID';

重点关注EXECUTIONS（执行次数）、DISK_READS（物理读）、ELAPSED_TIME（总耗时）这几个字段。物理读过多的SQL通常需要优化索引。

对于执行计划的分析，这个Hint技巧很实用：

SELECT /*+ INDEX(表名 索引名) */ * FROM 表名 WHERE 条件;

强制使用指定索引，可以用来验证索引效果。但要注意这只是临时方案，长期还是应该优化统计信息。

慢SQL实时监控也很重要。我部署了这个查询作为定时任务：

select SQL_ID, substr(query_sql, 1, 200) as query_sql, sum(elapsed_time - queue_time) sum_t, count(*) cnt from oceanbase.gv$ob_sql_audit where tenant_id = 1001 and request_time > (time_to_usec(now()) - 60000000) and elapsed_time > 1000000 group by sql_id order by sum_t desc;

它监控过去1分钟内执行时间超过1秒的SQL，按CPU总耗时排序。queue_time是等待时间，elapsed_time - queue_time才是实际消耗的CPU时间。

4. 高级诊断与运维技巧

日志流监控是分布式数据库特有的。这个查询我用来检查LS健康状态：

select svr_ip,svr_port,tenant_id,ls_id,ls_state,tablet_count from __all_virtual_ls_info where ls_state != 'NORMAL';

任何非NORMAL状态的日志流都需要立即检查。tablet_count字段还能看出数据分布是否均衡。

对于DDL操作监控，这个命令帮我们定位过多次卡住的问题：

select * from oceanbase.gv$session_longops where opname like '%CREATE INDEX%' order by elapsed_seconds desc;

elapsed_seconds显示已执行时间，message字段包含详细进度。上周一个建索引任务卡住，就是用这个命令发现是在排序阶段停滞。

最后分享一个自增列监控技巧：

select a.table_name,b.AUTO_INCREMENT_VALUE from oceanbase.__all_table a, oceanbase.DBA_OB_AUTO_INCREMENT b where a.table_id=b.AUTO_INCREMENT_KEY and a.autoinc_column_id=b.COLUMN_ID and a.TABLE_NAME='重要表名';

AUTO_INCREMENT_VALUE显示下一个自增值，接近最大值时需要及时处理。我们曾因此避免了多次主键溢出事故。

查看全文

http://www.jsqmd.com/news/698986/