【 使用环境 】测试环境
【 OB or 其他组件 】oceanbase 社区版与oms
【 使用版本 】OceanBase_CE 4.3.5.1
【问题描述】用OMS进行数据库迁移割接的时候，附加列删除这个特别耗时
【复现路径】
租户规格是： 16C 48G
直连ob测试：
现在验证的一张表 2亿条，删除1个字段花了50多分钟
4个字段同时删除的一张表 5亿条，执行了6800秒了，还没有完成
目前通过官网得知该操作属于offline ddl，且在4.x版本中，默认是将并行关闭；
参照之前3.x的测试记录是3亿数据删除字段耗时20多分钟；
针对这个版本之间的差异；除了调整ddl的并行度，是否还有别的优化操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
对于您提到的情况，我们可以尝试通过 obdiag 工具来收集日志和执行根因分析，以找出删除附加列操作非常耗时的具体原因。不过从现有的 obdiag 场景来看，可能没有直接针对数据迁移中删除附加列耗时问题的专门场景。但是，我们可以从 SQL 性能和日志归档的角度来进行分析，因为这两个方面可能会对操作耗时产生影响。
推荐使用 obdiag 工具进行日志采集和根因分析：
日志采集场景: SQL性能问题
日志采集命令: obdiag gather scene run --scene=observer.perf_sql --env “{db_connect=’-h<您的数据库IP> -P<您的端口号> -u<您的用户名>@<您的租户名> -p<您的密码> -D<您的数据库名>’, trace_id=’<您的trace_id>’}”
请您替换上述命令中的 <您的数据库IP>、<您的端口号>、<您的用户名>、<您的租户名>、<您的密码> 和 <您的数据库名> 为您实际使用的值。如果不知道 trace_id，可以暂时忽略该参数，但如果有具体发生耗时的事务ID，最好填上。
在您执行完上述命令后，请将生成的日志文件压缩包发送给我们，这将有助于我们进一步分析问题的原因。
另外，为了更准确地定位问题，请您提供以下信息：
这些问题的答案将帮助我们更快地找到解决方案。感谢您的配合！
附上敏捷诊断工具 obdiag 使用帮助链接
麻烦提供下一下oms的版本号 组件监控截图提供一下
数据量越大删除越慢吧
嗯，在3.x中3亿数据量删除，有并发的情况下，耗时20多分钟。4.x默认的并行没了，只有单线程，确实数据量越大，越慢
老师，可以先忽略oms这部分了。直连ob的测试结果就是很慢，想在ob这块做一些优化调整。
如下是测试数据：
直连ob测试：
验证的一张表 2亿条，删除1个字段花了50多分钟
4个字段同时删除的一张表 5亿条，执行了6800秒了，还没有完成
目前通过官网得知该操作属于offline ddl，且在4.x版本中，默认是将并行关闭；
参照之前3.x的测试记录是3亿数据删除字段耗时20多分钟；
自己可以在hint中加入并发 这个是支持的 参考官方文档
https://www.oceanbase.com/docs/common-oceanbase-database-cn-1000000003381296
嗯嗯，看来只能通过手工开启并行来进行oms迁移大表时在进行隐藏列的清理了。
可以手动加一下并行 我记得开启并行 也支持全局变量和session变量的
嗯嗯 灵活变动 找到适合自己的
