简介SAP BASIS日常运维精讲文档面向SAP系统管理员与运维工程师系统梳理了BASIS日常工作的核心模块包括用户权限、集团管理、数据库维护、后台作业、打印管理、系统监控与传输管理等场景的常用事务代码。压缩包内为一份2.02MB的PDF共1个文件属于科莱特SAP内训资料内容紧凑、便于速查。文档以实际操作为导向详细列出了SU01、PFCG、SU53等权限相关代码SM36/SM37后台作业管理DB13/DB02数据库监控ST06/SM50系统性能与进程查看以及STMS传输管理等关键命令的用途与使用时机并补充了启动日志、进程日志、传输日志的典型查看位置。对于需要快速掌握SAP系统日常巡检与常见维护操作的读者这份资料可起到清晰的入门引导和速查手册作用。目前已有960人浏览学习适合作为BASIS新手及运维人员的随身参考。1. SAP日常运维BASIS是什么系统没告警之前运维先行的活儿清晨第一件事是打开AL08、SM50、SM37三个事务码然后才碰咖啡。你要是把这句话读懂了就明白SAP日常运维BASIS到底在干什么——它不做需求、不写业务逻辑但对“用户能不能正常登录、后台作业有没有半夜翻车、传输请求能不能顺利到生产机”这套东西负责。说得直白一点BASIS就是那台SAP系统的守夜人和黑匣子记录员。这个岗位的日常工作绝不是“按下F5看彩灯”。真正见过生产系统的人都清楚磁盘空间告警、打印假脱机堆积、RFC断连、权限泄露这些事从来不会提前预约。BASIS的日常是每天用事务码把系统的脉搏摸一遍进程是否积压锁条目是否异常传输队列是否堵住然后在该动手的地方动手在翻不了车的地方提前放一道护栏。适合谁读刚接手SAP系统运维、被分到BASIS方向的同事或者做功能顾问、开发顾问但经常兼任系统维护的人。下文提到的每个事务码、每个操作次序都是能直接照着做的不是从教科书里抄出来的宽泛原则。2. 巡检节奏与监控数据从SM50、AL08到ST02该看什么别漏什么日常运维的底子不是知识广度而是巡检顺序。BASIS不像开发能靠一个增强点做出亮点BASIS的价值在“不变”在系统最需要你的时候你能在五分钟内说清楚当前是哪个环节出了问题。所以我的建议是把巡检动作固定下来顺序也别天天改先看进程再看会话最后看缓冲和数据库。2.1 早巡的前三把钥匙SM50、SM66、SM12SM50看的是当前应用服务器的工作进程状态。进入事务后你会看到对话进程、更新进程、后台进程、假脱机进程各自的CPU时间、程序名和状态。程序名是判断问题最直接的线索如果列里长时间卡着某个ABAP报表程序比如Z开头的报表或者报错显示“PRIV”状态说明这个进程被某个程序占用了独享模式别的用户在这台服务器上会明显感到点击变慢。“PRIV”状态是BASIS新手最容易忽略的坑。它表示对话进程被程序独占常见触发场景是用户在前台直接跑大报表后下载Excel或者做了不规范的ALV导出。现象是其他用户登录同一个系统实例时有时会一直转圈但SM50里没有红色告警。处理办法也不复杂选中这条“PRIV”进程用菜单“进程→结束”强制终止但要注意未提交的数据会丢最好先通过电话或消息确认一下是不是真有业务正在操作。SM66是全局工作进程监控一次看整个系统所有应用服务器实例的工作线程。生产环境通常是多实例架构单看SM50容易漏掉另外一台机器上的拥堵。SM66里红色高亮代表工作进程不可用如果只是某一个实例的进程耗尽优先看看那台服务器是不是被某种批处理作业堆满了。此时最忌讳的就是直接重启实例先把SM66里卡死的进程杀掉观察五分钟再判断要不要重启。SM12是锁条目监控。锁条目本身不等于异常正常业务也会产生短时锁定但如果在SM12里看到大量同一用户、同一事务的锁条目积压时间超过一两个小时说明业务流程被异常中断了。常见的元凶是用户在前台操作时网络断掉或者程序中途抛出短转储锁没有正常释放。清理前先看“锁对象”字段比较安全的是找到对应的事务代码确认不是正在跑的关键业务后再逐条删除。2.2 用户会话与后台作业AL08与SM37的配合AL08显示当前登录用户列表做BASIS的应该养成每天早上看一眼的习惯。注意别只看用户数要看会话时长和登录分布。正常情况下一线用户登录后很快进入具体事务如果某几个用户名长时间挂在同一个会话上状态又在“外部命令”之类的位置不变化就要警惕是不是会话没释放、连接被占用。这种情况在SAP GUI 810客户端换版本的时候尤其常见老客户端升级后有时会残留旧连接。AL08的值不在于你能说出当前有多少人而在于你能快速定位“谁在拖慢系统”。我一般会把AL08和SM50结合起来判断如果某用户占用多个会话同时SM50里他的对话进程CPU时间持续增长那大概率是他在跑大查询如果AL08里会话量不大但系统响应慢问题就不在用户层在数据库层。此时再转去DB02和ST04而不是继续在AL08上纠结。SM37是后台作业监控的重头戏。日常运维里用户抱怨最多的问题之一就是“昨天晚上那个作业到底跑没跑完”。进SM37作业选择屏幕按用户名、作业名、日期区间查重点看状态为“已取消”或“已终止”的作业。这里有一个血泪经验状态显示“已完成”不代表业务结果正确有些后台作业主作业正常结束但调用的子步骤返回了错误状态看起来还是完成。翻作业日志一定要点进去看最后一个步骤的返回码和消息文本别只看列表。2.3 缓冲区与数据库ST02、DB02、ST04的读法ST02是SAP缓冲区监控界面里能看到表缓冲、程序缓冲、日历缓冲等条目。日常运维不需要背所有参数抓两个指标就够表缓冲命中率整体最好在95%以上程序缓冲命中率在90%以上。如果发现命中率往下掉先找谁在刷表可能是某个新上线的报表没有按规范加数据库索引导致大量全表扫描把缓冲挤掉了。ST02里还能看缓冲命中率不高时的“直接读取次数”这个数字越大数据库压力越大。DB02在Oracle数据库时代非常实用现在HANA数据库的系统里位置被DBA Cockpit和HANA Studio替代了但看的方向一致空间使用率、数据文件是否接近上限、是否有表空间进入自动扩展失败。常见翻车现场是OS层磁盘还有一半DB02里某表空间已经满到不能分配新区业务一保存就报“无法扩展段”。这类问题往往不是SAP配置错了而是前期表空间规划没留够增长余量。ST04是数据库性能监控的入口重点看数据库CPU和等待时间。如果数据库CPU长期超过80%应用层再怎么优化都白搭得跑到数据库层面找慢SQL和锁等待。日常运维里我的习惯是每天早上在ST04里截一张图存档连续三天数据变化趋势比单次绝对值更有用。这个习惯花不了两分钟但遇到性能问题时历史快照能帮你少走半天弯路。提示巡检记录不要求格式统一但至少记录当日服务器进程数、后台作业失败数、缓冲命中率、数据库空间这四个数字形成自己的基线。3. 用户与权限维护SU01建号、PFCG配角色、SUIM查高危权限权限问题是BASIS被业务找得最多的一类需求。新员工入职要建号离职要锁号老员工换岗要调角色功能顾问改配置发现缺权限……用户与权限维护做得好不好直接影响业务对运维的评价。这一章的思路是建用户名要找模板角色配置要懂菜单和授权对象的区别查权限要用SUIM而不是进SU01一个个翻。3.1 SU01建号与模板复制的惯例SU01是用户主数据维护的入口。新建用户时必填项包括用户名、姓名、别名、有效期、密码密码要满足系统密码策略一般要求大小写加数字。更重要的不是这些基本字段而是“用户组”和“默认打印机”。用户组用来决定SU01里谁能看到这个用户生产环境建议按部门或团队设置独立用户组方便以后批量锁号和批量导出。实际做法中我不建议每次从零建。更稳的做法是先在系统里建一个模板用户比如“Z_TEMPLATE_BASIC”分配好基础权限和默认打印机、默认格式然后新用户时用SU01的“复制用户”功能从模板复制出来再改细节。复制用户时注意地址数据和参数文件会一起复制过来但角色记录不会自动带入需要在角色页签里手动分配。复制之后务必检查一下“登录数据”里的密码有效期避免新用户上线第一天就因密码过期被锁。离职锁号和删除是权限运维里最容易失控的环节。我的习惯是员工离职当天先用SU01勾选“锁定”并设置未来过期日期而不是直接删除用户因为删除用户会导致历史凭证、工作流任务、审批记录全部失去可追溯性。确需清理时要等审计追溯期过后再处理至少保留一年。3.2 PFCG角色配置菜单、授权与组织级别的三角关系PFCG在ECC时代就是角色维护的核心到了S/4时代依然是同一套逻辑。创建角色时界面上有两个容易混淆的页签“菜单”和“授权”。菜单页签决定用户登录SAP GUI后能看到的入口授权页签决定用户实际能执行哪些操作。功能顾问经常犯的错是只改菜单不加授权结果业务登录后菜单能看到点进去就报权限不足反而比不加菜单更让人恼火。授权页签里最核心的操作是“变更授权数据”进入后按事务代码或授权对象维表逐项勾选。这里必须理解“组织级别”的概念比如公司代码、工厂、销售组织这类字段授权对象里如果留成“*”代表全部但很多公司不希望普通用户看到所有公司代码就要在这里按具体值分配。组织级别分配错是权限故障的高发点现象是用户能进某个事务但保存时报“权限对象S_BUKRS未分配”排查时把组织级别改成对应的公司代码值就好。角色建完不是终点必须激活和生成参数文件。激活后要把用户分配到“用户”页签让角色成为该用户已分配角色这样SU01里用户的“角色”列表才会有效。这里有一个经验修改已有角色的授权后即使重新生成了参数文件在线用户也不会立刻生效因为用户主记录的授权缓冲有刷新时间。想让用户立即生效要么等待缓冲过期要么在SU01里对该用户做“比较”并手工刷新授权或者让用户重新登录。3.3 SUIM权限搜索查谁有S_DEVELOP、谁用了LSMWSUIM是权限信息检索的入口相当于权限领域的“审计工具箱”。日常运维里最常用的场景是查“谁拥有开发权限”。在SUIM里选“按事务分配的用户”输入SE38或SE37就能看到所有能打开ABAP编辑器的用户。这个结果里往往躺着几个业务部门的“超级用户”定期拉出来清理是很必要的。还有一类问题是用户拿LSMW做数据导入。LSMW本身不是开发工具但有数据覆盖风险权限对象里也有专门控制它的开关。用SUIM查谁拥有LSWM相关权限能防止有人通过LSMW把测试数据灌进生产。同理SE14是表数据维护和删除的工具如果普通用户有SE14权限等于给了别人一把直接改数据库的钥匙这类权限要连同S_DEVELOP一起定期审计。权限审计不只是“查了就行”更要有后续动作。我通常的做法是每个月首周跑一遍SUIM导出一份有SE38、SE14、SM12这些事务代码权限的用户清单发给部门负责人确认。“权限越大责任越大”这句话在SAP里是真的一旦有人误操作BASIS是第一责任人因为权限是你发出去的。提示生产环境要严格控制用户组不要把所有人放进同一个用户组否则离职清理时根本分不清哪些用户是哪个部门的。4. 传输与变更链路请求号、STMS和多客户端逻辑系统的日常把关传输系统是SAP运维里最容易被低估的一块。开发改完程序配置改完后台表都要靠请求号运输。传输一旦堵住或顺序错了轻则功能表现异常重则生产数据被覆盖。这章把请求号和传输链路的日常流程讲清楚。4.1 请求号的出生与释放SE09/SE10的使用习惯SAP的变更对象会归入请求号。日常工作流是开发或顾问在系统中修改程序、表、配置系统创建任务自动挂在请求号下完成后再由责任人释放请求号放入传输队列。这里要分清SE09和SE10的关系通常SE10用来处理工作台请求和定制请求的释放SE09是请求号的维护入口包括删除、变更属性和查看对象列表。我的习惯是建议团队在释放请求前打开SE09双击请求号在“对象列表”页签里逐条确认改动对象。经常出现的问题是一个请求号里带上了无关的对象比如GOING就顺手改了一个开发机的用户参数结果这个对象被一起带进生产轻则多一次不必要的导入重则覆盖了生产环境手工做的配置。释放之前做一次对象清单检查五分钟的事能省掉后面一堆麻烦。请求号的命名和描述也有讲究。描述字段要按“开发编号内容简述”来写比如“ZDEV-20240501-物料主数据批导程序”。这个描述会跟着请求号传到生产环境传输记录里写清楚后面追溯变更时才不会靠猜。这属于纯管理动作但BASIS要带头做。4.2 传输路由与导入队列STMS里怎么控制QAS→PRDSTMS是传输管理系统进事务后先看“系统概览”确认DEV、QAS、PRD三个系统连接正常状态显示绿灯。传输路径一般按DEV→QAS→PRD的顺序配置但生产环境导入往往不是自动放行的需要在STMS的传输层里设置“PRD需要审批”。这样当开发或顾问释放请求号后请求会停在QAS导入队列里等BASIS确认后再导入PRD。日常运维中STMS最常见的堵点是请求在QAS导完但PRD导入队列排队出现依赖问题。比如QAS里导入顺序是A→B→C但开发释放时把C先释放了STMS会提示C的请求依赖A和B无法导入。此时要回到SE03或SE10里查看对象清单确认依赖关系不能强行调顺序。强行导入缺少前置的请求生产环境会出现“程序包含的对象不存在”这类运行时错误这时候再去补前置请求就更被动了。导入PRD前我一般会在STMS里点开每个请求的对象清单把涉及生产自建表Z开头对象重点标红确认这些表的字段变更是否兼容现有数据。比如增加字段没问题但修改字段类型或长度就要评估历史数据的影响。传输不是搬运工传输是变更控制的一部分。4.3 传输失败与回滚SE03、SE14的边界传输出错在运维中不可避免重要的是别慌也别乱删请求号。某个请求导入时报“短转储”或“对象被锁定”第一步是查看STMS的导入日志找到对应的“导入步骤”和错误消息。多数情况下是目标对象被其他请求锁住或者目标系统里已有同名对象。这种错误通常不用回滚等锁释放后重新导入该请求即可。如果确实需要“后悔药”比如请求号里带了不该带的对象且已经被导入PRD就需要用SE03来处理。SE03可以删除请求号中的对象也可以修改请求属性但要注意已经导入PRD的请求号最好不要再从传输目录里物理清除否则历史记录会断。正确做法是在开发系统中创建一个新的反向请求把不需要的变更改回来再走一遍传输链路。这个流程要解释清楚不然业务会以为删掉请求号就是后悔药。SE14是表数据维护和删除工具很多顾问把它当成“清理测试数据”的方便途径但SE14能直接和数据库交互错删数据或者重新整理表时锁表会造成业务大面积阻塞。BASIS日常运维里对SE14的权限要非常谨慎尽量不要把这个事务码配给业务顾问。如果确实要清理某个自建表的数据优先用ABAP程序或SE16N的删除功能而不是SE14里的“删除数据库表数据”。4.4 逻辑系统与RFC对象跨系统连接的日常检查跨系统接口是运维里最“黑匣子”的部分。SAP与外围系统通信依赖RFC目标和逻辑系统。逻辑系统是SAP系统在ALE/IDoc中的一个逻辑名称一个物理系统里的不同客户端还可以配置不同的逻辑系统。配置逻辑系统主要通过SCC4和SALE完成日常运维里不需要天天改但要清楚每个客户端对应的逻辑系统名称否则IDoc发不出去排查起来会走弯路。SM59是所有RFC连接的管理入口。外部系统接SAP比如工厂自动化里常见的SECS/GEM设备对接、EAP系统调用SAP接口都会在SM59里配置一个TCP/IP类型的RFC目标。日常检查时逐个目标点“连接测试”看是否返回“连接成功”。如果连接失败先看报错码再检查网络端口和账号密码别一上来就重传配置。SAP系统之间做RFC还要检查目标系统的主机信息和登录用户是否有S_RFC权限权限不足时表现和网络故障很像光靠ping是看不出来的。外部服务用NW RFC SDK联调时特别注意版本匹配。SAP GUI 810对应的RFC SDK版本较新如果外围系统用的是老版本SDK握手阶段可能直接失败。遇到这类情况先确认双方库版本再看ABAP端报错最后才怀疑网络。把顺序搞反问题能在你手里转半天。5. SAP日常运维避坑打印假脱机、磁盘占满、RFC断连与锁死块的四个现场这章挑四个真实生产环境反复出现的故障现场按“现象→原因→解决”写清楚。每一条都是踩过坑后的经验结晶照着排查能省下大量时间。5.1 SP01打印假脱机请求卡死现象用户在前台打印采购订单或财务凭证点打印后没有反应或者在SP01里看到假脱机请求状态一直是“挂起”“等待”或“错误”。更典型的是报“无法达到远程组机的假脱机关系”这个错误在打印服务器和前端打印组件之间网络抽风时特别常见。原因打印请求生成后SAP把数据写入假脱机文件再交给操作系统打印队列。假脱机文件本身没问题但输出设备映射错误、打印机名称变了、前端打印组件端口被占用都会导致任务卡在假脱机层。还有一部分原因是用户在打印时选择了已停用的输出设备或者在事务码SPAD里输出设备的主机假脱机访问字段填错。解决标准流程分三步。第一步在SP01里选中卡住的假脱机请求先“退出”再“删除”把假脱机表的脏数据清掉第二步用SPAD检查输出设备确认设备类型、主机假脱机名称和数据格式缺什么补什么第三步如果卡的是大量历史请求用事务码SP01的“重新组织”功能清理过期假脱机数据这个操作建议定期做能在打印高峰前释放假脱机表压力。注意清理假脱机请求不影响已经打印完成的单据记录不是删凭证不用怕。5.2 磁盘满导致系统挂起现象系统整体响应变慢所有用户操作都像“卡死”但SM50和ST02看起来并不离谱。到OS层执行df -h发现/usr/sap/trans或/oracle目录空间显示100%或者数据库数据文件所在分区余量只剩几个GB。原因最常见的是传输目录/usr/sap/trans下堆积了大量请求文件特别是长期不清Cofiles和Datafiles其次是数据库的归档日志或告警日志增长过快比如数据库短转储后生成了好几个GB的trace文件还有一个隐蔽原因是SAP系统缓冲区文件在/usr/sap目录下异常膨胀。磁盘满之后数据库无法写入临时段后台作业大面积失败界面操作也会连带报出一般的R3错误。解决先把释放空间的优先级定清楚。第一优先是清理传输目录用事务码STMS里的“传输目录”选项查看各文件数量确认ABAP dump、日志文件可以直接删除的按时间分批清理掉第二优先是清理数据库告警日志和trace在OS层找到diag目录后按日期删除最后还要查一下表空间剩余DB02显示空间足够不代表OS层分区足够两边要对齐。清完结后建议把SAP的“归档管理”检查一遍配置归档作业避免日志无限增长。5.3 RFC调用失败与外部系统集成现象业务用户报“MIGO过账增强报RFC失败”或者外围系统调用SAP接口时提示“在RFC目标XYZ中未找到授权”。运维排查时发现SM59连接测试报“通信故障”但网络配置看起来全对。原因这类问题通常不是单一原因。最常见的是RFC目标指向的主机或端口已经变更比如外围系统服务器重装后IP变了SM59里的目标主机没同步更新其次是RFC用户的S_RFC权限不足这个问题在老系统上特别明显ECC环境里权限对象检查严格给RFC用户分配的角色少了一项授权第三类是外部Java系统使用NW RFC SDKSDK版本与当前SAP NetWeaver不匹配连握手都过不去。解决先看SM59输入RFC目标点“连接测试”看返回消息。如果返回“连接成功”权限问题的可能性变大用SU01检查RFC用户再用SUIM按对象S_RFC查权限清单如果返回“无法连接”用网络命令查目标主机和端口确认防火墙放行。再往上走检查外围系统的MID Server或SDK版本查看SAP的NW RFC SDK对应关系。这里最忌讳的是“怀疑网络就重启系统”先把问题范围缩小到SAP侧还是外围侧再动手。5.4 锁条目堆积与死锁现场现象用户在保存主数据或凭证时报“锁定条目已存在”或者在SM12里看到某个表有大量长时间未释放的锁。严重的时候后台作业互相等待形成死锁SM50里出现多个作业状态卡在“运行中”但CPU不增长。原因锁条目没有被正常释放的原因很多包括程序短转储、用户异常掉线、后台作业在COMMIT前被终止。最常见的是程序里没有做COMMIT WORK锁对象随程序结束也没有释放。死锁则一般是作业A锁表X等Y作业B锁表Y等X两边都不让步数据库和SAP层都无法自动解除。解决SM12里逐条查看锁条目先看“锁定用户”和“程序名”。如果程序名是SAP标准程序但用户早已退出直接删除锁即可如果是正在运行的批处理作业要找到对应作业并取消再删除该作业持锁的条目。处理死锁时先把SM50里两个作业视图调出来确认是哪两个程序互相等待选一个优先级低的作业杀掉锁会自动释放。切记不要同时杀两个作业两个都回滚反而可能拖慢数据库。清锁之前养成在群里问一句的习惯确认没有人在前台正在跑这笔业务误删活动锁会让用户事务直接回滚这个坑我踩过不止一次。6. 把巡检沉淀成常备脚本SM36变式与后台作业监控清单日常运维最怕的是每天重复做手工操作时漏掉一步。我建议把早晚巡检动作做成SM36的后台作业定时跑日志留痕第二天打开SM37看一下结果就能闭环。后端软件的监控作业可以这样规划用一个后台作业步骤类型选“ABAP程序”程序名填RSPO0041假脱机请求清理变式在SM36里保存为清理策略比如清洗三天前的已完成假脱机请求。再配一个作业监控数据库表空间可选程序DBACOCKPIT或RZ20里的CCMS告警把输出保存为日志。变式命名用Z开头方便以后识别。实际执行时作业里可以分段写监控步骤每个步骤对应一个程序变式并在SM36的“作业有关信息”里设置通知用户告警邮件直接发给BASIS组。这一步的价值在于如果你当天休假第二天回来能通过SM37快速看到前一天所有作业的状态再配合历史请求监控表就能把“事后补救”变成“事前告警”。-- 查询近24小时后台作业执行情况TBTCO为后台作业头表 SELECT JOBNAME, JOBCOUNT, SDLU, STATUS, SDLD, ENDDATE, ENDTIME FROM TBTCO WHERE SDLU SYSDATE - 1 AND SDLU IS NOT NULL ORDER BY SDLU DESC;这段SQL可以直接用SE16N或者SE38里的ABAP查询执行器跑也可以放到自定义报表里定时输出。STATUS字段为“F”代表已结束“A”代表已取消非F或A的状态通常就是“计划中”或“正在运行”说明作业还没跑步结束需要结合结束时间判断是否异常。我自己的习惯是每周五下午做一次周末传输队列预检打开STMS把所有排队中的请求号过一遍确认不是下周要上线的开发被提前释放到了PRD队列每个月再跑一次SUIM权限清单把超维和高危权限用户发给各模块负责人确认。这套节奏能帮你把日常运维从“救火”变成“防火”。做BASIS的时间越长越会发现系统本身比大多数流程稳定真正不可控的是人——误操作、忘了释放、配置改了一半。运维的价值不是等出故障来展示能力而是让人感觉不到故障存在。这个方向值得投入希望今天的这些事务码和操作次序能给你的SAP日常运维BASIS工作补上一块有用的拼图。本文还有配套的精品资源点击获取