oceanbase 各库，表占用大小，oceanbase4.2.0如何查看

OceanBase 技术问题
#1

【 使用环境 】生产环境 or 测试环境
【 OB or 其他组件 】
【 使用版本 】
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

【SOP系列 22 】——故障诊断第一步(自助诊断和诊断信息收集)

【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！

oceanbase 各库，表占用大小，oceanbase4.2.0如何查看

#4

SELECT sum(size)/1024/1024/1024 FROM (SELECT DATABASE_NAME,TABLE_NAME,TABLE_ID,PARTITION_NAME,TABLET_ID,ROLE
FROM oceanbase.DBA_OB_TABLE_LOCATIONS ) AA full join
(SELECT distinct(TABLET_ID) ,size
FROM oceanbase.GV$OB_SSTABLES ) BB on AA.TABLET_ID=BB.TABLET_ID
WHERE AA.role=‘leader’ and AA.table_name=’${表名}’;

1 个赞
#5

没有 gv$table视图

1 个赞
#6

小助手回答的有问题 按照我发的语句查一下

1 个赞
#7

感谢您的反馈。确实，在 OceanBase 4.2.0 中并没有 gv$table 视图。我们可以使用其他视图来获取表的占用大小信息。以下是具体的步骤和 SQL 语句：

  1. 查看数据库占用大小:

    • 可以通过查询 gv$tenant 视图来获取各个租户（相当于数据库）的占用大小。具体 SQL 语句如下：
      SELECT tenant_name, total_size FROM gv$tenant;

  2. 查看表占用大小:

    • 可以通过查询 gv$part 视图来获取各个表的占用大小。具体 SQL 语句如下：
      SELECT table_schema, table_name, SUM(data_length) AS total_data_length, SUM(index_length) AS total_index_length, SUM(data_free) AS total_data_free
FROM gv$part
WHERE table_schema = 'your_database_name'
GROUP BY table_schema, table_name;

  3. 查看表的详细存储信息:

    • 如果需要更详细的存储信息，可以查询 gv$part 视图，该视图提供了分区级别的存储信息。具体 SQL 语句如下：
      SELECT table_schema, table_name, partition_name, data_length, index_length, data_free
FROM gv$part
WHERE table_schema = 'your_database_name';

这些查询可以帮助您在 OceanBase 4.2.0 中查看各库和表的占用大小。如果您需要进一步的帮助或有其他问题，请随时告知。

参考文档：

检索到的文档如下:

  1. 诊断实践：使用 SQL_PLAN_MONITOR 分析性能问题
  2. 视图概述
  3. 查询物化视图
  4. OceanBase 术语
  5. DROP RESTORE POINT
  6. ASH_REPORT
  7. oceanbase.DBA_OB_TABLEGROUP_PARTITIONS
  8. 使用 OBKV-Table GO 客户端连接集群
  9. V$SQL_PLAN_MONITOR
  10. 删除表组

(小助手的答复已结束，如未能解决您的问题，请继续提问并等待其他同学的回复，谢谢！)

1 个赞
#8

推荐一款神器，诊断工具obdiag 的一键洞察功能，里面能查到各种OB集群的信息，也不需要你记那么多SQL，帮你屏蔽了版本的差异：https://www.oceanbase.com/docs/common-obdiag-cn-1000000001768219

1 个赞
#9

你这个是看整个库吧

看所有的表的每个表的空间有吗

1 个赞
#10

SELECT /*+ query_timeout(30000000) */ a.TENANT_ID, a.DATABASE_NAME,
a.TABLE_NAME, a.TABLE_ID,
sum(case when b.nested_offset = 0 then IFNULL(b.data_block_count+b.index_block_count+b.linked_block_count, 0) * 2 *
1024 * 1024 else IFNULL(b.size, 0) end) /1024.0/1024/1024 as data_size_in_GB
FROM oceanbase.CDB_OB_TABLE_LOCATIONS a inner join oceanbase.__all_virtual_table_mgr b on a.svr_ip = b.svr_ip and a.svr_port=b.svr_port and a.tenant_id = b.tenant_id and a.LS_ID = b.LS_ID and a.TABLET_ID = b.TABLET_ID and a.role =‘LEADER’ and a.tenant_id = ${租户ID}$ and a.DATABASE_NAME=${数据库名}
and b.table_type >= 10 and b.size > 0 group by a.TABLE_ID;

1 个赞
#11

东西是个好东西，可是为啥总是独立搞轮子，不愿意集成进OCP里面。

1 个赞
#12

说说我的的考量吧：

  1. 敏捷诊断工具obdiag 走的是敏捷的路子，敏捷开发，轻量使用；
  2. 并不是所有的用户都用OCP，有OBD部署，systenmd部署、obshell部署，还有的是脚本部署的，所以诊断工具从设计之初就想解除对部署平台的限制。
1 个赞
#13

我是觉得吧，当你用上这种高大上的数据库的时候，你的数据环境已经跟轻量两个字say good bye了。

（轻量我为啥不用RDS 4核8G 100G ESSD）

当你需要Diag的时候，就已经不是一个小白用户了，何必介意别人只用diag而不用OCP管理、OBD部署。

各自考量不同吧，社区就是这点好，自由发挥讨论。

1 个赞
#14

哈哈，各有各的道理，感谢你的建议。

从ob 4.0 发布之后，ob 就想打开轻量化的市场，尤其是社区用户，号称“增强版的mysql”，ob 进入4.0时代，在小型化上是下了苦功夫的。obdiag 初衷是“让诊断变得更快更容易”，最终的形态是想做成傻瓜式的工具，小白也能看得懂，用得明白。你提到的“用上diag 了说明不是小白用户”说明我们目前的diag还不够傻瓜化，还需要更多的迭代来完善。

不止你一个用户提到过和ocp集成的事情，看起来我需要重新考虑考虑这个事情了 :grinning: