表分区后存储容量变小10倍是否正常？

[恩怨似云烟]

【 使用环境 】测试环境
【 OB or 其他组件 】OB
【 使用版本 】5.7.25-OceanBase_CE-v4.0.0.0
【问题描述】清晰明确描述问题
【复现路径】问题出现前后相关操作
【问题现象及影响】单表71个字段8000万数据存储占用查询121G，分区后查看分区大家存储9亿7000万数据占用空间46G，这是正常的吗？

【附件】

[秃蛙]

查看的方法是什么样的？

[恩怨似云烟]

未分区前（查看数据容量121G）
select table_schema as ‘数据库’, table_name as ‘表名’, table_rows as ‘记录数’, truncate(data_length/1024/1024/1024, 2) as ‘数据容量(GB)’,
truncate(index_length/1024/1024/1024, 2) as ‘索引容量(GB)’
from information_schema.tables where table_schema=‘database’ order by table_rows desc, data_length desc;

分区后（根据分区后的数据容量进行累加46G）
select distinct a.object_name,a.subobject_name,a.object_id,b.tablet_id,
truncate(b.data_size/1024/1024/1024, 2) as ‘数据容量(GB)’
from dba_objects a,dba_ob_tablet_replicas b
where a.data_object_id=b.tablet_id
and a.subobject_name is not null and
a.OBJECT_NAME=‘test_table’

[秃蛙]

这两个sql查询不是实时的数据统计大小，正常相同数据量分区和非分区压缩不会有太大差别。

[恩怨似云烟]

分区后导入9亿数据的已经导入进去过了两天了，现在查询一样还是累加40多G。那有没办法知道真实的存储空间占用多少？我这边预估要导30亿的数据。

[秃蛙]

明天我找下对应开发确认下。

[恩怨似云烟]

好的，感谢~

[秃蛙]

select a.svr_ip,a.svr_port,a.tenant_id,b.tenant_name,
CAST(a.data_disk_in_use/1024/1024/1024 as DECIMAL(15,2)) data_disk_use_G,
CAST(a.log_disk_size/1024/1024/1024 as DECIMAL(15,2)) log_disk_size_G,
CAST(a.log_disk_in_use/1024/1024/1024 as DECIMAL(15,2)) log_disk_use_G
from oceanbase.__all_virtual_unit a,oceanbase.dba_ob_tenants b
where a.tenant_id=b.tenant_id;

select * from __all_virtual_disk_stat;

这种方式统计下看看效果。

[恩怨似云烟]

dev_teant租户，每个节点168G，还是不正确哦，最后一张图8千万数据就121G了，9亿分区后的数据只占几十G？ 3个节点的数据都是一样的副本数据吧？

[秃蛙]

按这个图，把9Y分区后的统计查询下看看是什么样的。

[恩怨似云烟]

@恩怨似云烟

未分区前（查看数据容量121G）
select table_schema as ‘数据库’, table_name as ‘表名’, table_rows as ‘记录数’, truncate(data_length/1024/1024/1024, 2) as ‘数据容量(GB)’,
truncate(index_length/1024/1024/1024, 2) as ‘索引容量(GB)’
from information_schema.tables where table_schema=‘database’ order by table_rows desc, data_length desc;

分区后用这个显示null
所以才会用这段代码查询分区后的。
分区后（根据分区后的数据容量进行累加46G）
select distinct a.object_name,a.subobject_name,a.object_id,b.tablet_id,
truncate(b.data_size/1024/1024/1024, 2) as ‘数据容量(GB)’
from dba_objects a,dba_ob_tablet_replicas b
where a.data_object_id=b.tablet_id
and a.subobject_name is not null and
a.OBJECT_NAME=‘test_table’

[恩怨似云烟]

未分区前（查看数据容量121G）
select table_schema as ‘数据库’, table_name as ‘表名’, table_rows as ‘记录数’, truncate(data_length/1024/1024/1024, 2) as ‘数据容量(GB)’,
truncate(index_length/1024/1024/1024, 2) as ‘索引容量(GB)’
from information_schema.tables where table_schema=‘database’ order by table_rows desc, data_length desc;
现在我感觉这SQL统计的是错误的数据容量

[秃蛙]

业务租户执行看下这个：
select sum(size)/1024/1024 from (select DATABASE_NAME,TABLE_NAME,TABLE_ID,PARTITION_NAME,TABLET_ID,ROLE from 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=‘test_zone2’;

[秃蛙]

先执行这个，再执行上面的sql;

用户租户先执行转储合并；
ALTER SYSTEM MINOR FREEZE;

ALTER SYSTEM MAJOR FREEZE;
查看状态为ldle后为合并结束
SELECT * FROM oceanbase.DBA_OB_ZONE_MAJOR_COMPACTION

[恩怨似云烟]

9亿数据的大小（已分区）

8000万数据的大小（未分区）

结果是这样的，单位是M的话9亿47G，8000万20G

[秃蛙]

你再使用这个语句查一下，看下合并完成后数值和之前有差异吗
select table_schema as ‘数据库’,
table_name as ‘表名’,
truncate(data_length/1024/1024/1024, 2) as ‘数据容量(GB)’,
truncate(index_length/1024/1024/1024, 2) as ‘索引容量(GB)’
from information_schema.tables
where table_schema=‘test’;

[恩怨似云烟]

查了后8000万数据的还是显示121G
这两种语句的查询方式哪个结果是正确的？
8000万20G还是8000万121G？

[秃蛙]

内部测试使用的是查看整体容量的sql
SELECT svr_ip,svr_port,total_size/1024/1024/1024 AS total, free_size/1024/1024/1024 AS free,(total_size-free_size)/1024/1024/1024 as used FROM oceanbase.__all_virtual_disk_stat;

我测试100W的数据分区和非分区，合并后容量是一样的。

你2张表的表结构和数据规格是一样的么，正常不会有太大差异。