基于湖库一体架构,统一管理结构化、半结构化与非结构化等多模态数据,一个系统承载事务处理、实时分析与 AI 工作负载。
大事务影响小事务的 RT
更新时间:2026-06-10 09:51
问题现象
大事务持续执行提交 redo 日志,小事务执行延迟增加,大压力下可能达到几十秒。
关键诊断信息
触发条件
大事务持续提交 redo,且存在并发小事务。
事前巡检
无 。
事后诊断
发现小事务延迟过长不符合预期,并且日志中可查询到 transaction log sync use too much time 日志,errcode=-4389,相关日志信息如下。
[2023-11-07 18:01:47.464160] WDIAG [STORAGE.TRANS] test_lock (ob_trans_ctx.cpp:235) [42986][T1004_ApplySrv1][T1004][Y0-0000000000000000-0-0] [lt=14][errcode=-4389] transaction log sync use too much time(log_cb={ObTxBaseLogCb:{base_ts:{val:0, v
:0}, log_ts:{val:1699351185971211034, v:0}, lsn:{lsn:260536822466}, submit_ts:1699351206561276}, this:0x7f7b21e866e0, is_inited_:true, trans_id:{txid:1002316}, ls_id:{id:1001}, ctx:0x7f7b21e83ad0, tx_data_guard:{tx_data:NULL}, is_callbacked_:t
rue, is_dynamic_:false, mds_range_:{range_array_.count():0, range_array_:[]}, cb_arg_array_:[{log_type:0x1, arg:null}], first_part_scn_:{val:18446744073709551615, v:3}}, log_sync_used_time=100788994, ctx_lock_wait_time=113889)
问题原因
大事务持续提交 redo,占有事务上下文锁时间过久,clog 日志回调线程由于需要获取事务上下文锁,导致等锁卡住,对于此时的并发的小事务,由于 clog 回调线程已被占用,无法回调,最终导致小事务延迟增加。
问题的风险及影响
小事务执行 RT 时间增加,最长可超过 15s 。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户,对于 SYS 租户无影响。
影响的版本
OceanBase 数据库企业版本 V4.2.1 GA(oceanbase-4.2.1.0-100000182023092722)及之后版本、V4.2.2 GA(oceanbase-4.2.2.0-100000082024011317)及之后版本。
解决方法及规避方式
解决方法:
升级到问题已修复的版本。目前已修复该问题的版本包括 OceanBase 数据库企业版本 V4.2.1 BP4(oceanbase-4.2.1.4-104000062024022914)及之后版本、V4.2.2 BP1(oceanbase-4.2.2.1-101000012024030619)及之后版本。
限制单个大事务写入的并发度以及限制大事务的并发数。
规避方式:
在大事务高压力场景,尽可能避免其他的小事务并发执行,进而规避小事务 RT 受大事务执行影响。