ST22 DUMP SPOOL_INTERNAL_ERROR处理措施
问题表现
- ST22迅速产生大量SPOOL_INTERNAL_ERROR类型的DUMP
- 系统所有操作均无法执行
- 大量后台作业delay或者取消
- 系统非常卡顿
- 传请求一直在传输中
原因分析
ST22产生大量SPOOL_INTERNAL_ERROR类型的DUMP,说明SPOOL队列满。SAP假脱机队列有一个NUMBER RANGRE,默认最大值是32000,一旦假脱机超过这个值将会产生上面的DUMP。
当务之急
此时系统已经处于拒绝服务的情况了,所以必须用特殊手段使系统先恢复正常,那么需要快速删除假脱机日志,释放NUMBER RANGRE。运行程序RSPO1041可迅速删除假脱机,挽救系统。
长期策略
1.提高SPOOL的NUMBER RANGRE范围
需登录000 Client操作,其他Client操作无效。
2.设置后台作业定期清理过时的SPOOL
3.加强对系统的监控,一旦出问题能第一时间跟进处理
提高SPOOL的NUMBER RANGRE范围的操作
1.登录000 Client,必须是000 Client
2.SNRO修改SPO_NUM的当前值为32000
3.修改NUMBER RANGE的截止值,根据需要调大一点,超过99000将会影响系统性能,这里需要权衡
设置后台作业定期删除SPOOL的操作
标准JOB:SAP_REORG_SPOOL 调用的是RSPO0041这个标准程序,事实上这个程序并没有什么用.
SAP提供了另外一个标准程序:RSPO1041,这个程序可以如下设置参数条件并保存为一个变式. 然后用这个程序替代RSPO0041.
这个程序在Notes 130978中有介绍,其中就介绍了这个程序是用来替代RSPO0041的 .
自定义变式
上图红圈中的参数很重要,意思是删除不需要打印(即不是用过smartforms等打印函数产生的假脱机信息,例如是通过SM37定义的作业write出来的alv清单、日志等内容)的假脱机信息,其实正是这些信息占用了大量资源。
由于我们各种接口、任务太多了,1小时清理一次有可能spool骤满之后清理spool垃圾的程序都无法正常运行,因此调整为半小时执行一次。
注意,作业变式中的天数是指当前时间和作业创建时间之间的差异,所以只要时间相减满足条件就会删除(而不是傻傻的一整天)。
相关知识
记录假脱机日志的主表,TSP01和TSP02,TSP01里的每一行代表一次打印,有的一次打印可能有几百几千行,所以当这个表里有上万行数据的时候可能意味着后台有上百万的假脱机日志,会导致系统非常慢。
SP01输入假脱机编号就能查询对应的打印信息
其他补充
SAP官方关于扩展假脱机号码段的说明:Extending Number Assignment
如若转载,请注明出处:https://www.gavindong.com/4927.html