ERROR 4019 (HY000): Size overflow

OceanBase
#1

【产品名称】oceanbase-ce

【产品版本】3.1.1

【问题描述】目前有个sql语句大小为144k，sql的内容类似select a, b, c from tbl_name where order_id in (xxx);主要是in的内容特别多，导致这个sql

非常大，执行会报ERROR 4019 (HY000): Size overflow。目前net_buffer_length参数的值是1M，max_allow_packet是4M。order_id是联合唯一索引最左

字段，报错也是瞬间报错，不像是死锁导致。有人遇到过么？感谢各位大佬！

#2

详细的排查需要了解一下你的租户内存资源大小。

查看方法是：

select tenant_name, resource_pool_name, zone, svr_ip, svr_port, max_cpu, round(max_memory/1024/1024/1024) max_mem_gb,round(min_memory/1024/1024/1024) min_mem_gb from gv$unit
where tenant_id=1006
;


如果租户内存不大，或者sql文本实在太长，需要调整租户的sql工作内存。

MySQL [oceanbase]> show global variables like '%area%';
+-----------------------------+-------+
| Variable_name               | Value |
+-----------------------------+-------+
| ob_sql_work_area_percentage | 5     |
+-----------------------------+-------+
1 row in set (0.047 sec)


MySQL [oceanbase]> set global ob_sql_work_area_percentage=30;


如果还报错，可以把这个内存比例调整更大一些。

#3

in后面的参数大概有多少个呢，方便提供一下报错日志吗。

先执行

set ob_enable_trace_log=1;

然后执行目标query，报错后执行

show trace;

用展示的trace_id到observer.log中搜索。

#4

租户内存80g，ob_sql_work_area_percentage参数为5，意味着单个sql占4G，是这个意思么？


#5

10272个，我按照你提供的方法试试看看报错信息是啥

#8

因为show trace展示的是当前session执行的上一条sql的trace，你用source的话show trace不会展示脚本中报错的那条sql的trace。

执行在observer.log中搜吧

grep "from tbl_name where order_id" observer.log* | grep "ret=-4019"
#11

已定位由于分布式计划序列号query_range爆栈导致，由于in后面list中有很多值，抽出了很多query range，导致序列化时递归深度过大，近期会在社区版修复该问题。

1 个赞
#12

好的，感谢大佬！由于之前的回帖图片里有一些敏感信息，所以删除了之前的回复，非常抱歉！

再次感谢各位大佬！感谢各位大佬给予的支持！感谢各位大佬对开源社区的贡献和热爱！

希望有机会能对oceanbase的开源社区做出贡献。

1 个赞