OBMySQL在处理有较多对象的库时提示timeout，调整interactive_timeout参数后依旧提示timeout

OceanBase 技术问题
,
#1

【 使用环境 】测试环境
【 OB or 其他组件 】obsever
【 使用版本 】4.2.5.3
【问题描述】在使用OMS计划进行数据迁移时，由于目标端已经存在对应的库/表，表对象有6000个左右，期望使用dorp database删除目标库后重建空库以快速完成迁移，租户为3副本每个zone配置大小为2C8G，使用obclient命令行直接连接数据库，第一次执行dorp database时，等待一会提示timeout，查看参数interactive_timeout值为28800，修改该参数值为31536000后重新执行drop database依然提示timeout。最后通过拼接语句生产dorp table的sql语句脚本分批删表完成迁移，删除表的sql运行时间约每张表1s左右。
问题：
1.OB数据库在处理有较多对象时性能受哪些因素影响?(obmysql的某个库有较多表，oboracle某用户下有较多表的情况)
2.是租户配置资源影响了drop database性能吗?
3.再遇到该种情况该如何快速实现对目标端的重建(不能删租户)
@论坛小助手

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

2 个赞
#3

根据您的描述，当您在处理包含大量对象的数据库时遇到了超时问题，即便已经调整了 interactive_timeout 参数。这可能涉及到多个方面的因素，包括但不限于系统资源限制、租户配置、以及具体的数据库操作效率等。针对您提到的问题，可以尝试通过 obdiag 工具来进一步诊断。

推荐使用的 obdiag 工具命令

日志采集场景:

  • SQL性能问题
  • 日志采集命令:
    obdiag gather scene run --scene=observer.perf_sql --env "{db_connect='-h127.0.0.1 -P2881 -utest@test -p****** -Dtest', trace_id='Yxx'}"
    请将 db_connect 中的内容替换为您实际的连接信息，并确保使用正确的 trace_id，这可以通过在执行 SQL 时开启跟踪来获得。

建议

  • 使用上述命令收集有关 SQL 性能的详细日志，这将有助于我们分析具体的原因，例如是否有锁争用、资源竞争等问题。
  • 将收集到的日志压缩包发送给我们，我们将基于日志进行更深入的分析。

为了能够更准确地定位问题并给出解决方案，请您提供以下信息：

  1. 数据库中对象的具体类型（如表、视图、存储过程等）及其数量分布情况，了解对象的种类是否对性能有特殊影响。
  2. 当前租户配置的详细信息，特别是与资源分配相关的设置（如内存、CPU 核数等），这有助于评估资源是否充足。
  3. 执行 drop database 操作前后的系统负载情况，包括 CPU、内存、I/O 等指标的变化，这可以帮助判断是否因为资源紧张导致操作超时。
  4. 是否尝试过其他优化措施，如增加租户资源、调整 SQL 语句或参数等，如果有的话，这些措施的效果如何？
  5. 是否有任何特定的业务场景或操作触发了这个问题，了解背景信息对诊断非常重要。

希望这些信息能够帮助我们更快地找到问题的根源，并提供有效的解决方案。如果您还有其他疑问或需要进一步的帮助，请随时告知。

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

1 个赞
#4

数据库中对象的具体类型：6093张表，8张视图
当前租户配置的详细信息：2C8G
执行 drop database 操作前后的系统负载情况：没有其他使用，仅执行drop database
是否尝试过其他优化措施：没有尝试
是否有任何特定的业务场景或操作触发了这个问题：没有特定场景，按需求主动操作

1 个赞
#5

学习一下

#6

sql超时参数是 ob_query_timeout 默认10s

1 个赞
#7

学习了