---
title: "业务 SQL 执行时偶发性报错：ORA-00600: internal error code, arguments: -11049, Exceed query memory limit-OceanBase数据库使用指南"
description: "了解OceanBase数据库在实际应用中关于业务 SQL 执行时偶发性报错：ORA-00600: internal error code, arguments: -11049, Exceed query memory limit相关的常见问题和使用技巧，帮助您快速解决业务 SQL 执行时偶发性报错：ORA-00600: internal error code, arguments: -11049, Exceed query memory limit的难题。"
image: https://mdn.alipayobjects.com/huamei_22khvb/afts/img/A*OSPzQ6GUQF4AAAAAQHAAAAgAeiGDAQ/original
---
切换语言

- 中文站 - 简体中文
- International - English
- 日本站 - 日本語

划线反馈

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

更新时间：2026-08-25 02:41

适用版本： V4.2.x、V4.3.x、V4.4.x 内容类型：Troubleshoot  

## 问题现象

业务 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 及以上版本的一个内部已知缺陷。

**缺陷原理**

1. OceanBase 内核存在单条查询（query）的内存限制功能，默认上限为业务租户内存的 50%。
 2. 在执行 DML 语句时，系统会发起内部 SQL（inner sql）查询日志流（LS）的缓存，此时执行上下文会切换到 META 租户。
 3. 切换后，实际内存使用量仍计入业务租户，但内存检测线程在周期性重新读取租户配置和内存使用量时，会基于当前线程的上下文（即 META 租户）重新计算内存使用上限。
 4. 由于 META 租户的内存通常仅为业务租户的 1/10，导致计算出的内存上限远小于预期。
 5. 当内部 SQL 本身消耗内存较大时，就可能超过这个被错误计算的小上限，从而触发内存超限报错。

**触发场景**

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

**修复版本**

- 4.2.5.7 hotfix3
 - 4.3.5.5 hotfix5
 - 4.4.2.0
 - 4.6.0

## 适用版本

OceanBase V4.2.5（oceanbase-4.2.5.0-10000008202410202）及更高版本。

## 解决方法

**方法一：调大业务租户内存规格**

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

**方法二：控制单条 SQL 语句的内存使用量**

优化业务 SQL，例如将消耗内存大的单条 SQL 拆分为多条 SQL 分批次执行，以降低单次操作的内存峰值。

**方法三：升级 OceanBase 集群版本**

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

## 规避方式

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

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

```

- 将参数 `1002` 替换为实际业务租户的 `tenant_id`。
 - 将 `query_memory_limit_percentage` 设置为 100 表示取消单条 SQL 的内存百分比限制。

## 问题排查

**报错日志示例**

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

```
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 可使用的租户内存百分比。

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

```

- **作用**：指定单条 SQL 可使用的租户内存百分比。当内存使用超过指定阈值后，系统会报错并中断该 SQL 的执行。
 - **级别**：租户级别（TENANT），动态生效（DYNAMIC_EFFECTIVE）。
 - **默认值**：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 租户的配置进行计算所致。

上一篇

[使用 OB Oracle 到原生 Oracle 的 DBLink 查询报错 24454](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006418183)

下一篇

[索引列频繁 UPDATE 导致索引 MemTable Key 膨胀的验证与分析](https://www.oceanbase.com/knowledge-base/oceanbase-database-1000000006802899) ![有帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*y6ocSqN8cqsAAAAAAAAAAAAAARQnAQ)![无帮助](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*BG9IQJyLHF8AAAAAAAAAAAAAARQnAQ)![反馈](https://gw.alipayobjects.com/mdn/ob_asset/afts/img/A*eTWdQKCRKHwAAAAAAAAAAAAAARQnAQ)[AI](https://www.oceanbase.com/obi) 咨询热线