业务SQL执行时偶发性报错：ORA-00600: internal error code, arguments: -11049, Exceed query memory limit

问题现象

业务 SQL 执行时偶发性报错，错误信息如下：

java.lang.RuntimeException: java.sql.BatchUpdateException: (conn=3221505248): ORA-00600: internal error code, arguments: -11049, Exceed query memory limit

• OBServer 版本：V4.2.5.6
• 业务租户规格：16C64G

问题原因

该问题属于 OceanBase V4.2.5 及以上版本的一个已知缺陷。

执行 DML 语句时，如果触发了内部 SQL（inner sql）查询、执行上下文切换到 META 租户，此时实际使用的内存仍属于业务租户，但单条 SQL 的内存使用上限却按 META 租户来计算。

由于 META 租户的内存通常仅为业务租户的 1/10，导致计算出的内存上限远小于预期。当单条 SQL 语句本身消耗内存较大时，就可能触发误报，提示内存超限。

触发场景：

1. 单条 SQL 执行消耗了较大的内存（超过业务租户内存的 1/20）。
2. 执行过程中触发了内部 SQL 执行，导致上下文切换到 META 租户。

修复版本：

• 4.2.5.7 hotfix3
• 4.3.5.5 hotfix5
• 4.4.2.0
• 4.6.0

关键信息

NA

问题的风险及影响

NA

适用版本

OceanBase V4.2.5 及更高版本。

解决方法

方法一：调整业务租户内存规格
通过调大业务租户的内存规格，间接增加其关联的 META 租户内存，使其上限超过单条 SQL 语句内存使用量的 50%。

方法二：控制单条 SQL 内存使用量
优化业务 SQL，例如将单条消耗内存较大的 SQL 拆分为多条 SQL 分批次执行，以降低单次执行的内存峰值。

方法三：升级 OceanBase 集群版本
将 OceanBase 集群升级至已修复该问题的版本。

规避方式

如需临时规避此问题，可连接到系统租户（sys），执行以下 SQL 语句：

ALTER SYSTEM SET query_memory_limit_percentage = 100 TENANT = META$1002;

说明：

• 将 query_memory_limit_percentage 设置为 100 表示不限制单条 SQL 的内存使用。
• 命令中的 1002 需替换为实际环境中业务租户的 tenant_id。

问题排查

完整的报错日志示例如下：

OBE-00600: internal error code, arguments: -11049, Exceed query memory limit (mem_limit=3435973836, mem_hold=3436745640),  please check whether the query_memory_limit_percentage configuration item is reasonable.

错误码说明：

• OceanBase 错误码：11049
• 错误原因：查询内存超出限制。
• 解决方法：检查配置项 query_memory_limit_percentage 的值，确认设置是否合理。
• 引入版本：该错误码从 OceanBase V4.2.5 版本开始引入。

相关配置项：
从 OBServer V4.2.5、V4.3.5 版本开始，新增了租户级配置项 query_memory_limit_percentage，用于指定单条 SQL 可使用的租户内存百分比。

-- 查询配置项信息
SELECT * FROM gv$ob_parameters WHERE name LIKE 'query_memory_limit_percentage';

• 作用：指定单条 SQL 可使用的租户内存百分比。当内存使用超过指定阈值后，系统会报错并中断该 SQL 的执行。
• 默认值：50
• 取值范围：[0, 100]
• 生效范围：租户级别，动态生效。

案例分析：
以客户环境为例，业务租户内存规格为 64G。当租户内存规格大于等于 10G 时，META 租户和用户租户的内存分配比例通常为 1:9。

因此，业务租户可用内存约为：

64G * (1 - 10%) = 57.6G

单条 SQL 默认允许使用的内存上限为：

57.6G * 50% = 28.8G

然而，报错日志中显示的内存上限（mem_limit）为 3435973836 字节，约等于 3.2G，远低于预期的 28.8G。此差异印证了问题原因中的描述：内存检测时错误地使用了 META 租户（内存较小）的上下文来计算上限。