truncate分区耗时问题始终无法解决

OceanBase 技术问题
#22

老师，参数查到了。

  • schema_history_expire_time 目前设置的是1d
  • schema_history_recycle_interval 目前设置的是20m

您这边建议设置为多大

1 个赞
#23

老师，您说的第三条建议，其中有一个参数叫trace_id。查阅资料发现需要通过gv$sql_audit查询。
sql语句：select * from gv$sql_audit;报错表gv$sql_audit不存在。。。

1 个赞
#24

一般情况下 系统设置的都是默认最佳值 你可以根据当前的情况 考量设置
这个时间是多版本记录回收任务的时间间隔 你自己设置看看 记住默认值
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000000220464

#25

1、执行语句
ALTER TABLET HisPosition Truncate PARTITION D20240813;
2、查询trace_id
select last_trace_id();
3、执行obdiag收集信息
obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-hxx -Pxx -uxx -pxx -Dxx’, trace_id=‘xx’}”
4、收集报告上传到帖子上

#26

老师，我的操作是首先在一个obclient中输入命令
alter table THisPosition truncate partition D20240813；

然后又开了一个obclient，执行select last_trace_id()；发现traceid会变化，就是不止一个tradeid，这样的话咋整

#27

这种方式只能在一个窗口执行 truncate语句生产环境执行需谨慎
如果执行时间长 执行完 你查询诊断信息 获取trace_id 在用obdiag收集信息
select TRACE_ID from oceanbase.gv$ob_sql_audit where QUERY_SQL like ‘%alter table THisPosition truncate partition D20240813%’;

#29

敏感信息 尽量脱敏发出来

#30

obdiag收集出来信息了么？

#31

老师，gather的结果发给您
obdiag_gather_pack_20240816164034.7z (1.9 MB)

执行gather后，有如下的提示信息
[ERROR] plan explain> explain extended alter table THisPosition TRUNCATE PARTITION D20240813
[ERROR] ProgrammingError(1064, “You have an error in your SQL syntax; check the manual that corresponds to your OceanBase version for the right syntax to use near ‘alter table THisPosition TRUNCATE PARTITION D20240813’ at line 1”)
table count ((‘THisPosition’, 4805057),)
data size ((‘127.0.0.1’, ‘LEADER’, 2090836),)

#32

还有一个问题，为什么在obclient执行显示花费了 12min 26.136sec。为啥这个结果里头显示只花了276s

#33

没事 不支持ddl的expaln 这个没事

#34

我也问了相关的同学 结论：分区表包含全局索引，即使你删除了一个没有数据的分区，和数据量、schema等有关系，重建全局索引是非常耗时的，整个 DDL 的耗时可能会超过预期，甚至超时，不同的表的消耗的时间也是不一样 不建议有压力的时候清理数据

#35

sys租户才3c2G ，太抠了。 改到 5C10G 后再对比观察一下。如果资源不够，就从业务租户里抠一点出来 :smile:

#36

老师，这忙活半天，意思是解决不了吗

#37

老师，看了一下文档。请问这两个值，是越小，ObServer的执行效率越高？

#38

分区表有全局索引，执行truncate操作，会导致全局索引失效，需要重建全局索引，Oracle也是这样，只是oceanbase mysql模式下是自动重建全局索引

#39

老师，那这个问题客观存在的情况下，我们如何优化。
业务租户分了23C
sys租户分了3C，这个也有影响吗
上边有老师提到这个问题

另外，这两个值是越小越好吗？阅读了一下文档，schema_history_recycle_interval设置为0，是可以关掉schema保存历史数据的功能的。
schema_history_expire_time
schema_history_recycle_interval

#40

老师，客户都是用业务租户登录数据库。sys资源少，也会影响业务租户的性能吗

#41

全局索引重建的问题，这两个参数应该没啥关系，应该就是IO操作，看数据量大小和存储性能咋样

#42

可是淇老师说，跟数据量大小没关系啊，就算truncate一个空表也需要重建全局索引。那意思就是说，我们连优化的空间都没有。有什么建议吗老师，时间确实太长了，十几分钟