ABAP内部模式2GB上限：SYSTEM_IMODE_TOO_LARGE排查与内存优化实战

凌晨两点，监控邮件把我叫醒：一个跑了快两年的后台报表作业突然失败，ST22 里躺着一个SYSTEM_IMODE_TOO_LARGE。我登录应用服务器一看，物理内存 64GB 还剩一大半，swap 也没满，怎么看都不像“内存不够”。可 ABAP 程序就是在内部模式（Internal Mode）的 2GB 上限门口崩溃了。

这个 dump 跟物理内存几乎没有直接关系。真正卡死它的是 ABAP 内部模式的边界，而这个边界由地址空间、运行时参数、还有程序自己的“内存吃相”共同决定。这篇文章把完整链路拆一遍：内部模式 2GB 上限到底卡在哪、排查时应该看什么、代码层怎么把内存压下来、内存参数能调到什么程度，以及最后怎么让团队长期不再踩同一个坑。对 ABAP 开发、SAP Basis 顾问、还有做性能优化的人来说，这篇算一份能直接上手的实战手册，不是泛泛讲理论。

1. 内部模式 2GB 上限：先搞清楚它到底卡在哪

1.1 内部模式是什么：Work Process 脚下的一亩三分地

很多 ABAP 开发者听到“内部模式”四个字就觉得抽象，我换个说法：一个 Work Process 在跑你的一段 ABAP 代码时，它脚下那一整块可用的内存地皮，就是内部模式。这块地皮不是指数据库那边的数据量，也不是应用服务器物理内存总量，而是当前这个作业、这个执行会话里，你所有全局变量、内表、字符串、对象实例和调用栈的立足之地。

这块地皮大致由三块拼成：

• Roll Area（滚动区/静态区）：每个 Work Process 自带的一块固定小空间，存放全局变量、标准内表头、当前程序状态。它像办公桌上的抽屉柜，容量有限，通常是几 MB 级别。
• Extended Memory（扩展内存）：多个 Work Process 共享的内存池，用来缓解对话步骤切换时的数据搬移。可以理解成走廊里共用的资料柜，谁需要谁取。
• Private Heap（私有堆）：Work Process 从操作系统进程堆里申请的内存，ABAP 程序跑大内表、大字符串、创建大量对象时主要从这里拿地。好不好拿，取决于进程地址空间和 SAP 参数。

内部模式 = 这三块在某个执行上下文里的总和视图。SYSTEM_IMODE_TOO_LARGE报出来，就是这个总和触碰到了系统允许的边界，或者其中某一块申请失败、总账超支。

1.2 为什么上限是 2GB：地址空间与 ABAP 进程模型的历史账

要聊 2GB 上限，得先回到 32 位进程时代。32 位的进程地址空间总共只有 4GB，操作系统默认给用户态划 2GB，给内核态留 2GB。SAP 的 Work Process 本质是一个操作系统进程，它的一切内存申请都得从这个 2GB 的用户态地址空间里出。Roll Area、Extended Memory 映射、Private Heap，全部挤在这 2GB 里，谁多占一点，别人就少一点。这就是“内部模式 2GB 上限”最直白的历史来源。

我在实际培训时爱用一个比喻：物理内存是你公司楼下整个停车场的大小，进程地址空间是你能租到这层楼上仓库的合同面积，而内部模式是这间仓库里真正摆得下货架的区域。物理内存哪怕有 64GB，只要进程地址空间只有 2GB 的合同面积，大货就永远进不来。32 位系统上，SELECT *一下拉 400 万行，经常在 ABAP 层还没开始处理就原地爆炸，原因就在这里。

64 位系统普及后，进程用户态地址空间按说已经大到可以忽略这个限制。但 SAP 这么多年下来形成了一种根深蒂固的“护栏”习惯：即便底层地址空间够大，运行时仍然通过一系列 profile 参数给单个 Work Process 圈了一条人工上限，防止某个异常程序一口气吃光实例资源、把邻居业务全部拖死。所以你在 64 位 HANA 环境里照样会见到SYSTEM_IMODE_TOO_LARGE，这时候的 2GB 已经不是地址空间原罪，而是参数圈出来的人为边界。标题里说的“2GB 上限”，在今天既要看历史原因，也要看现实的参数约束。

1.3 64 位环境为什么也会爆：参数背锅还是代码背锅

到了 64 位系统，单个 Work Process 能碰到的地皮理论值远不止 2GB，但 SAP 还是有几个关键参数在暗中划线：rdisp/heaplimit、abap/heap_area_dia、abap/heap_area_nondia、em/initial_size_MC这些合起来决定了一个进程私有堆最多能长到多大。超过了，Work Process 会拒绝继续申请内存，然后 ABAP 运行时把这个拒绝升级成 dump，报错信息就是SYSTEM_IMODE_TOO_LARGE。

我遇到过一个特别典型的案例：某个报表程序平时跑 100 万行数据没出过事，后来业务数据涨到 380 万行，第二天凌晨直接 dump。系统是 64 位，内存参数一个没动过。问题出在代码用SELECT *把整张业务表载进了内表，又在 ABAP 层做了不应该由 ABAP 做的全量聚合。参数和系统都没变，是数据量跨过了一个暗线。这种就叫“代码背锅”：程序在自己不该吃那么多内存的地方吃太狠，任何参数都只是延后而不是消除问题。

所以先有结论放在前面：见到SYSTEM_IMODE_TOO_LARGE，脑子里第一反应应该是“哪个程序在内部模式里塞了太多东西”，而不是“服务器内存不够了”。前者指向代码和参数，后者指向运维加机器，方向完全不同。

2. 一次后台报表 dump 的完整排查链路

2.1 ST22 里最先看的三处信息

出事之后第一步不是去看代码，而是打开 ST22 看 dump 快照。ST22 的 dump 列表里找到那一条SYSTEM_IMODE_TOO_LARGE，先看三个地方。

第一是“发生错误的位置”和“当前语句”，它能告诉你程序跑到了哪一行、停在了哪条语句上。很多时候错误干脆就停在LOOP AT一个大内表，或者停在某次APPEND大量内表行的地方。第二是“触发的事务”和“后台作业名”，方便回过去定位是哪个报表、哪个作业、哪个用户。第三是“错误信息”和“内存分配”这一段，有些版本会直接给出“Current memory used”之类的数字，能帮你快速判断是离上限很近还是远远超支。

这里有个经验：ST22 里的行号是编译后行号，跟源码行不一定完全一致。我一般会把这个行号先折算一下，或者直接在 SE38/SE80 里打开程序跳到对应行附近。不要只看行号就冲进代码，先看语句类型和附近的变量名，效率高很多。

2.2 沿着 ST05 找到吃掉内存的那条 SQL

ST22 看完，下一个动作通常是给这个后台作业开一次 SQL 跟踪。事务代码 ST05，激活跟踪，重新跑一遍作业（或者让用户重跑一次失败的作业），然后看跟踪结果里单条 SQL 的返回行数。

我之前排查那个 380 万行的案例时，ST05 里一条SELECT * FROM VBAP WHERE ...的返回行数直接显示 380 多万行，数据量几十 MB 甚至上百 MB。看到这个数字，心里基本有数了：ABAP 层要建一个 380 万行的内表，按每行 200 到 500 字节算，光这一个对象就吃掉 700MB 到 1.5GB。叠加程序里还有别的内表、工作区、排序开销，撞上内部模式边界一点也不奇怪。

ST05 看 SQL 有个细节：不要只看有没有WHERE条件，还要看条件有没有用上索引。打开跟踪条目的“执行计划”，如果看到 Full Table Scan、索引缺失的提示，那就不仅是内存问题，还叠加了数据库性能问题。优化方向就变成两头抓：既要减小 ABAP 层装载量，也要给数据库加索引。这跟开发里说的“abap 创建索引”是一回事，很多时候内存问题和 SQL 性能问题是同一条语句的两个侧面。

2.3 用内存查看器给 ABAP 内表称重

ST05 能定位到数据库侧的大查询，但程序在 ABAP 层把哪些内表喂得最大，还得用内存查看器来看。事务代码S_MEMORY_INSPECTOR在标准 NetWeaver 里通常可用，它能按程序对象列出内存占用分布。如果版本或权限不允许，也可以用一个很小的 ABAP 工具类CL_ABAP_MEMORY_UTILITIES，在程序关键节点打印当前内存消耗，辅助定位增长曲线。

实际排查时，我会在怀疑的程序里临时加几行日志：

DATA(lv_mem_before) = cl_abap_memory_utilities=>get_memory_used( ). " 执行某段大操作 DATA(lv_mem_after) = cl_abap_memory_utilities=>get_memory_used( ). WRITE: / |内存变化: { lv_mem_before } -> { lv_mem_after }|.

这是最笨但最有效的定位方法：一段段打点，看哪段代码让内存水位猛涨。很多时候你会发现，真正猛涨的并不是 LOOP 处理本身，而是 LOOP 开始时那次全量SELECT，或者是循环里字符串拼接导致的反复重新分配。

2.4 别急着怀疑物理内存：几个容易误判的方向

接到SYSTEM_IMODE_TOO_LARGE工单时，经常有人第一反应是给服务器加内存条，或者把em/initial_size_MC猛调大。这两件事我都见过，前者能不能解决问题全看运气，后者往往治标不治本。

要避免误判，先确认几个事实：

• 应用服务器物理内存是否真的吃满，看ST02和操作系统层的free -m/top。机器空闲度很高，但 ABAP 作业照样 dump，这基本就是内部模式边界问题。
• 是不是只有某个固定程序、固定时间段才出问题。如果是，先用 ST05 和内存打点定位代码，而不是去动全局参数。
• 是不是并发量大导致的共享内存池不足。这跟单一程序的内存超支不同，症状上也可能报SYSTEM_IMODE_TOO_LARGE，但根源在扩展内存池配置，需要看ST02里的扩展内存占用和 roll 统计。

排查顺序一句话总结：先看语句，再看 SQL，再看内表，最后才看参数。跳步容易白忙活。

3. 代码层内存优化：把 2GB 的每一兆都用在刀刃上

3.1 从 SELECT * 到按需取数：省内存的第一道闸门

代码层优化里，见效最快、成本最低的一条就是砍掉SELECT *。很多人写报表习惯了把整行拉回来，反正字段多一些在 ABAP 里慢慢处理也不会报错，直到某天一个大表直接把你顶到内部模式上限。正确的做法是“只取你后面真正要用的字段”，同时把能下推的条件都下推到数据库。

反面写法：

SELECT * FROM mara INTO TABLE @gt_mara.

正面写法：

SELECT matnr, ersda, ernam, mtart, matkl FROM mara INTO TABLE @gt_mara WHERE ersda >= @p_from AND mtart IN @s_mtart.

看起来只是少写了一个星号，实际差别巨大。一张几百列的大表，字段裁剪之后单行宽度可能直接砍掉一半以上；数据量一大，这省下来的就是几百 MB。我在好几条 dump 程序上都只做了“字段裁剪 + 条件过滤”这一件事，就把内存峰值从 1.4GB 降到了 200MB 以内。这是最典型、也最推荐的第一个动作。

3.2 FOR ALL ENTRIES 使用边界：空表、去重与索引配合

FOR ALL ENTRIES是 ABAP 里常用的主子表关联写法，但使用不当会变成内存杀手。它最大的隐藏坑是：内表为空时，FOR ALL ENTRIES会被 ABAP 运行时直接忽略，导致底层 SQL 退化成无条件的全表查询，相当于一次SELECT *把整张主数据表全部拉出来。如果这张表恰好是 MARC、MARA 这种大表，一条语句就够让内部模式爆表。

所以规范做法是在使用前强制判空：

CHECK lt_keys IS NOT INITIAL. SELECT vbeln, posnr, matnr, kwmeng FROM vbap INTO TABLE @gt_vbap FOR ALL ENTRIES IN @lt_keys WHERE vbeln = @lt_keys-vbeln.

另外还有两个细节容易被忽略。第一，FOR ALL ENTRIES会先对条件内表去重，条件内表本身越大，这一步消耗的内存和 CPU 越高。能预先压缩到几百行就绝不放几万行进去。第二，底层 SQL 是按“条件内表条目数”分批拼接的，条件内表过大时，不仅 ABAP 侧占内存，数据库侧也会产生非常长的 SQL 语句，排查时会发现 ST05 里单条 SQL 的“语句文本”异常长。配合数据库索引，在 WHERE 字段上建好二级索引，能显著降低数据库侧扫描成本。这也就是团队里经常说的“abap 创建索引”要落到实处的场景。

3.3 内表类型与查找方式：SORTED TABLE、BINARY SEARCH 和循环内 LOOP

内表选型直接决定内存和查询效率。标准表（STANDARD TABLE）在数据量上去之后，每次READ TABLE ... WITH KEY默认都是顺序扫描，复杂度 O(n)。如果你在 LOOP 外面套一层 LOOP，再在里面做全表顺序查找，那就是 O(n²) 的噩梦。数据量几千行还好，几十万行时 CPU 和内存会同时失控。

优先考虑这几种写法：

• 数据量较大且查询频繁，用SORTED TABLE定义内表，或者先SORT后再READ TABLE ... BINARY SEARCH：

SORT gt_vbap BY vbeln posnr. READ TABLE gt_vbap INTO DATA(ls_vbap) WITH KEY vbeln = lv_vbeln posnr = lv_posnr BINARY SEARCH.

• 需要按键唯一读取的大数据量场景，直接定义HASHED TABLE，哈希查找接近 O(1)，内存占用略高但查询极快：

DATA: gt_mara TYPE HASHED TABLE OF ty_mara WITH UNIQUE KEY matnr.

• 避免在大循环里反复SORT同一个内表。排序本身要申请额外内存，循环里排一次就已经很浪费，排 N 次基本等于自爆。如果发现循环里反复排序，多半是算法设计有问题，先把排序提到循环外，再把循环内查找改成二分或哈希。

我们团队复盘过一条 dump 程序：一个 50 万行的内表，在 LOOP 里又去读另一个 80 万行的标准表，每条都顺序扫一遍，跑了一个多小时才到 2GB 上限。改成 SORTED TABLE 之后，几秒钟跑完，内存占用掉到原来的十分之一。问题从来不是“内存不够”，是算法在硬吃内存。

3.4 大数据量分批消费：游标与 UP TO n ROWS

有些场景确实需要处理整张大表，比如批量回填、历史数据清洗。这时候绝不能再一次性SELECT ... INTO TABLE到内表，而是分批消费。我常用的两种做法：

第一种，keyset 分页。适用于有序取数的场景，每次取一批，记住最后一个键值，下一批从它后面继续：

DATA: lv_last TYPE matnr VALUE ' '. DO. CLEAR: lt_pkg. SELECT matnr, mtart, matkl FROM mara INTO TABLE @lt_pkg UP TO 5000 ROWS WHERE matnr > @lv_last ORDER BY matnr. IF lt_pkg IS INITIAL. EXIT. ENDIF. PERFORM process_package USING lt_pkg. DATA(lv_lines) = lines( lt_pkg ). lv_last = lt_pkg[ lv_lines ]-matnr. COMMIT WORK. ENDDO.

注意 keyset 分页要求排序键唯一且稳定。如果业务键不唯一，要再叠加一个唯一键位，比如matnr + 时间戳之类，避免漏行、重行。

第二种，游标分段，适合取数条件复杂不能简单比较键位的场景：

DATA: lv_cursor TYPE cursor. OPEN CURSOR WITH HOLD lv_cursor FOR SELECT matnr, mtart, matkl FROM mara WHERE ersda >= @p_from. DO. FETCH NEXT CURSOR lv_cursor INTO CORRESPONDING FIELDS OF TABLE @lt_pkg PACKAGE SIZE 10000. IF sy-subrc <> 0. EXIT. ENDIF. PERFORM process_package USING lt_pkg. ENDDO. CLOSE CURSOR lv_cursor.

游标方式的内存峰值基本只跟“单批大小”成正比，而不是跟全量数据成正比。同时COMMIT WORK在后台作业里很重要，能控制数据库锁和共享内存压力。大数据量批处理建议单批控制在 5000 到 10000 行之间，既能压住内存，又能保证数据库不频繁往返。

3.5 字符串拼接与大对象的隐性膨胀

内表不是唯一的吃货。字符串拼接在 ABAP 里有一个容易被忽略的特性：传统CONCATENATE在循环里反复拼接，每拼一次都可能产生新的字符串对象，旧对象等 GC 回收。数据量大时，这个“反复复制-丢旧-再复制”的过程会把内部模式迅速塞满。

反面写法：

DATA: lv_result TYPE string. LOOP AT lt_text INTO DATA(ls_text). CONCATENATE lv_result ls_text-line INTO lv_result. ENDLOOP.

正面写法是把要拼的内容先收集到字符串内表，再一次性合并：

DATA: lt_lines TYPE TABLE OF string. LOOP AT lt_text INTO DATA(ls_text). APPEND ls_text-line TO lt_lines. ENDLOOP. DATA(lv_result) = concat_lines_of( table = lt_lines ).

concat_lines_of更接近“一次性合并所有行”，内部尽量复用内存，比循环拼接高效得多。类似的还有xstring、XML 构建、JSON 序列化等大对象操作，能一次性构造就别在循环里一点点拼。

3.6 FREE 与 CLEAR：交还内存的时机

ABAP 内表用完之后，很多人习惯用CLEAR清空。CLEAR只是把内容清掉、保留已分配的内存仓库，方便下次继续用；如果程序后面不再大量使用这个内表，仓库就一直占着。用FREE会真正释放内表占用的私有堆内存，把地皮还给系统。

CLEAR gt_mara. " 清空内容，内存池保留 FREE gt_mara. " 释放内表占用的堆内存，后续可重新填充

我在优化长期运行的后台程序时，会在每个大内表处理完的节点主动加FREE，同时对后续不再需要的中间内表也做FREE。短小对话事务内没必要太较真，但一个后台作业里如果连续做多个大步骤，每一步之间及时释放，能明显平滑内存水位。这不是什么高深技巧，就是“用完的仓库退租”，但很多人就是想不起来。

4. 内存参数调优：能解燃眉之急，但别当第一张牌

4.1 影响内部模式边界的参数清单：从 RZ11 读起

代码优化做完，如果内存压力还是大，才会轮到参数层面。但动参数之前必须用事务代码 RZ11 查看当前实际生效值。不同 NetWeaver 版本、不同操作系统、不同数据库，常见默认值差异不小，照抄网上参数不一定适合你的系统。下面表格给的是“这个参数管什么”和“通常往哪个方向调”，不是让你照抄数值。

这里我必须强调：这些参数里，ztta/roll_first和ztta/roll_area是动态参数，通常可以直接用 RZ11 在线改；abap/heap_area_dia、abap/heap_area_nondia这类属于 profile 参数，需要改默认 profile 并重启实例才能完全生效。如果只是想临时救火，又不想重启，就要先分清哪些参数是 instance 级动态可调、哪些是整体重启才生效。

4.2 一次参数调整的真实实验：哪些改动有效，哪些是心理安慰

我参与过的一个项目，某客户系统连续几周在月末后台跑批时出现SYSTEM_IMODE_TOO_LARGE。一开始 Basis 团队选择调参数：把abap/heap_area_dia从 1GB 提到 2GB，abap/heap_area_nondia提高到 4GB，rdisp/heaplimit从 300MB 提到 500MB，em/initial_size_MC从 1024 调到 2048。

结果确实有效，SYSTEM_IMODE_TOO_LARGE不再出现，但应用服务器的整体内存占用从 32GB 一路飙到 45GB，其他业务进程开始被挤到 swap，用户反馈系统明显变慢。最后我们花了两天时间把报表程序里那条全量SELECT + ABAP 层聚合重构成数据库侧GROUP BY，内存参数全部还原回默认配置，dump 再也没有出现过，系统内存也回到了 30GB 上下。

这个案例说明三件事：

1. 参数上调确实能解决“单个进程上限不够”的直接问题，但是代价是挤压实例上其他 Work Process 的生存空间。
2. 上调参数往往只是把问题从“进程崩溃”变成“整体资源紧张”，系统照样慢，只是不 dump 而已。
3. 只要代码层把大头消掉，原来认为“必须调参”的场景根本不需要调参。

所以我个人对参数的态度很明确：它可以作为临时止血手段，但绝不是长久之计。特别是在 64 位系统上，轻易把abap/heap_area_nondia之类的参数调得很大，一旦程序内存泄漏或者数据量突变，单个 Work Process 可能把一个应用服务器吃到不可用。

4.3 参数调优的边界：保护进程还是削足适履

还有一个经常被忽视的问题：SYSTEM_IMODE_TOO_LARGE本身是 SAP 的一种“保护性拒绝”，目的是防止一个进程无限吃内存拖垮整个实例。如果你把它看成一次错误拒绝，然后无限调高上限，本质上是在拆除安全护栏。

打个比方，家里保险丝 10A，你总是开大功率电器导致跳闸。你能做的是换 20A 保险丝，但真正要做的是少同时开几个大电器。换保险丝解决的是“能不能用”，少开大电器解决的是“安不安全”。ABAP 内部模式参数同理。

如果要动参数，我的建议是：每次只动一个，改完观察 24 到 72 小时，结合 ST03N、STAD、操作系统内存指标综合判断，确认没有引发其他进程资源不足，再考虑下一步。千万不要一次把四五个参数同时拉大，出了问题你根本不知道是哪一步造成的。

5. 从救火到防火：内部模式内存的长期治理

5.1 建立实例内存基线：ST03N 和 STAD 的日常盯法

SYSTEM_IMODE_TOO_LARGE不可能完全靠临时排查杜绝，必须把内存监控纳入日常运维节奏。我建议每个月至少看一次 ST03N 的工作负载统计，关注对话、后台、更新这几类工作负载的内存消耗平均值和峰值。如果发现后台作业内存峰值逐月抬升，那大概率是数据量在涨、程序没跟上，迟早会撞线。

STAD（事务代码 STAD）则用来复盘单个用户或单个作业的事务统计。看单条事务的数据库调用次数、平均响应时间、上下文大小这些字段，能帮你快速找出“跑得慢且吃内存”的高危程序清单。把这批清单拉出来，就是下一个月的优化候选池。

这个监控节奏不需要很复杂，关键是持续。我见过太多项目的内存排查是“出事才看”，事后再没人管，下个月再 dump 一次。建立月度基线对比之后，很多问题能被提前发现，根本不必等到崩溃。

5.2 用 Code Inspector 把内存风险拦在传输前

比事后监控更靠前的，是在代码上线前就把问题拦住。SAP 标准的 Code Inspector（事务代码 SCI）支持自定义检查变体，你可以把规则配严一点，重点开启这几类检查：

• SELECT *检查，发现全表字段选择直接给出警告。
• FOR ALL ENTRIES前缺少空表检查的检查项。
• 循环内调用READ TABLE且未使用二分搜索的嫌疑。
• 大型内表定义和性能相关的基础检查。

在传输请求释放前强制跑一遍 SCI，高风险代码直接打回。这个动作相当于给 ABAP 内存问题上了一道“生产前安检”，成本远低于线上 dump 之后排查。团队刚开始推行时可能有抵触情绪，觉得 SCI 误报多，但把检查变体配置合理之后，误报会少很多，留下来的问题基本都是真问题。

5.3 把聚合压给数据库：CDS 与 SQL 下推

ABAP 层最常犯的错误就是“取全量明细，然后到 ABAP 里分组汇总”。正确的方向是把聚合、过滤、连接全部压到数据库层，让数据库返回已经浓缩的结果。

比如以前这么写：

SELECT * FROM vbap INTO TABLE @gt_vbap. LOOP AT gt_vbap INTO DATA(ls_vbap). COLLECT ls_vbap INTO gt_summary. ENDLOOP.

现在改成用 CDS 视图做聚合：

@AbapCatalog.sqlViewName: 'ZCUST_MONTHLY_SALES' @AbapCatalog.compiler.compareFilter: true define view ZCustMonthlySales as select from vbap as v inner join mara as m on m.matnr = v.matnr { m.mtart as MaterialType, sum( v.kwmeng ) as TotalQty, count( * ) as LineCount } group by m.mtart

ABAP 层再从这个 CDS 视图查，返回的只有几行几十行聚合结果，而不是几十万上百万的明细行。内存占用的差别是数量级的。这个思路不只是 CDS，任何能下推的 SQL 聚合、JOIN 过滤、甚至 HANA 的窗口函数，都应该优先在数据库侧完成。ABAP 只负责“处理和展示”，不要让 ABAP 层变成数据库。

5.4 值得写进开发规范的内存红线

最后，把这些年踩坑总结出来的几条硬规矩放到团队开发规范里，能挡掉大部分内存问题：

• 禁止SELECT *拉大表；只取需要的字段，能下推的条件必须下推。
• 使用FOR ALL ENTRIES前必须判空，条件内表能先压缩就压缩。
• 大数据量表内查找必须用 SORTED TABLE / HASHED TABLE 或二分搜索，禁止循环内对标准表顺序查找。
• 批量处理超过几万行时，必须设计分批消费逻辑，禁止全量装载后处理。
• 字符串、XML、JSON 等大对象禁止在循环里反复拼接，尽量一次性构造。
• 后台作业中处理完的大内表及时FREE，不要等作业结束。
• 新增报表程序在传输前必须过 Code Inspector 内存相关检查。

这些规矩每一条背后都对应着我见过的一次真实 dump。看起来是小事，数据量小的时候全无所谓，数据量一上来全是事故。把它们写进规范，相当于把过去踩过的坑变成自动拦截规则，比任何“优化经验分享”都管用。

我现在处理SYSTEM_IMODE_TOO_LARGE的固定顺序已经非常机械：先开 ST22 看语句和位置，再开 ST05 看有没有单条大 SQL，再用内存打点看哪个内表是吃货，然后按代码层优化清单逐条修，最后才动参数。这些年下来，百分之八十以上的 dump 在第三、四步就能解决，真正需要动内存参数的是少数，而且动完也只是临时方案。

印象最深的一次，客户的数据量翻了四倍，那条老报表还在用几年前的写法全量拉数。我用了一个下午把它的 SELECT 改成字段裁剪、把分组汇总改成 CDS 下推、把中间内表改成 SORTED TABLE，再配上分批读取，内存峰值从 1.6GB 降到了 60MB，运行时间从 45 分钟压缩到 6 分钟。调完那天我在想，要是当初写程序的人就按这几条规矩来，这个 dump 根本不会发生。

所以最后分享一个最朴素的经验：内部模式 2GB 上限不是敌人，它是替你把那些“吃内存没够”的程序提前暴露出来的报警器。真正要改的，从来不是报警器，而是那个让内存失控的写法。每次看到SYSTEM_IMODE_TOO_LARGE，都当是一次免费的代码体检，把根因修掉，这个 dump 才有价值。