问题现象
OceanBase 数据库从 V3.2.3 BP5 升级到 V3.2.3 BP10 后，使用 obdumper 工具导出大量数据时 SQL 执行超时，影响了数据的正常推送和监管报送。
关键诊断信息
触发条件
租户内存 limit 持续等于 hold。
使用 obdumper 工具执行大数据量导出操作。
SQL 执行过程中涉及大量的排序（sort）和哈希连接（hash join）操作。
事前巡检
检查租户内存配置，确保租户内存 limit 不会长期等于 hold。
审核 SQL 语句，特别是涉及大量数据排序的操作，评估是否有优化空间。
事后诊断
查询
gv$sql_workarea_active视图，确认是否存在大量 sort 算子和 hash join 算子落盘的情况。检查 obdumper 工具的日志，观察是否有生成临时文件的记录。
问题原因
租户内存 limit 持续等于 hold 情况下，自动内存管理功能失效，全局内存边界（global memory bound）降为 1MB。这导致排序（sort）操作每处理一行数据就需要写入临时文件，由于存储写入放大效应，最终导致磁盘空间迅速膨胀，SQL 执行因此超时。
问题的风险及影响
SQL 执行超时。
磁盘空间膨胀。
影响租户
影响 OceanBase 数据库中的 SYS 租户和 Oracle 租户以及 MySQL 租户。
影响版本
OceanBase 数据库企业版 V3.2.3 BP10（oceanbase-3.2.3.3-110000092023091219）及之后版本、V3.2.4 GA（oceanbase-3.2.4.0-100000072022102819）及之后版本。
解决方法
清理 KV cache 后重新执行 SQL。
使用 OBClient 连接字符串加上
-c选项，并通过 Hint 控制执行计划来执行 SQL。
规避方式
定期监控租户内存使用情况，避免租户内存 limit 长期等于 hold。
对于涉及大量数据排序的 SQL，考虑使用更高效的算法或增加内存分配，减少排序操作的内存使用超过自动内存管理计算的内存边界的可能性。
在非向量化场景下，尽量避免使用可能导致大量数据落盘的 SQL 语句，或提前测试并优化这些语句。
考虑升级到修复此问题的版本：升级至问题已修复版本。目前已修复的版本包括 OceanBase 数据库企业版 V3.2.3 BP10 Hotfix18（oceanbase-3.2.3.3-110180012025060316）版本、V3.2.3 BP10 Hotfix19（oceanbase-3.2.3.3-110190022025082615）版本、V3.2.3 BP10 Hotfix20（oceanbase-3.2.3.3-110200012025111317）版本。
