打开 _enable_enhanced_cursor_validation 后 DML 修改的表个数超过 8 个则 cursor 可能读不到事务内修改

问题现象

开关处于打开状态：_enable_enhanced_cursor_validation=True（此开关默认是关闭状态）。 cursor 在事务中打开时事务内 DML 修改的表个数大于或等于 8 个的情况下，如果 cursor 访问的表位于访问顺序的第 8 个表开始的表集合中，则 cursor 的读取可能读不到当前事务在这个表上的修改。注意，并不会报错出来。

关键诊断信息

触发条件

1. 租户级别开关处于打开状态：_enable_enhanced_cursor_validation=True。

2. cursor 在事务中打开时事务内 DML 修改的表个数大于或等于 8 个的情况下。

3. 若按照访问顺序给表确定顺序的情况下，若 cursor 将会访问第 8 张表或者这张表之后的表。

将会触发本文档描述的缺陷。

事前巡检

检查用户的存储过程，是否有符合如上使用的事务模型。注意触发器访问的表也会被纳入到事务访问的表。

事后诊断

没有明确的日志信息，需要打开 trace 日志。但是基本上通过事务模型可以确定。

问题原因

因处理事务中访问表的集合时对于超过8张表的情况下进行优化去重处理上存在 BUG 导致每次处理的最后一张表会被从集合中删除。 从而导致 cursor 误判表上无事务内修改，采用事务外读的方式读取数据，从而读不到未提交事务的修改。

问题的风险及影响

如果触发此使用场景，用户的 cursor 读取结果是不正确的。取决于用户是否有校验，以及是否对 cursor 查询的结果进行作为修改数据的依赖项，从而导致最终事务的数据不正确。

影响租户

影响 OceanBase 数据库中的 Oracle 租户，对于 SYS 租户和 MySQL 租户无影响。

影响版本

OceanBase 数据库企业版 V4.2.1 BP8（oceanbase-4.2.1.8-108000052024072217）及之后版本、V4.2.5 GA（oceanbase-4.2.5.0-100000082024102022）及之后版本、V4.3.5 GA（oceanbase-4.3.5.0-100000122024123020）及之后版本。

解决方法

• 升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V4.2.5 BP3 Hotfix1（oceanbase-4.2.5.3-103010072025041817）版本、V4.2.5 BP3 Hotfix2（oceanbase-4.2.5.3-103020062025042921）版本、V4.2.5 BP3 Hotfix3（oceanbase-4.2.5.3-103030032025050809）版本、V4.2.5 BP3 Hotfix4（oceanbase-4.2.5.3-103040042025052114）版本、V4.2.5 BP3 Hotfix5（103050012025061710）版本、V4.2.5 BP3 Hotfix6（oceanbase-4.2.5.3-103060032025111215）版本、V4.2.5 BP4（oceanbase-4.2.5.4-104000082025052817）及之后版本、V4.3.5 BP1 Hotfix4（oceanbase-4.3.5.1-101040012025041719）版本、V4.3.5 BP1 Hotfix5（oceanbase-4.3.5.1-101050012025042323）版本、V4.3.5 BP1 Hotfix6（oceanbase-4.3.5.1-101060022025052114）版本、V4.3.5 BP2（oceanbase-4.3.5.2-102000162025051417）及之后版本。

• 可以选择关闭开关：_enable_enhanced_cursor_validation。

• 可以修改事务执行的逻辑，避免如上触发条件。

规避方式

建议关闭开关 _enable_enhanced_cursor_validation，若无法关闭开关，建议修改事务执行的逻辑规避触发条件。