Obdiag

OceanBase 技术问题
#1

【 使用环境 】测试环境
【 OB or 其他组件 】OceabBase_CE 4.2.1.2; Obdiag 2.3.0
【 使用版本 】OceabBase_CE 4.2.1.2; Obdiag 2.3.0
【问题描述】客户的机器上运行执行删除分区 truncate操作非常耗时，因此做了巡检。因为之前没有通过obdiag做过巡检，希望老师帮忙看看我本地生成的巡检文件是否有问题。如果无误的话，将在客户的机器上完成巡检操作。
【复现路径】
obdiag_check_report_observer_2024-08-14-08-51-00.zip (1.9 KB)

【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：

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

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

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

再向您确认几个问题:

  1. 您在执行truncate操作时遇到了具体的耗时情况能否详细描述一下比如耗时多久
  2. 在您的环境中执行truncate操作的表大概有多少数据量
  3. 您提到的巡检是在遇到truncate耗时问题之后进行的是吗
  4. 除了truncate操作之外系统中还有其他正在进行的大规模DML操作吗
#4

1：truncate一张表大概在15min左右。特别说明，我这里的truncate操作是truncate有分区的表。truncate普通表大概在2s左右可以完成。truncate带有分区的表的时间为15min
2：目前我们测试下来，发现truncate分区耗时与分区内的数据量无关。该分区内无数据的时候，也大概需要15min。
3：truncate分区是昨天操作的，我今天做的巡检。
4：确认没有，因为这个数据库是客户刚部署测试性能来的。

#5

根据您提供的信息，您在测试环境中使用 OceanBase CE 4.2.1.2 版本，并使用了 Obdiag 2.3.0 工具进行了巡检。您提到在执行 truncate 分区操作时遇到了耗时较长的问题，具体表现为：

  1. 对于带有分区的表执行 truncate 操作大约需要 15 分钟，而对普通表执行 truncate 操作只需要大约 2 秒。
  2. truncate 分区耗时与分区内的数据量无关，即使分区为空也需要大约 15 分钟。

您还提供了巡检结果，显示巡检结果为“PASS”，没有发现明显的错误信息。

分析建议

1. 确认分区表结构

  • 确认分区表的定义：请检查分区表的定义，包括分区类型（如范围分区、列表分区等）、子分区（如果有）以及是否具有全局索引等特性。
  • 确认分区数量：请确认分区的数量，因为分区越多，可能需要处理的元数据越多，这可能会影响 truncate 操作的耗时。

2. 检查事务状态

  • 检查活动事务：在 sys 租户下，通过视图 oceanbase.GV$OB_TRANSACTION_PARTICIPANTS 查询当前还未结束的事务上下文状态。确保在执行 truncate 操作时，分区上没有活动的事务或查询，这可能会导致 SQL 语句报错或出现异常情况。

3. 检查全局索引

  • 确认全局索引状态：如果您正在使用的分区表具有全局索引，请确保在 truncate 分区时正确使用了 UPDATE GLOBAL INDEXES 关键字来更新全局索引信息。如果未使用该关键字，可能会导致索引处于不可用状态，进而影响 truncate 操作的性能。

4. 考虑并发性

  • 并发执行 truncate：尝试并发执行 truncate 操作，观察是否能够减少总耗时。尽管 truncate 操作本身不涉及数据移动，但在多分区的情况下，同时处理多个分区可能会提高整体效率。

5. 联系技术支持

  • 联系 OceanBase 技术支持：如果以上步骤未能解决问题，建议联系 OceanBase 的技术支持团队，他们可以提供更深入的技术支持和建议。

结论

根据文档库中的信息，执行 truncate 分区操作时需要注意活动事务的状态和全局索引的维护。由于您提到 truncate 操作耗时与分区内的数据量无关，这可能意味着问题出在元数据处理上。建议按照上述建议进行排查，并考虑联系 OceanBase 的技术支持团队以获得进一步的帮助。

具体信息可参考以下文档:

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

#6

老师，我这个巡检文件是我本地做的巡检。不是客户的问题机器上，只是想让咱们这边帮忙看看文件生成的是否无误。无误的话，我会将相同的操作在客户的目标问题机器上再操作一次。。

#7

你好 看着巡检的结果 没有什么问题 具体操作文档 以官方文档为主 看看具体怎么使用

#8

2. 检查事务状态

  • 检查活动事务：在 sys 租户下，通过视图 oceanbase.GV$OB_TRANSACTION_PARTICIPANTS 查询当前还未结束的事务上下文状态。确保在执行 truncate 操作时，分区上没有活动的事务或查询，这可能会导致 SQL 语句报错或出现异常情况。

请问我是直接，root@sys登录ob后，select * from oceanbase.GV$OB_TRANSACTION_PARTICIPANTS 就行了是吧？

3. 检查全局索引

  • 确认全局索引状态：如果您正在使用的分区表具有全局索引，请确保在 truncate 分区时正确使用了 UPDATE GLOBAL INDEXES 关键字来更新全局索引信息。如果未使用该关键字，可能会导致索引处于不可用状态，进而影响 truncate 操作的性能。

请问下第三条是要如何操作，直接 执行 UPDATE GLOBAL INDEXES吗？

#9

obdiag的执行没什么问题，这边发现两个可优化点，一个是数据盘和日志盘目前部署在一个盘上建议分开，避免io瓶颈导致问题；第二个是给core文件预留的空间不够了，建议在10GB，万一出现crash的话可以有足够的空间生成core文件。

此外目前有模块占用内存超过10G可以深入看下，在这里oceanbase.__all_virtual_memory_info

其他的建议优化项目，具体的可以看看报告内的建议信息

#10

老师，我是问第三条 我该怎么操作。。。
“请确保在 truncate 分区时正确使用了 UPDATE GLOBAL INDEXES 关键字来更新全局索引信息”

我们的表创建了1k左右的分区，然后有三个索引。一个GLOBAL的，两个local的

#11

ALTER TABLE LOC_IM_MID_PRES_ADDR_TEST truncate partition P_530 UPDATE GLOBAL INDEXES;
MySQL 模式下，会将对应表的所有全局索引进行重建（删除索引后，重新创建索引）

分区表如果包含全局索引，那么删除分区后，OceanBase 数据库的 MySQL 模式下会自动重建该全局索引。如果数据量很大，重建全局索引是非常耗时的，整个 DDL 的耗时可能会超过预期，甚至超时。

DDL 的超时时间由系统配置项 _ob_ddl_timeout 来控制，默认值为 1000s。

对于分区表，如果经常需要使用 Truncate 分区来清理数据，应建立避免使用全局索引。

#12

渠老师，这个是客户刚执行完sql后的巡检结果，麻烦您看一下。
obdiag_check_report_observer_2024-08-14-16-34-59.zip (1.8 KB)

#14

老师，我们是mysql模式。truncate数据使用的命令是

ALTER TABLE THisPosition TRUNCATE PARTITION 2024-08-13；类似于这样。

您意思是，我们将命令更新为
ALTER TABLE THisPosition TRUNCATE PARTITION 2024-08-13 UPDATE GLOBAL INDEXES;

这样会有一个效率上的提升吗？

#16

老师我再补充一下gather all的结果，log的部分太大上传不了。
obstack2_127.0.0.1_20240814153740.zip (27.7 KB)
perf_127.0.0.1_20240814153742.zip (10.7 KB)
result_summary.txt (2.7 KB)
sysstat_127.0.0.1_20240814153740.zip (40.3 KB)

#17

日志盘和数据盘同盘的问题还是有，这个在生产环境中是不建议的，在大流量环境中会十分影响性能。其他的内核参数部分可以和公司运维商量修改。

#18

老师我刚试了一下，
执行：ALTER TABLE THisPosition TRUNCATE PARTITION 2024-08-13没问题
执行：ALTER TABLE THisPosition TRUNCATE PARTITION 2024-08-13 UPDATE GLOBAL INDEXES;报错，errorcode = 1064，SQLState = 42000，看着是有语法错误。

#19

老师，看了一下好多都是tcp套接字部分的内核参数。tcp的流量会影响数据库性能吗

1 个赞
#20

你看一下 这个文档 这个语法不支持 如果是这样的话 那就是清空数据 全局索引会失效 删除全局索引在重新建了
https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000000207709?back=kb

#21

老师，看了一下，我们这个是oceanbase4.1.2.1ce版本的；update global indexes最高支持到3。这个语法应该是在我们这个版本不支持的。

#22

不好意思 你对文档理解有的问题 给你发文档 是让你看看清空分区数据 都会有全局索引失效的问题 会重新建全局索引 会有性能问题 目前所有的社区版本obmysql模式 都不支持 这个语法