TRUNCATE慢

【 使用环境 】生产环境
【 OB or 其他组件 】OB
【 使用版本 】4.2.1.7
【问题描述】truncate慢,非分区表,可以从那些方面排查
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接(右键跳转查看):

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

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

3 个赞

根因分析场景: DDL过程中报磁盘空间不足的问题 (如果有疑问,可以先排查是否由于磁盘空间不足导致的缓慢)
根因分析命令: obdiag rca run --scene=ddl_disk_full
日志采集场景: 合并问题
日志采集命令: obdiag gather scene run --scene=observer.compaction

推荐使用 obdiag 工具进行根因分析和日志采集,并且将采集到的日志提供给我们以便确认问题所在。obdiag rca run --scene=ddl_disk_full 用于排查 TRUNCATE 操作中是否存在磁盘空间不足的问题,而 obdiag gather scene run --scene=observer.compaction 可以收集与合并相关的日志信息,因为 TRUNCATE 操作可能会触发底层的合并操作。

麻烦您提供一些信息以便我们更好地帮助您:(下面提出几个问题)

  1. 在执行 TRUNCATE 操作时,是否有其他大事务或者 DML 操作同时在运行?
  2. 是否观察到服务器的 IO 使用率或者 CPU 使用率有异常升高?
  3. 能否提供执行 TRUNCATE 操作的具体表名以及该表的数据量大小?
  4. 是否方便提供通过上述命令采集到的日志压缩包?

附上敏捷诊断工具 obdiag 使用帮助链接

3 个赞

deepseek生

1 个赞

truncate慢的问题,可以尝试升级到ob-4.2.1bp10及以上版本解决;
具体分析,可以看下truncate慢时集群的负载,io是否达到瓶颈,可以手动合并一次对比耗时有无变化。
再提供下集群架构和执行耗时

负载正常,只是truncate慢的表,每天会定时truncate然后在写入数据

根据您的描述,TRUNCATE 操作变慢可能与表的使用模式有关。以下是一些可能的原因和排查建议:

1. 检查是否存在未完成的事务

  • 如果该表上有未提交的事务(例如长时间运行的 SELECT FOR UPDATE 或者其他 DML 操作),可能会导致 TRUNCATE 操作被阻塞。
  • 排查方法:可以通过查询 (G)V$OB_LOCK_WAIT(G)V$OB_TRANSACTION 视图来检查是否有锁等待或者未提交的事务。
SELECT * FROM gv$ob_lock_wait WHERE table_id = (SELECT object_id FROM oceanbase.__all_table WHERE table_name = 'your_table_name');
SELECT * FROM gv$ob_transaction WHERE status = 'ACTIVE';

2. 检查是否触发了合并操作

  • 在 OceanBase 数据库中,TRUNCATE 操作可能会触发底层的合并操作(Minor Freeze 或 Major Freeze)。如果表的数据量较大,或者存在大量删除标记的数据,可能会导致合并操作耗时较长。
  • 排查方法:可以通过查询 (G)V$OB_MAJOR_COMPACTION(G)V$OB_MINOR_COMPACTION 视图来检查是否有正在进行的合并操作。
SELECT * FROM gv$ob_major_compaction WHERE tenant_id = (SELECT tenant_id FROM oceanbase.__all_tenant WHERE tenant_name = 'your_tenant_name');
SELECT * FROM gv$ob_minor_compaction WHERE tenant_id = (SELECT tenant_id FROM oceanbase.__all_tenant WHERE tenant_name = 'your_tenant_name');

3. 检查表的存储特性

  • 如果该表每天都会被定时 TRUNCATE 并重新写入数据,可能会导致表的高水位(HWM)无法及时回收,从而影响后续的 TRUNCATE 操作。

  • 优化建议

    • 调整租户的合并参数,例如 freeze_trigger_percentageminor_freeze_times,以加快合并速度。
    • 手动触发合并操作,确保删除标记的数据能够及时物理删除。
    ALTER SYSTEM MAJOR FREEZE;
    

4. 检查系统参数配置

  • 系统参数配置不当也可能导致 TRUNCATE 操作变慢。例如,cpu_quota_concurrency 参数设置过低,可能会限制可用线程的数量,从而影响操作性能。

  • 排查方法:检查相关参数的配置。

    SHOW PARAMETERS LIKE 'cpu_quota_concurrency';
    

5. 检查日志文件状态

  • 如果 clog 文件回收较慢,可能会导致磁盘空间不足,从而影响 TRUNCATE 操作。
  • 排查方法:参考文档片段 4 中的描述,检查 clog 文件的状态。
SELECT * FROM gv$ob_clog_stat;

6. 尝试绑定执行计划

  • 如果上述方法均未发现问题,可以尝试通过 CREATE OUTLINE 绑定 TRUNCATE 操作的执行计划,确保其每次都使用最优的路径。
CREATE OUTLINE truncate_outline ON TRUNCATE TABLE your_table_name;

总结

根据文档库中的信息,TRUNCATE 操作变慢可能与锁等待、合并操作、系统参数配置等因素有关。建议按照上述步骤逐一排查,并结合实际场景进行优化。如果问题仍未解决,可以提供更多的诊断信息(例如 obdiag 日志)以便进一步分析。

检索到的文档如下:

  1. SQL FAQ
  2. SQL 调优常见问题
  3. Buffer 表
  4. 日志同步问题
  5. DELETE_TABLE_STATS
  6. SQL 查询导致的异常
  7. 节点网卡负载过高
  8. writing_throttling_trigger_percentage
  9. trace_log_slow_query_watermark
  10. SQL 调优典型场景和案例

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

1 个赞

部分表的truncate慢还是所有的truncate慢,或者是整体ddl都慢,慢这个变化有具体出现的时间点吗或者变更点

只是truncate出现在慢SQL监控里, 这只是批量任务,其它业务没问题

是不是进入 large查询了 。

trucate 慢 是否加并行了 。
truncate操作可以加并行的


https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000002013757

没有,这些参数都没有调整,

尝试打开trace跟踪 。 或者ocp 里面能不能看到这个sql , 看看trace-id 看下 observer的日志里面有没有这个trace-id