SAP系统慢的一些举措

  • A+
所属分类:SAP

1.SLG2 删除过期的程序日志
2.WE11 删除特定的idoc(如有几百上千个门店的情况,扩展物料的操作会导致edids增长非常快,需进行压制)
3.RSPO1041 删除SPOOL历史,如果不删除会导致SPOOL增长过快发生SPOOL_INTERNAL_ERROR的DUMP
4.RSBTCDEL2 删除过期的JOB,有标准JOB名为SAP_REORG_JOBS,调整其参数即可
5.SM37里用关键字REORG模糊匹配出所有标准作业,根据自己的情况调整参数
6.自建程序,对自定义的日志表定期进行备份并删除
7.SM66无条件干掉超过理论运行时间很久的程序,例如24小时
8.SM37无条件干掉超过理论运行时间很久的程序,例如24小时
9.HANA服务器配置当个SQL语句允许只用的内存,超过内存限制立刻DUMP(SYSTEM登录到对应的租户,配置>global.ini>memorymanager)
10.RSMEMORY设置APP内存占用限制,达到配额立刻DUMP
11.做Client Copy之后,立刻删除/usr/sap/trans/data下对应的export文件,否则传输目录很容易撑爆
12.传输请求一直无法完成(状态一直进行中),ps -ef | grep tp,无条件kill掉对应的进程,千万别敲错进程号!!!
13.AL08出现大量状态为PPIV的进程,可能是用户没有使用组登录、都登录到一台APP上了,给用户配置组登录,正确使用负载均衡
14.DB13每天查看增长过快的表、数据库使用的内存及硬盘空间增长情况,预测需要增加硬件配置的时间、提前采取有效的行动
15.SM66查看有无大量HTTP_WAIT,有时候和SAP对接的外部系统贼拉慢的时候,可能会把SAP也拖慢,尤其交互的模式是同步时(例如你给OMS发了一条数据,一直等待OMS返回状态,OMS一直不返回,你一直等,会导致大量HTTP阻塞通道,最终拖慢SAP)
16.系统很快,但有些事务代码很慢,可能有的程序写得确实有问题、包括标准程序(最近的标准程序代码质量似乎下降了,bug贼拉多),去优化看看
17.CDS别JOIN太多层
18.登录数据库看下有没有因为内存不足导致的UNLOADS,如果频繁发生UNLOADS会导致数据库服务器频繁在内存和硬盘之间大量读写数据,用户大部分时候从硬盘SELECT,不慢才怪
19.看下ST22和IDOC是不是有大量报错,有大量报错的时候很容易把数据库撑爆、堵塞通道,进而拖慢系统
20.有时候可能是网络问题,特别是服务器不在公司的情况,你要相信网络提供商宣传的5A、99%都只是面子话,实际上搞不好在运维机房或专线组件的人就是你某个不怎么上进的高中同学(调侃下),二狗心情不好K个进程、重启下交换机这种操作在目前的国内商业环境下应该不足为奇吧(不然也不会发生某云删别人公司数据的案例了)
21.极端情况下,可能服务器的硬件出问题了,别以为不可能,主板烧了、硬盘挂了这种事情我都是遇到过的,还好有备份和HA
22.当然,感觉系统慢,很有可能只是你自己慢,记得把SAP GUI的补丁打一下、电脑配置太低的话换台跟得上时代的、用router不行的话试试VPN
23.如果做了什么变更、新安装了什么RPM包,监控下

系统慢这个话题,其实分析起来非常复杂,是一个系统工程,涉及程序、服务器、数据库、操作系统、硬件、网络的方方面面,任何一个环节都有可能导致系统慢。
功夫在平时,有空的时候多熟悉SUSE、HANA、SAP Application、ABAP、SAP Library上的那些指南,操作系统原理及基本的网络、计算机组成原理也要知道的。
真出问题了,也不要慌,冷静的分析问题,按照平时积累的经验和知识、方法论去排查,必要的时候要果断的采取一些措施避免更大的损失发生,多查资料、内部外部多渠道同步分析问题。

发表评论

:?: :razz: :sad: :evil: :!: :smile: :oops: :grin: :eek: :shock: :???: :cool: :lol: :mad: :twisted: :roll: :wink: :idea: :arrow: :neutral: :cry: :mrgreen: