调用VC_I_GET_CONFIGURATION注意事项

结论:调用VC_I_GET_CONFIGURATION时,必须设置IV_MAX_MASSPROCESSING参数,建议设置成10.
解释:VC_I_GET_CONFIGURATION是为GUI界面调用设计的。为提高读取同一个订单数据的速度,它会将订单的主数据和配置数据放到内存中,以便下一次使用。这个机制对单个订单处理是合适且有效的,但是当一个报表程序需要同时读取很多订单的配置数据,就会造成Paging Area内存的溢出。
为应对批量读取订单配置的情况,必须设置VC_I_GET_CONFIGURATION的IV_MAX_MASSPROCESSING参数。如果设置成10,意味着这个函数调用10次之后,就会清空缓存数据。

Notes 303138的说明:
Module VC_I_GET_CONFIGURATION and the modules being called are not written for mass data processing but for high-performing online transactions. For this reason, the master data and the configuration data is buffered in memory for the entire runtime of the transaction, to ensure quick access when you request the same data several times.
This buffering cannot be cancelled but the initiator must actively delete the buffers.

现象:2010-12-21上午,系统出现40多个MEMORY_NO_MORE_PAGING的DUMP
分析:
1、出现第一个MEMORY_NO_MORE_PAGING 错误,运行的是事务码ZSDRXXXX。与用户沟通,大概9:00左右程序运行结束,但之后仍有同样的DUMP.
2、使用ST02查看Page Area内存的使用历史记录,发现从12-15起,连续出现Page Area内存达到最大设置值1,048,576(单位8K).
3、与开发人员沟通,在12-15左右对程序ZSDRXXXX进行过调整,取订单配置使用了新的FM VC_I_GET_CONFIGURATION,之前使用的是VC_I_GET_CONFIGURATION_IBASE.
4、与系统管理员确认,最近没有对SAP内存管理的参数进行过调整,主要涉及rdisp/PG_SHM和rdisp/PG_LOCAL.
5、在QAS系统对事务码ZSDRXXXX进行跟踪,发现每次调用VC_I_GET_CONFIGURATION,Page Area内存增加约400K,几分钟内增大到100M以上。
6、根据关键字VC_I_GET_CONFIGURATION、MEMORY_NO_MORE_PAGING查找NOTES,通过分析notes 303138, 发现我们使用VC_I_GET_CONFIGURATION的错误。

附加说明
Paging area包含的数据:
This data includes the ABAP/4 memory (EXPORT TO MEMORY), the SUBMIT REPORT parameters, CALL DIALOG and CALL TRANSACTION USING, as well as internally defined macros (specified with DEFINE).

Comments are closed.