问题现象
OBServer 在特定场景下，触发日志报错 -4013 错误码 （OB_ALLOCATE_MEMORY_FAILED），报错关键日志为 ObTransCtx statistics(active_sche_ctx_count=100001。这代表了单台 OBServer 的事务超过了 10w 上限。这个问题有可能是因负载造成的，堆积的活跃事务达到了 10w，就会报错，在此场景下如果积压的活跃事务被及时处理，OBServer 有可能可以自动恢复，报错日志消除。但单台 OBServer 10w 活跃事务已经是有过载（风险），需要进一步监控分析和优化。除了负载造成的问题，已知在 MySQL PL 场景下，Oracle 游标 select udf 场景下会开启事务造成事务超限报错 4013 且 OBServer 无法自动恢复的故障。这两种场景具体如下：
| MySQL mode | Oracle mode | ||
|---|---|---|---|
| 问题引入 | Mysql 低版本的问题，V3.2.4 正式支持 MySQL PL 的能力后不再有该问题。同时为了保障因为历史原因等情况在低版本仍然使用 MySQL PL 能力的用户无故障，对低版本也进行了修复。 | 为了修复 MySQL PL 模式下造成的事务超限问题，引入了 Oracle 模式下游标 select udf 开启事务触发的事务超限问题。 | |
| 问题版本（同分支更高版本修复问题） | V3.2.4： V3.2.4 Hotfix1（oceanbase-3.2.4.0-100010012022110218）以及之前的版本。 V3.2.3： V3.2.3 BP6 Hotfix4（oceanbase-3.2.3.3-106040022022122222）以及之前的版本。 V3.1.2： V3.1.2 BP10 Hotfix（2022.10.27-12.09 的发版），V3.1.2 BP11 （oceanbase-3.1.2-111000052023010412）以及之前的版本。 V2.2.77： V2.2.77 BP14（oceanbase-2.2.77-114000072022120410）及之前的版本。 |
V3.2.4： V3.2.4 Hotfix1（3.2.4.0-100010012022110218）版本。 V3.2.3 ： 无问题。 V3.1.2： V3.1.2 BP10 Hotfix (2022.10.27-12.09 的发版)，V3.1.2 BP11 （oceanbase-3.1.2-111000052023010412） 版本。 V2.2.77： V2.2.77 BP14（oceanbase-2.2.77-114000072022120410）版本。 |
|
关键诊断信息
触发条件
| MySQL mode | Oracle mode | |
|---|---|---|
| 触发场景示例 | MySQL模式下有两种场景触发该问题： 1. MySQL模式下，顶层语句是 select，内部 sql 可以是 select for update。 在这种场景下，内部的 for update 会开启事务。 同时因为顶层 select 语句会走 standalone 逻辑，不开启事务。在父子语句间造成了混淆。当执行栈退出到顶层父语句时，会认为自己在 standalone 语境中，忽略事务，从而造成事务泄露。此类导致事务超限报错 4013。 2. MySQL 模式下的另外一个场景，select 嵌套 select，内层 select 因为执行在 udf 语境下，在 PL 层会把 ac 改为 false，而 MySQL 下 Standalone 的先决条件是 ac=1，因此内层语句不走 standalone，而走了开事务逻辑，同样会泄露，此类导致事务超限报错 4013。 触发场景示例如下：客户环境请在测试环境测试避免造成生产故障。 create table t1(id int); insert into t1 value(1),(2); create table t2(id int); insert into t2 value(1),(2),(3); create table t3(v1 int, v2 int) partition by hash(v1) partitions 4; delimiter / create procedure p0() begin declare a int; declare i int; set a = 20; set i = 1; while (i < a) do insert into t3 value(i, i); set i = i + 1; end while; end/ call p0()/ CREATE FUNCTION f2(v1 int) returns int begin declare haha int; declare ans int; set haha = 1000; SELECT haha + v1 INTO ans FROM t3 limit 1; return ans; END/ create procedure p3() begin declare a int; declare i int; set a = 100010; set i = 0; while (i < a) do select * from t2 left join t1 on t1.id = t2.id where t1.id > 0 and f2(i) > 0 limit 1; set i = i + 1; end while; end/ call p3()/ |
Oracle mode 下游标 select udf 开事务在问题版本即会触发该事务。 触发场景示例如下：客户环境请在测试环境测试避免造成生产故障。 create or replace function func return int is begin return 0; end; / create table t(col int); insert into t values (1),(2); declare cursor c is select func() from t; x int; begin for idx in 1..100010 loop open c; fetch c into x; close c; end loop; end; / |
事后诊断
查询 OBServer 日志，找到
scheduler ctx陡增的时间段。fgrep "ObTransCtx statistics" OBServer.log.*获取active_sche_ctx_count陡增时间段。执行以下步骤保存基本信息。
- 系统租户下查询虚拟表 __all_virtual_trans_stat，保存事务信息。
- 系统租户下查询虚拟表 __all_virtual_processlist，保存会话信息。
- 保存
active_sche_ctx_count陡增时间段对应节点的 OBServer 日志。 - 系统租户下查询对应时间段内的
sql_audit，保留对应时间段的 SQL 执行情况。
注意
在执行步骤 c 时需要先查询虚拟表 __all_virtual_trans_stat，再保存 OBServer 日志。
由于在查询虚拟表
__all_virtual_trans_stat的时候，会强制打印scheduler的trace日志（但是存在个数限制，上限为 100 个）。可以根据该trace日志来做进一步分析。```shell [2022-09-01 13:47:01.366152] TRACE [TRACE]:0 [77998][1846][YB42BC01804E-0005E78AA3FA19F1] [lt=23] [dc=0] [force print](TRACE=begin_ts=1662011125164361 2022-09-01 05:45:25.164361 [init] u=0 arg1:140177843717248, ctx_type:"scheduler", trans_type:2, trans_id:{hash:394514311769914514, inc:1285146, addr:{ip:"188.x.xxx.xx", port:2xxx}, t:1662011125164349}, pkey:{tid:1000, partition_id:1000, part_cnt:1000}, arg1:false, uref:1073741824 [start_trans] u=2 ret:0, uref:1073741825 [start_stmt] u=2 ret:0, tenant_id:1012, sql_no:4294967297, phy_plan_type:1, stmt_type:1, sql_id:"D636765F56872FC", trace_id:YB42BC01804E-0005E78A7DE9xxxx, start_time:1662011125164328, uref:1073741825 total_timeu=4) ```初步分析：通过捕获
scheduler的trace日志，去分析是否可以发现在同一个 SQL 执行下，会产生大量的scheduler上下文。此步骤可以在收集到步骤 2 的信息后联系 OceanBase 技术支持。
问题原因
一旦单台 OBServer 触发了事务超过 10w 上限的告警，那么此台 OBServer 上不能再开启新事务，这也是 server 的一种为了避免过载的自我保护机制。如果是由于大量事务执行时间比较慢，堆积在系统中，但这些事务事务仍在处理中，且向前推进，那么等到堆积的事务逐渐进行处理后，系统有可能自动恢复。但是，如果由于 OBServer 的原因（如代码问题）导致开启了非预期的事务或者是未关闭开启的事务，会导致事务的 scheduler ctx 计数随此类问题事务数量增加而增加，最终突破 10w 上限。而对此类的问题，问题当下只能通过重启问题 OBServer 来恢复系统可用性。最终需要升级 OBServer 来升级版本。
问题的风险及影响
事务超限，OBServer 报错-4013。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。
影响版本
OceanBase 数据库企业版 V2.2.77 GA（oceanbase-2.2.77-20210508211731）及之后版本、V3.1.2 GA（oceanbase-3.1.2-20210618150922）及之后版本、V3.2.3 GA（oceanbase-3.2.3.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。
解决方法及规避方式
如上述提到的 MySQL udf 场景，或者是 Oracle 游标
select udf场景下触发的事务超限问题，问题当下需要重启 OBServer 进行应急。最终需要升级到修复版本解决问题。升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V2.2.77 BP14（oceanbase-2.2.77-114000072022120410）及之后版本、V3.2.3 BP6 Hotfix4（oceanbase-3.2.3.3-106040022022122222）版本、V3.2.3 BP6 Hotfix5（oceanbase-3.2.3.3-106050012023051617）版本、V3.2.3 BP7（oceanbase-3.2.3.3-107000092023011911）及之后版本、V3.2.4 Hotfix1（oceanbase-3.2.4.0-100010012022110218）版本、V3.2.4 Hotfix2（oceanbase-3.2.4.0-100020032023032115）版本、V3.2.4 BP1（oceanbase-3.2.4.1-101000052023010822）及之后版本。
