【 使用环境 】测试环境
【 OB or 其他组件 】OMS 4.2.12
【 使用版本 】OMS 4.2.12
【问题描述】
老师，您好，
我们发现OMS有个任务，经常延时很大，初期，我们是通过扩容内存的方式（增加liboblog.memory_limit & ob2store.serialize_pool_size）处理，但是发现仍然同步非常缓慢，我们将libobcdc.log拿来分析，
日志附件
text (31).log (633.8 KB)
这份新日志信息量很大，揭示了之前内存扩容没有解决问题的真正原因 。让我对比分析：
重大发现：同步链路被海量 TRUNCATE DDL 淹没
1. 日志主体内容：铺天盖地的 TRUNCATE TABLE
整个日志几乎全是同一种操作：
OP_TYPE=OB_DDL_TRUNCATE_TABLE(59)
DDL_STMT=[truncate table bap_etl.etl_xxx]
涉及 degp_pre.bap_etl 库下几十张 ETL 中间表（etl_dm_bi_satp_csfk_* 、etl_bi_satp_* 、etl_plus_dwd_zt_kmye* 等），每隔约 60~130ms 就有一条 TRUNCATE DDL 事务 ，且不断循环重复（同一张表被反复 truncate）。
这是典型的 ETL 调度任务模式 ：每批数据加载前先 TRUNCATE 中间表再灌数。源端业务把 OMS 同步链路当成了"DDL 洪水"的来源。
单线程 DDL 处理成为串行瓶颈
注意所有 handle_tenant_ddl_task_ / handle_ddl_stmt_ 都发生在同一个线程 [54483][CDC-SEQ-TX-HAND] 上，且每个 DDL 事务都要走完整流程：
1parse_ddl_info → handle_trans → get_old_schema_version_(WDIAG 版本回退告警)
2→ handle_stmt → DIRECT_OUTPUT → schema replay → replace_dict_table_meta → commit
每条 TRUNCATE 都要串行地做 schema 增量回放 + 数据字典刷新 。Formatter 线程（Formatter_0~9）也在为这些表反复 init table_schema_info 、check_column_ 。
DDL 在 liboblog 中是全局串行的 ，TRUNCATE 洪水直接把单线程打满，DML 被排在后面，整体吞吐崩塌。这才是"同步很慢"的根因——不是内存，不是 Writer，而是源端 DDL 风暴 。
持续的告警：DDL schema version is reversed
WDAG: DDL schema version is reversed
(ddl_schema_version=1787056023xxxx, tenant_ddl_cur_schema_version=1787060709xxxx)
每条 DDL 事务都报"schema 版本回退"。这是因为积压了 18.5 小时 ：Sequencer 正在处理的是"过去"的 DDL，而租户当前 schema 版本早已远超它。在追平之前，这个告警会一直刷。
根因结论（修正之前的判断）
源端 ETL 作业循环 TRUNCATE 几十张中间表（DDL 风暴）
↓
liboblog 单线程串行处理 DDL + schema 回放
↓
DDL 队列积压 18.5 小时，DML 被饿死
↓
Sequencer 反压（PAUSE_DISPATCH_TO_SEQUENCER）→ Fetcher 暂停
↓
内存堆积（扩容只能缓解，不能根治）→ 同步延迟持续增长
其实，我们不需要同步产生DDL的数据库，但是，我们发现黑名单和白名单都不太生效的样子。
尝试如下配置，好像效果也不明显。
ob2store.collect_ddl=false
【复现路径】问题出现前后相关操作
【附件及日志】推荐使用OceanBase敏捷诊断工具obdiag收集诊断信息,详情参见链接（右键跳转查看）：
【备注】基于 LLM 和开源文档 RAG 的论坛小助手已开放测试，在发帖时输入 [@论坛小助手] 即可召唤小助手，欢迎试用！
