TRUNCATE慢

OceanBase 技术问题
#1

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

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

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

3 个赞
#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 个赞
#4

deepseek生

1 个赞
#5

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

#6

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

#7

根据您的描述，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_percentage 和 minor_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 个赞
#8

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

#9

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

#10

是不是进入 large查询了 。

image
image923×580 12.5 KB

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

image
image810×244 4.36 KB

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

#11

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

#12

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

#13

SQL_AUDIT里面根据truncate 的语句找下对应的语句的trace_id,然后根据trace_id过滤一下RS的日志，提供一下RS的日志