问题现象
DtlIntermRes 这个 mod 的内存占用过大。
可以通过如下语句查看该模块占用的内存。
obclient> select * from oceanbase.__all_virtual_memory_info where label = 'DtlIntermRes';
关键诊断信息
分布式计划，中间结果集大。
问题原因
设计问题。所有中间结果的落盘是由一个后台线程完成的，写入速度较大时落盘跟不上，会导致占用内存越来越大。
存在一个 BUG，在读落盘的中间结果时，会申请内存存放数据，读完以后会释放内存释。为了避免频繁申请释放内存，这里做了优化，不会真正把内存释放掉，而是放入
free_list_中等待后续复用。导致free_list_中的内存没有得到复用。BUG 导致free_list中的内存没有得到复用，因此使用的内存越来越多。
问题的风险及影响
分布式计划执行时如果中间结果集比较大，占用内存比较多。
影响租户
影响 OceanBase 数据库中的 Oracle 租户和 MySQL 租户，对于 SYS 租户无影响。
影响版本
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.0-20220418212020）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本、V4.1.0 GA（oceanbase-4.1.0.0-100001122023040322）及之后版本。
解决方法及规避方式
升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP11（oceanbase-3.2.3.3-111000032024070822）、V3.2.4 BP6（oceanbase-3.2.4.6-106000062023110109）。
对于存在这样问题的 SQL，可以使用
hint /*+ parallel(2) */开启并行，并行度大于 1 时是流式执行，不会写中间结果。通常生成计划时会避免 transmit 发送那么大的数据，出问题的 SQL 最终的输出结果有几十亿行。可以检查一下问题 SQL 是否合理，或者对计划进行调整。
