PL 内部含有大量静态 SQL 可能导致 core dump

问题现象

当用户执行含有大量静态 SQL 的 PL 语句时，OceanBase 数据库可能出现 core dump。从目前的已知问题来看，在 OceanBase 数据库 V4.x 版本上，单个 PL 含有数千条静态 SQL 时可能触发此问题。理论上全版本都有此问题，但目前仅在 V4.x 版本出现过，可能是因为 V3.x 版本比 V4.x 版本默认栈大小更大，所以出现概率更低。

关键诊断信息

触发条件

当执行的 PL 中含有大量静态 SQL 时可能触发。

事前巡检

如果发现用户某个 PL 中含有的 SQL 语句数量过多，建议将其分解为多条 PL 执行，或将 OceanBase 数据库升级到已修复版本。

事后诊断

如果出现 core dump，立即备份日志和 core 文件。使用 gdb 打开 core 文件并进入发生 core dump 的栈帧，执行 find $rsp-10000，$rsp 0xcaca12344321acac 判断栈爆，若有结果，继续在日志中搜索 CHRASH ERROR ，如果打印出的 PL 语句包含大量静态 SQL，则大概率命中此问题。理论上爆栈可能 core 在任何位置，但大概率含如下信息。

oceanbase::sql::ObSPIService::spi_execute(oceanbase::pl::ObPLExecCtx*, char const*, long, oceanbase::sql::ObSqlExpression const**, long, oceanbase::sql::ObSqlExpression const**, long, oceanbase::common::ObDataType const*, long, bool const*, long const*, bool, bool, bool, bool)

这层栈帧。建议通过 gdb 判断栈爆和日志中打印的语句两方面共同判断是否是此问题。

问题原因

OceanBase 数据库内核 BUG。当 PL 在执行静态 SQL 语句时，会在栈上分配临时内存，但执行完毕后没有清理，只有等待整个 PL 执行结束后才会回收。所以当单个 PL 含有大量 SQL 语句时，可能造成爆栈 core dump。

问题的风险及影响

core dump 造成业务不稳定。

影响租户

影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。

影响版本

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.3-20220419）及之前版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之前版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之前版本、V4.2.0 GA（oceanbase-4.2.0.0-100010082023083014）及之前版本、V4.2.1 GA（oceanbase-4.2.1.0-100000182023092722）及之前版本、V4.2.2 GA（oceanbase-4.2.2.0-100000082024011317）及之前版本。

解决方法及规避方式

• 解决方法：

  升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）及之后版本、V3.2.4 BP8（oceanbase-3.2.4.8-108000142024041520）及之后版本、V4.2.1 BP4（oceanbase-4.2.1.4-104000062024022914）及之后版本、V4.2.2 BP1（oceanbase-4.2.2.1-101000012024030619） 及之后版本。

• 规避方式：

  1. 改写 PL，将静态 SQL 分散到多个 PL 中，避免单一 PL 含有大量静态 SQL。

  2. 使用 alter system set stack_size 适当增大栈大小，重启生效。