拓冰网站定制 
简介面向SAP系统管理员与BASIS运维人员的日常运维速查手册内容紧扣SAP BASIS核心工作覆盖用户权限管理SU01、PFCG、SU53、集团管理SCC4、SCCL、SCC1、数据库日常维护DB13、DB02、BRTOOLS、后台作业调度与监控、打印管理SPAD、SP01、系统运行监控ST06、SM04、SM21、ST22以及传输管理等高频操作场景同时附有启动日志、进程日志、传输日志和数据库日志的常用路径并说明如何通过日志分析定位异常。资源为单个PDF文档体积仅2.02MB便于随时离线查阅已有960人学习适合初入行的BASIS学员系统入门也适合在职运维人员作为日常命令速查工具。内容基于科莱特SAP内训材料提炼对每个事务代码的适用场景、操作要点和注意事项均给出简明提示可直接用于日常巡检、问题排查与新人培训。1. SAP日常运维BASIS先搞清这套系统你到底在维护什么做 BASIS 运维的都有过这种经历周五下午用户群里突然有人喊“系统卡得点不动了”你打开 ST03N 看负载数值不高数据库响应也在正常范围但用户那边就是转圈圈。这种“说不清道不明的卡”最磨人也正是 SAP日常运维BASIS 这个岗位存在的意义——SAP 系统不是装完就能一直安稳跑下去的应用服务器、数据库、打印假脱机、后台作业、传输请求、权限账号每一块都可能成为故障点。BASIS 干的活通俗讲就是让 SAP 这套业务系统“活着、快着、不乱”。从每天上班打开 SAP GUI 那一刻开始你要确认系统还能不能登录、后台作业有没有挂、队列有没有堵、数据库空间够不够再到开发往生产传请求时别把别人的程序覆盖掉新员工入职要开账号、离职要收权限补丁版本要按序打。这些工作不直接产生业务价值但任何一环出问题财务月底结不了账工厂跑不了 MRP生产计划全打乱。这篇笔记我按日常巡检、传输管理、权限控制、高频故障排查和进阶调优五个方向展开把我做过的方案和踩过的坑整理成能直接照做的步骤。适合谁看负责单个 ECC 或 S/4HANA 系统的内部顾问、刚接手 SAP 系统管理的运维工程师以及准备从业务顾问转 BASIS 的同事。开发相关的内容我只在排错时涉及不会往 ABAP 代码层面深入。2. 把系统状态摸清楚巡检指标、事务码和第一反应2.1 每天的第一个动作用这些事务码和命令确认系统还活着我对“日常运维”的定义很简单每天早晨的第一件事是确认系统从数据库到应用层都是健康的。不要等用户来报障才看系统那是救火不是运维。在 Linux 环境下的 SAP 实例我习惯先用 sapcontrol 这一组命令把实例状态扫一遍# 查询当前实例的进程状态判断 AppServer 进程是否全部拉起 sapcontrol -nr 00 -function GetProcessList # 查看实例整体运行状态返回 RUNNING 才说明实例可用 sapcontrol -nr 00 -function GetInstanceStatus # 查看分发队列长度队列积压严重时业务操作会明显变慢 sapcontrol -nr 00 -function GetQueueStatistic-nr 00是实例号ECC 和 S/4HANA 常见的实例号是 00如果一套机器装了多个实例就按实际的实例号切换。GetProcessList 返回的每个进程都带状态GREEN 表示正常YELLOW 表示受限GREY 表示进程没起来比如 dispwork 变灰了用户基本就登录不上了。GetQueueStatistic 这个命令很多人不常用但它在排查“系统没报警但是业务慢”的场景特别好使——队列长度持续往上涨说明工作进程处理不过来请求全堵在队列里。GUI 层面SM50 看当前实例的工作进程占用SM66 跨实例看全局工作进程SM37 看后台作业状态SM13 看数据库更新请求有没有报错SM04 看在线用户。这些事务码是 BASIS 的“仪表盘”每天早上花五分钟扫一遍比事后看 ST03N 的负载统计有用得多。SAP GUI 客户端本身也值得注意前几年很多人还在用 7.x 的旧版新装环境已经普遍到 8.10 甚至更高客户端版本过旧会导致部分事务显示异常登录报错先看 GUI 版本不是玄学真遇到过好几回了。2.2 巡检指标不要拍脑袋把负载、队列、数据库卡点设成一张表很多刚做 BASIS 的同事巡检没有章法登录系统后东点点西看看最后啥结论都没有。我建议把巡检固化成一张表列清楚检查项、工具、阈值和异常处理动作这样新手照着做也能上手。检查项工具/事务码阈值参考异常处理动作工作进程利用率SM50 / SM66DIA 进程占用持续 90% 以上超过 10 分钟用 ST05 跟踪慢事务检查是否有低效 SQL后台作业失败率SM37每日失败数量超过 5%逐个查看作业日志按第 5 章方式排查缓冲区命中率ST02低于 90%检查是否频繁发生缓冲区交换必要时调大缓冲数据库平均响应DBACOCKPIT超过 50 毫秒检查数据库锁表、慢 SQL、表空间状态磁盘使用率df -h / sapcontrol达到 85% 需要关注清理日志目录扩展文件系统假脱机队列深度SP01积压任务超过 200检查打印机设备状态清理异常输出请求如果你们的系统跑 MRP还要额外关注 MD07 这类物料需求清单事务在计划员高峰期的调用频率。它本质上是大量读视图的报表在计划跑批时段集中操作会明显拉高数据库负载我见过不止一次因为计划员盯着 MD07 刷新导致 DB 响应变慢的情况。处理方法不是禁止用户看而是错峰操作或者在后台跑批完成后再开放高频访问。巡检数据沉淀下来之后下一步是让它变成告警而不是报表。常见的做法是写脚本定时调 sapcontrol 和数据库接口把异常状态推到企业微信或者钉钉机器人。脚本写法在第 6 章会给出一个可用的框架这里先不展开因为很多团队第一步连手工巡检都没跑顺直接上自动化只会增加一个没人看的告警群。3. 请求传输从释放到落地SAP 变更的“高速公路”3.1 传输链路与 TMS 配置开发请求怎么安全到达生产业务顾问在开发机改一个程序、配一个逻辑系统这个变更要交付生产中间靠的就是请求Transport Request。我见过太多刚转 BASIS 的同事把请求传输理解成“拷个文件过去”实际完全不是一回事。一个变更对象从创建请求开始到可修改、已释放、已导出、已导入中间要过传输路线Transport Route和传输控制系统TMS。常规流程是这样开发顾问用 SE09 或 SE10 创建并维护请求请求底下挂若干任务Task每个人改完自己的部分后释放任务最后发布者一起释放整个请求。请求释放后进入 TMS 队列按配置好的传输路线进入测试系统测试确认没问题后再传输到生产。这条链路里SE03 负责请求相关参数的调整STMS 是传输控制台SCC1 可以直接在目标系统导入请求。请求本身分工作台请求和传输请求两类有时候还涉及定制请求。我的建议是新手上路先分清请求和任务的关系不要直接在一个请求下拉人进来乱改。很多权限类的配置比如 PFCG 里的角色也会放进请求里传输所以传输队列不只是开发代码权限变更也走这条路。3.2 传输翻车的三个高频原因和对应处理第一类是依赖顺序问题。典型的情况是数据库表结构还没有传到目标系统程序先传过去了导入时报对象不激活。解决思路是遇到导入失败时不要急着重传先在 STMS 里看导入日志确认是哪一个对象失败。通常是按“基础设施 → 表结构 → 程序 → 权限”的顺序分批传输而不是把一串请求一次性打进生产。如果同一批次里有多个请求用 SCC1 导入时务必保持顺序跳号传只会制造更多冲突。第二类是对象锁定。某位开发顾问在传输请求已经释放之后又在同一个对象上新建了任务导致目标系统导入时发现对象被锁定。处理方式是让顾问把未完成的任务释放或删除必要时由 BASIS 通过 SE03 调整请求包含的对象列表把不在范围内的对象移出去。这种事不要硬来先和顾问确认是否真的不需要那个对象了再动请求结构否则事后要恢复会非常麻烦。第三类是目标系统配置不对。请求在测试机队列里能看到但在生产机队列里找不到十有八九是传输路线没配好或者 TMS 里分配的目标系统错误。检查顺序是 STMS → 传输路线概览 → 查看开发机和生产机的分配关系。这套东西没有重启大法改完配置后要重新生成传输路线并在测试环境先验证一次完整传输流程。传输这块我的经验是把测试系统看成生产的前置演练场任何请求第一次进生产前先在测试机完整走一遍。三个月之后你会发现生产导入失败的次数大大减少因为大部分坑都在测试环境踩完了。4. 用户与权限从建号到回收的完整处理套路4.1 SU01 建号、PFCG 配权、SU53 定位缺权用户和权限管理是 BASIS 日常运维里频率最高的操作之一。新人入职要开账号老员工调岗要加角色离职要回收权限业务顾问时不时还会找过来说“我这边有个事务报没权限”。这些工作看着琐碎但权限给的太宽是审计红线给的太窄影响业务效率中间这个度需要通过规范的流程来把控。创建用户走 SU01核心参数包括用户类型、初始密码、密码有效期、用户组。用户类型要格外注意Dialog 类型的用户占用的许可资源最多接口用户如果也配成 Dialog既浪费许可又增加安全隐患接口调用应该用 CPIC 或 Service 类型。密码策略如果在系统层面统一配置了SU01 里就不要再单独给某个用户设置永不过期除非有明确的特例审批记录。配角色的入口是 PFCG这是 SAP 权限体系里最重要的一个事务码。角色分为单角色和复合角色单角色里挂事务代码、报表权限、授权对象值复合角色把多个单角色打包给用户。创建角色的流程一般是先在“菜单”页签勾选用户需要的事务然后在“权限”页签点击“更改授权数据”系统会根据所选事务自动生成推荐授权对象之后用 SU24 维护事务对应的默认授权对象。这一步很容易被忽略导致角色配好了但用户执行事务时依然报权限不足。用户报“没有权限”时别凭感觉给授权用 SU53 让用户在报错的事务里复现一遍SU53 会记录具体是哪个授权对象检查失败、缺哪些字段值。根据 SU53 的结果回到 PFCG 里补充对应授权对象再重新生成参数文件分配给用户这样比拍脑袋加 SAP_ALL 靠谱得多。给权限相关的事务码列一张表事务码用途SU01用户主数据创建与维护PFCG角色创建、权限配置与分配SU24事务代码默认授权对象批量维护SU53权限检查失败详细信息查看SUIM用户信息系统生成各类用户与角色分析报表SU10批量锁定或解锁用户SE14数据库表编辑工具日常账号管理慎用“万能权限” SAP_ALL 是权限管理里最扎眼的存在运维团队最好能约定一个规矩任何角色和用户都禁止直接分配 SAP_ALL 或 SAP_NEW确实需要临时高权限时走审批并设置到期日期。SAP 系统被审计出问题绝大多数都是权限过度授权导致的。4.2 离职与调岗的权限回收给审计留一条清晰的链权限回收这块我强烈建议按“先锁定、后归档、再清理”三步走不要用户一离职就立刻删账号。直接删除账号会丢掉历史变更记录后面审计要查“某个人某天改过什么”的时候数据已经没了。离职处理的标准操作当天用 SU01 把用户锁定或者用 SU10 批量锁定一批离职用户然后记录锁定时间和操作人。用户锁定后该用户下所有未释放的请求、正在跑的后台作业、分配给这个人的任务都要逐一检查有没有遗留。请求可以转给其他人作业可以重新调度但这个过程最好在一周内确认完不要拖着。季度审计是权限管理里很容易被忽略的部分。用 SUIM 跑一张“用户-角色-最后登录时间”报表把超过 90 天没有登录过的用户挑出来逐一确认是否还需要保留账号。如果业务上确实暂时用不到就锁定而不是删除后续需要时再解锁既节省许可又留了安全余地。跨系统权限比对也建议定期做尤其是开发、测试、生产三套环境之间同一业务角色的权限配置差异往往就是隐患来源。调岗人员同理先确认新岗位需要的角色再移除旧岗位的角色不要只在 SU01 里追加角色。权限配置的历史留痕要保得住建议把每周的权限变更清单导出存档放在团队共享目录里审计来的时候可以直接按时间段调出清单省得临时现查现补。5. ST22、SM37、SPOOL、数据库与补丁五个最容易让运维翻车的现场5.1 ST22 里的程序 dump先看错误分类再决定找谁处理现象用户执行某个事务时报错退出有时会弹出 ABAP 短转储的对话框查看 ST22 能看到一长串 dump 记录。原因dump 并不全是程序代码问题。TSV_T_NEW_PAGE_ALLOC_FAILED 这类错误通常指向内存分配失败可能是系统内存不足也可能是某个会话占用过多而 DATABASE 相关的 dump 往往是数据库索引失效或锁表。字符串运算、权限检查失败也会产生 dump但占比小得多。解决ST22 打开错误列表后先看“错误”栏的分类判断是哪一层面的问题。内存类先看系统资源是否充足、是否有程序并发跑太高数据库类到 DBACOCKPIT 里查锁和慢 SQL如果是明确的 ABAP 代码异常把 dump 截图发给开发顾问让他们按短转储里的程序名、行号定位。ST22 里的历史 dump 建议每季度清理一次不然堆积太多真正需要找记录时翻起来特别费劲。5.2 SM37 后台作业失败作业日志、批输入、SPOOL 要分开看现象SM37 里调度中的作业显示为完成但状态是红色或者一直停在“已计划”没执行。原因后台作业失败的原因很分散最常见的是三种。一是作业调用的 ABAP 程序本身报错二是批输入会话没有正常处理完三是作业触发时系统资源不够批处理进程被占用作业没抢到执行资源。解决从 SM37 选中失败的作业直接看作业日志日志会显示具体的错误位置。如果是批输入相关作业失败再去 SM35 看批输入会话状态很多时候是因为主数据问题导致批输入中断修正数据后重新处理即可。如果是跨系统调用的作业比如通过 RFC 调用另一台 SAP 实例还要检查目标系统的实例状态很多作业失败其实是目标系统没起来引发的连锁反应。判断依据就是作业日志、批输入会话、系统进程状态这三样按顺序查基本不会漏。5.3 假脱机 Spool 卡死用户打不出报表的第一嫌疑现象用户打印或者预览报表时卡住系统提示无法完成假脱机请求SP01 里积压大量输出请求后台假脱机进程占满。原因打印机设备配置错误、宿主机连接不上、假脱机进程数不足都会导致这个局面。最典型的是远程打印机目标不可达Spool 请求发出去了但服务器端无法建立连接请求一直挂在队列里。解决先看 SPAD 里打印机设备的配置确认输出设备类型、主机地址、端口是否正确再到 SP01 里查看输出请求状态把长时间未完成的请求手动删除或重新发起输出。如果假脱机进程全被占满在 SM50 里看 SPO 类型工作进程的使用情况必要时使用 SM51 重启实例释放假脱机进程。处理完设备问题后让用户重新打印一份测试页确认恢复正常再关闭工单。“无法达到远程组机假脱机关系”这种报错出现时优先怀疑目标打印机或打印服务器的问题不要一上来就想着调 SAP 参数。5.4 数据库表空间不足与连接中断现象业务保存单据时报数据库表空间不足或者 SAP 日志里出现数据库连接中断的记录严重时整个实例不可用。原因最常见的是数据增长超出预期尤其是凭证表、日志表、批输入表增长过快表空间没有及时扩容。其次是归档配置没做好历史数据全堆在活动表里数据库文件越来越大。解决先通过 DBACOCKPIT 查表空间使用率紧急情况下直接扩展数据文件让系统先恢复可用。之后分析是哪些表增长异常SE14 可以查看和调整表存储属性但我必须提醒一句SE14 是数据库表的底层工具调整表结构、直接删除数据这些操作一旦失误影响面极大操作前一定要做完整的表备份并且不要在业务高峰时段执行。归档策略是治本方案把历史凭证和日志定期归档到归档存储而不是让它们一直占着活动表空间。5.5 补丁与升级期 SPAM 状态机卡住现象使用 SPAM 或 SAINT 打完补丁后系统重启升级状态停在某个步骤不再推进有的补丁队列显示为等待状态。原因SPAM 升级有一个严格的状态机逻辑前一步没有成功完成后面不会自动继续。常见卡住的原因包括补丁队列没按顺序导入、DDIC 对象在激活阶段出现冲突、升级前有未完成的后台作业占用了进程资源。解决按 SPAM 界面提示的当前步骤判断不要绕过状态机强行推进。对象激活冲突时回到 SE03 或 SE14 排查具体冲突对象属于修正包范围内的对象可以单独处理如果是后台作业阻碍先释放进程再重试。升级这种事最忌讳的就是在生产环境直接试我做过一次 SAP 补丁升级因为忽略了版本兼容性结果打完后某个标准功能直接不可用回滚又花了半天。从那以后我坚持升级前先备份然后在测试机完整走一遍同样的补丁流程记录所有报错和处理方式生产环境照着执行。补丁期间的每一步操作记录都留在当天的变更日志里这是给自己留的后悔药。6. 把运维从被动变主动ST05、SE30、sapcontrol 脚本与变更记录6.1 用 ST05 和 SE30 把“慢”定位到同一条 SQL遇到用户反馈某个事务慢口头描述往往是“转圈转了好久”但这句描述没有任何定位价值。我会先让用户再操作一次同时打开 ST05 开启跟踪系统会把这次访问的所有数据库调用、表访问路径、RFC 调用记录下来。跟踪结束后按时间筛选耗时最长的操作基本就能锁定是某一条 SQL 慢还是某一个函数模块调用延迟。SE30 可以单独分析一个程序的运行时分布结合 ST05 的数据库跟踪结果就能把慢的根因定位到具体代码路径。这套方法比反复让用户复现问题高效得多也省去了“系统慢是不是网络问题”的猜测。6.2 把早检查写成脚本sapcontrol 加计划任务日常巡检可以脚本化一部分我最常用的是用 sapcontrol 配合 shell 脚本做每日健康检查异常时告警省去每天手工敲命令的重复劳动#!/bin/bash # 每日巡检检查实例进程状态统计 GREEN 进程数量异常时发送告警 INSTANCE_NR00 STATUS$(sapcontrol -nr $INSTANCE_NR -function GetProcessList | grep -c GREEN) echo [$(date %Y-%m-%d %H:%M:%S)] GREEN process count: $STATUS /usr/sap/log/system_check.log if [ $STATUS -lt 5 ]; then echo SAP instance $INSTANCE_NR process not healthy, check SM50 immediately \ | mail -s SAP daily check alert opsexample.com fi这个脚本的要点有两个一是用grep -c GREEN统计正常进程数低于预期值时告警二是把结果写入独立日志文件每天累积形成趋势。实际场景里告警的发送方式可以是企业微信机器人脚本、钉钉机器人或者邮件按团队现有的通信工具接入即可。把脚本加到 crontab 里每天 08:30 执行运维值班的人只需要等告警没告警就意味着早上这一关过了。脚本要做得可靠还要处理一个问题sapcontrol 命令路径和环境变量要在脚本里显式声明否则 crontab 执行时往往因为 PATH 不对找不到命令。这也是很多自动化运维脚本“手动跑没事、定时跑失效”的原因。6.3 给配置变更留一个“黑匣子”系统出问题的时候第一反应是看最近改了什么。这是排障的黄金法则但前提是你有记录。我现在带团队有一条硬规矩每次修改系统参数、传输请求、补丁级别、打印机配置、权限角色都要在共享的变更记录里写一行内容包括变更时间、操作人、变更内容和影响范围。这个习惯养成了排查问题时打开记录一看大概率心里就有数了。好的 BASIS 运维不是靠记性而是靠留痕。系统配置的变更记录就是你的黑匣子平时看着不起眼出问题时它就是最快找到根因的路径。这行记录不需要多复杂Excel 表格、企业微信文档、SAP 备注都可以关键是坚持记。希望帮到你。本文还有配套的精品资源点击获取 SAP BASIS日常运维实战：巡检、传输、权限与故障排查要点
简介面向SAP系统管理员与BASIS运维人员的日常运维速查手册内容紧扣SAP BASIS核心工作覆盖用户权限管理SU01、PFCG、SU53、集团管理SCC4、SCCL、SCC1、数据库日常维护DB13、DB02、BRTOOLS、后台作业调度与监控、打印管理SPAD、SP01、系统运行监控ST06、SM04、SM21、ST22以及传输管理等高频操作场景同时附有启动日志、进程日志、传输日志和数据库日志的常用路径并说明如何通过日志分析定位异常。资源为单个PDF文档体积仅2.02MB便于随时离线查阅已有960人学习适合初入行的BASIS学员系统入门也适合在职运维人员作为日常命令速查工具。内容基于科莱特SAP内训材料提炼对每个事务代码的适用场景、操作要点和注意事项均给出简明提示可直接用于日常巡检、问题排查与新人培训。1. SAP日常运维BASIS先搞清这套系统你到底在维护什么做 BASIS 运维的都有过这种经历周五下午用户群里突然有人喊“系统卡得点不动了”你打开 ST03N 看负载数值不高数据库响应也在正常范围但用户那边就是转圈圈。这种“说不清道不明的卡”最磨人也正是 SAP日常运维BASIS 这个岗位存在的意义——SAP 系统不是装完就能一直安稳跑下去的应用服务器、数据库、打印假脱机、后台作业、传输请求、权限账号每一块都可能成为故障点。BASIS 干的活通俗讲就是让 SAP 这套业务系统“活着、快着、不乱”。从每天上班打开 SAP GUI 那一刻开始你要确认系统还能不能登录、后台作业有没有挂、队列有没有堵、数据库空间够不够再到开发往生产传请求时别把别人的程序覆盖掉新员工入职要开账号、离职要收权限补丁版本要按序打。这些工作不直接产生业务价值但任何一环出问题财务月底结不了账工厂跑不了 MRP生产计划全打乱。这篇笔记我按日常巡检、传输管理、权限控制、高频故障排查和进阶调优五个方向展开把我做过的方案和踩过的坑整理成能直接照做的步骤。适合谁看负责单个 ECC 或 S/4HANA 系统的内部顾问、刚接手 SAP 系统管理的运维工程师以及准备从业务顾问转 BASIS 的同事。开发相关的内容我只在排错时涉及不会往 ABAP 代码层面深入。2. 把系统状态摸清楚巡检指标、事务码和第一反应2.1 每天的第一个动作用这些事务码和命令确认系统还活着我对“日常运维”的定义很简单每天早晨的第一件事是确认系统从数据库到应用层都是健康的。不要等用户来报障才看系统那是救火不是运维。在 Linux 环境下的 SAP 实例我习惯先用 sapcontrol 这一组命令把实例状态扫一遍# 查询当前实例的进程状态判断 AppServer 进程是否全部拉起 sapcontrol -nr 00 -function GetProcessList # 查看实例整体运行状态返回 RUNNING 才说明实例可用 sapcontrol -nr 00 -function GetInstanceStatus # 查看分发队列长度队列积压严重时业务操作会明显变慢 sapcontrol -nr 00 -function GetQueueStatistic-nr 00是实例号ECC 和 S/4HANA 常见的实例号是 00如果一套机器装了多个实例就按实际的实例号切换。GetProcessList 返回的每个进程都带状态GREEN 表示正常YELLOW 表示受限GREY 表示进程没起来比如 dispwork 变灰了用户基本就登录不上了。GetQueueStatistic 这个命令很多人不常用但它在排查“系统没报警但是业务慢”的场景特别好使——队列长度持续往上涨说明工作进程处理不过来请求全堵在队列里。GUI 层面SM50 看当前实例的工作进程占用SM66 跨实例看全局工作进程SM37 看后台作业状态SM13 看数据库更新请求有没有报错SM04 看在线用户。这些事务码是 BASIS 的“仪表盘”每天早上花五分钟扫一遍比事后看 ST03N 的负载统计有用得多。SAP GUI 客户端本身也值得注意前几年很多人还在用 7.x 的旧版新装环境已经普遍到 8.10 甚至更高客户端版本过旧会导致部分事务显示异常登录报错先看 GUI 版本不是玄学真遇到过好几回了。2.2 巡检指标不要拍脑袋把负载、队列、数据库卡点设成一张表很多刚做 BASIS 的同事巡检没有章法登录系统后东点点西看看最后啥结论都没有。我建议把巡检固化成一张表列清楚检查项、工具、阈值和异常处理动作这样新手照着做也能上手。检查项工具/事务码阈值参考异常处理动作工作进程利用率SM50 / SM66DIA 进程占用持续 90% 以上超过 10 分钟用 ST05 跟踪慢事务检查是否有低效 SQL后台作业失败率SM37每日失败数量超过 5%逐个查看作业日志按第 5 章方式排查缓冲区命中率ST02低于 90%检查是否频繁发生缓冲区交换必要时调大缓冲数据库平均响应DBACOCKPIT超过 50 毫秒检查数据库锁表、慢 SQL、表空间状态磁盘使用率df -h / sapcontrol达到 85% 需要关注清理日志目录扩展文件系统假脱机队列深度SP01积压任务超过 200检查打印机设备状态清理异常输出请求如果你们的系统跑 MRP还要额外关注 MD07 这类物料需求清单事务在计划员高峰期的调用频率。它本质上是大量读视图的报表在计划跑批时段集中操作会明显拉高数据库负载我见过不止一次因为计划员盯着 MD07 刷新导致 DB 响应变慢的情况。处理方法不是禁止用户看而是错峰操作或者在后台跑批完成后再开放高频访问。巡检数据沉淀下来之后下一步是让它变成告警而不是报表。常见的做法是写脚本定时调 sapcontrol 和数据库接口把异常状态推到企业微信或者钉钉机器人。脚本写法在第 6 章会给出一个可用的框架这里先不展开因为很多团队第一步连手工巡检都没跑顺直接上自动化只会增加一个没人看的告警群。3. 请求传输从释放到落地SAP 变更的“高速公路”3.1 传输链路与 TMS 配置开发请求怎么安全到达生产业务顾问在开发机改一个程序、配一个逻辑系统这个变更要交付生产中间靠的就是请求Transport Request。我见过太多刚转 BASIS 的同事把请求传输理解成“拷个文件过去”实际完全不是一回事。一个变更对象从创建请求开始到可修改、已释放、已导出、已导入中间要过传输路线Transport Route和传输控制系统TMS。常规流程是这样开发顾问用 SE09 或 SE10 创建并维护请求请求底下挂若干任务Task每个人改完自己的部分后释放任务最后发布者一起释放整个请求。请求释放后进入 TMS 队列按配置好的传输路线进入测试系统测试确认没问题后再传输到生产。这条链路里SE03 负责请求相关参数的调整STMS 是传输控制台SCC1 可以直接在目标系统导入请求。请求本身分工作台请求和传输请求两类有时候还涉及定制请求。我的建议是新手上路先分清请求和任务的关系不要直接在一个请求下拉人进来乱改。很多权限类的配置比如 PFCG 里的角色也会放进请求里传输所以传输队列不只是开发代码权限变更也走这条路。3.2 传输翻车的三个高频原因和对应处理第一类是依赖顺序问题。典型的情况是数据库表结构还没有传到目标系统程序先传过去了导入时报对象不激活。解决思路是遇到导入失败时不要急着重传先在 STMS 里看导入日志确认是哪一个对象失败。通常是按“基础设施 → 表结构 → 程序 → 权限”的顺序分批传输而不是把一串请求一次性打进生产。如果同一批次里有多个请求用 SCC1 导入时务必保持顺序跳号传只会制造更多冲突。第二类是对象锁定。某位开发顾问在传输请求已经释放之后又在同一个对象上新建了任务导致目标系统导入时发现对象被锁定。处理方式是让顾问把未完成的任务释放或删除必要时由 BASIS 通过 SE03 调整请求包含的对象列表把不在范围内的对象移出去。这种事不要硬来先和顾问确认是否真的不需要那个对象了再动请求结构否则事后要恢复会非常麻烦。第三类是目标系统配置不对。请求在测试机队列里能看到但在生产机队列里找不到十有八九是传输路线没配好或者 TMS 里分配的目标系统错误。检查顺序是 STMS → 传输路线概览 → 查看开发机和生产机的分配关系。这套东西没有重启大法改完配置后要重新生成传输路线并在测试环境先验证一次完整传输流程。传输这块我的经验是把测试系统看成生产的前置演练场任何请求第一次进生产前先在测试机完整走一遍。三个月之后你会发现生产导入失败的次数大大减少因为大部分坑都在测试环境踩完了。4. 用户与权限从建号到回收的完整处理套路4.1 SU01 建号、PFCG 配权、SU53 定位缺权用户和权限管理是 BASIS 日常运维里频率最高的操作之一。新人入职要开账号老员工调岗要加角色离职要回收权限业务顾问时不时还会找过来说“我这边有个事务报没权限”。这些工作看着琐碎但权限给的太宽是审计红线给的太窄影响业务效率中间这个度需要通过规范的流程来把控。创建用户走 SU01核心参数包括用户类型、初始密码、密码有效期、用户组。用户类型要格外注意Dialog 类型的用户占用的许可资源最多接口用户如果也配成 Dialog既浪费许可又增加安全隐患接口调用应该用 CPIC 或 Service 类型。密码策略如果在系统层面统一配置了SU01 里就不要再单独给某个用户设置永不过期除非有明确的特例审批记录。配角色的入口是 PFCG这是 SAP 权限体系里最重要的一个事务码。角色分为单角色和复合角色单角色里挂事务代码、报表权限、授权对象值复合角色把多个单角色打包给用户。创建角色的流程一般是先在“菜单”页签勾选用户需要的事务然后在“权限”页签点击“更改授权数据”系统会根据所选事务自动生成推荐授权对象之后用 SU24 维护事务对应的默认授权对象。这一步很容易被忽略导致角色配好了但用户执行事务时依然报权限不足。用户报“没有权限”时别凭感觉给授权用 SU53 让用户在报错的事务里复现一遍SU53 会记录具体是哪个授权对象检查失败、缺哪些字段值。根据 SU53 的结果回到 PFCG 里补充对应授权对象再重新生成参数文件分配给用户这样比拍脑袋加 SAP_ALL 靠谱得多。给权限相关的事务码列一张表事务码用途SU01用户主数据创建与维护PFCG角色创建、权限配置与分配SU24事务代码默认授权对象批量维护SU53权限检查失败详细信息查看SUIM用户信息系统生成各类用户与角色分析报表SU10批量锁定或解锁用户SE14数据库表编辑工具日常账号管理慎用“万能权限” SAP_ALL 是权限管理里最扎眼的存在运维团队最好能约定一个规矩任何角色和用户都禁止直接分配 SAP_ALL 或 SAP_NEW确实需要临时高权限时走审批并设置到期日期。SAP 系统被审计出问题绝大多数都是权限过度授权导致的。4.2 离职与调岗的权限回收给审计留一条清晰的链权限回收这块我强烈建议按“先锁定、后归档、再清理”三步走不要用户一离职就立刻删账号。直接删除账号会丢掉历史变更记录后面审计要查“某个人某天改过什么”的时候数据已经没了。离职处理的标准操作当天用 SU01 把用户锁定或者用 SU10 批量锁定一批离职用户然后记录锁定时间和操作人。用户锁定后该用户下所有未释放的请求、正在跑的后台作业、分配给这个人的任务都要逐一检查有没有遗留。请求可以转给其他人作业可以重新调度但这个过程最好在一周内确认完不要拖着。季度审计是权限管理里很容易被忽略的部分。用 SUIM 跑一张“用户-角色-最后登录时间”报表把超过 90 天没有登录过的用户挑出来逐一确认是否还需要保留账号。如果业务上确实暂时用不到就锁定而不是删除后续需要时再解锁既节省许可又留了安全余地。跨系统权限比对也建议定期做尤其是开发、测试、生产三套环境之间同一业务角色的权限配置差异往往就是隐患来源。调岗人员同理先确认新岗位需要的角色再移除旧岗位的角色不要只在 SU01 里追加角色。权限配置的历史留痕要保得住建议把每周的权限变更清单导出存档放在团队共享目录里审计来的时候可以直接按时间段调出清单省得临时现查现补。5. ST22、SM37、SPOOL、数据库与补丁五个最容易让运维翻车的现场5.1 ST22 里的程序 dump先看错误分类再决定找谁处理现象用户执行某个事务时报错退出有时会弹出 ABAP 短转储的对话框查看 ST22 能看到一长串 dump 记录。原因dump 并不全是程序代码问题。TSV_T_NEW_PAGE_ALLOC_FAILED 这类错误通常指向内存分配失败可能是系统内存不足也可能是某个会话占用过多而 DATABASE 相关的 dump 往往是数据库索引失效或锁表。字符串运算、权限检查失败也会产生 dump但占比小得多。解决ST22 打开错误列表后先看“错误”栏的分类判断是哪一层面的问题。内存类先看系统资源是否充足、是否有程序并发跑太高数据库类到 DBACOCKPIT 里查锁和慢 SQL如果是明确的 ABAP 代码异常把 dump 截图发给开发顾问让他们按短转储里的程序名、行号定位。ST22 里的历史 dump 建议每季度清理一次不然堆积太多真正需要找记录时翻起来特别费劲。5.2 SM37 后台作业失败作业日志、批输入、SPOOL 要分开看现象SM37 里调度中的作业显示为完成但状态是红色或者一直停在“已计划”没执行。原因后台作业失败的原因很分散最常见的是三种。一是作业调用的 ABAP 程序本身报错二是批输入会话没有正常处理完三是作业触发时系统资源不够批处理进程被占用作业没抢到执行资源。解决从 SM37 选中失败的作业直接看作业日志日志会显示具体的错误位置。如果是批输入相关作业失败再去 SM35 看批输入会话状态很多时候是因为主数据问题导致批输入中断修正数据后重新处理即可。如果是跨系统调用的作业比如通过 RFC 调用另一台 SAP 实例还要检查目标系统的实例状态很多作业失败其实是目标系统没起来引发的连锁反应。判断依据就是作业日志、批输入会话、系统进程状态这三样按顺序查基本不会漏。5.3 假脱机 Spool 卡死用户打不出报表的第一嫌疑现象用户打印或者预览报表时卡住系统提示无法完成假脱机请求SP01 里积压大量输出请求后台假脱机进程占满。原因打印机设备配置错误、宿主机连接不上、假脱机进程数不足都会导致这个局面。最典型的是远程打印机目标不可达Spool 请求发出去了但服务器端无法建立连接请求一直挂在队列里。解决先看 SPAD 里打印机设备的配置确认输出设备类型、主机地址、端口是否正确再到 SP01 里查看输出请求状态把长时间未完成的请求手动删除或重新发起输出。如果假脱机进程全被占满在 SM50 里看 SPO 类型工作进程的使用情况必要时使用 SM51 重启实例释放假脱机进程。处理完设备问题后让用户重新打印一份测试页确认恢复正常再关闭工单。“无法达到远程组机假脱机关系”这种报错出现时优先怀疑目标打印机或打印服务器的问题不要一上来就想着调 SAP 参数。5.4 数据库表空间不足与连接中断现象业务保存单据时报数据库表空间不足或者 SAP 日志里出现数据库连接中断的记录严重时整个实例不可用。原因最常见的是数据增长超出预期尤其是凭证表、日志表、批输入表增长过快表空间没有及时扩容。其次是归档配置没做好历史数据全堆在活动表里数据库文件越来越大。解决先通过 DBACOCKPIT 查表空间使用率紧急情况下直接扩展数据文件让系统先恢复可用。之后分析是哪些表增长异常SE14 可以查看和调整表存储属性但我必须提醒一句SE14 是数据库表的底层工具调整表结构、直接删除数据这些操作一旦失误影响面极大操作前一定要做完整的表备份并且不要在业务高峰时段执行。归档策略是治本方案把历史凭证和日志定期归档到归档存储而不是让它们一直占着活动表空间。5.5 补丁与升级期 SPAM 状态机卡住现象使用 SPAM 或 SAINT 打完补丁后系统重启升级状态停在某个步骤不再推进有的补丁队列显示为等待状态。原因SPAM 升级有一个严格的状态机逻辑前一步没有成功完成后面不会自动继续。常见卡住的原因包括补丁队列没按顺序导入、DDIC 对象在激活阶段出现冲突、升级前有未完成的后台作业占用了进程资源。解决按 SPAM 界面提示的当前步骤判断不要绕过状态机强行推进。对象激活冲突时回到 SE03 或 SE14 排查具体冲突对象属于修正包范围内的对象可以单独处理如果是后台作业阻碍先释放进程再重试。升级这种事最忌讳的就是在生产环境直接试我做过一次 SAP 补丁升级因为忽略了版本兼容性结果打完后某个标准功能直接不可用回滚又花了半天。从那以后我坚持升级前先备份然后在测试机完整走一遍同样的补丁流程记录所有报错和处理方式生产环境照着执行。补丁期间的每一步操作记录都留在当天的变更日志里这是给自己留的后悔药。6. 把运维从被动变主动ST05、SE30、sapcontrol 脚本与变更记录6.1 用 ST05 和 SE30 把“慢”定位到同一条 SQL遇到用户反馈某个事务慢口头描述往往是“转圈转了好久”但这句描述没有任何定位价值。我会先让用户再操作一次同时打开 ST05 开启跟踪系统会把这次访问的所有数据库调用、表访问路径、RFC 调用记录下来。跟踪结束后按时间筛选耗时最长的操作基本就能锁定是某一条 SQL 慢还是某一个函数模块调用延迟。SE30 可以单独分析一个程序的运行时分布结合 ST05 的数据库跟踪结果就能把慢的根因定位到具体代码路径。这套方法比反复让用户复现问题高效得多也省去了“系统慢是不是网络问题”的猜测。6.2 把早检查写成脚本sapcontrol 加计划任务日常巡检可以脚本化一部分我最常用的是用 sapcontrol 配合 shell 脚本做每日健康检查异常时告警省去每天手工敲命令的重复劳动#!/bin/bash # 每日巡检检查实例进程状态统计 GREEN 进程数量异常时发送告警 INSTANCE_NR00 STATUS$(sapcontrol -nr $INSTANCE_NR -function GetProcessList | grep -c GREEN) echo [$(date %Y-%m-%d %H:%M:%S)] GREEN process count: $STATUS /usr/sap/log/system_check.log if [ $STATUS -lt 5 ]; then echo SAP instance $INSTANCE_NR process not healthy, check SM50 immediately \ | mail -s SAP daily check alert opsexample.com fi这个脚本的要点有两个一是用grep -c GREEN统计正常进程数低于预期值时告警二是把结果写入独立日志文件每天累积形成趋势。实际场景里告警的发送方式可以是企业微信机器人脚本、钉钉机器人或者邮件按团队现有的通信工具接入即可。把脚本加到 crontab 里每天 08:30 执行运维值班的人只需要等告警没告警就意味着早上这一关过了。脚本要做得可靠还要处理一个问题sapcontrol 命令路径和环境变量要在脚本里显式声明否则 crontab 执行时往往因为 PATH 不对找不到命令。这也是很多自动化运维脚本“手动跑没事、定时跑失效”的原因。6.3 给配置变更留一个“黑匣子”系统出问题的时候第一反应是看最近改了什么。这是排障的黄金法则但前提是你有记录。我现在带团队有一条硬规矩每次修改系统参数、传输请求、补丁级别、打印机配置、权限角色都要在共享的变更记录里写一行内容包括变更时间、操作人、变更内容和影响范围。这个习惯养成了排查问题时打开记录一看大概率心里就有数了。好的 BASIS 运维不是靠记性而是靠留痕。系统配置的变更记录就是你的黑匣子平时看着不起眼出问题时它就是最快找到根因的路径。这行记录不需要多复杂Excel 表格、企业微信文档、SAP 备注都可以关键是坚持记。希望帮到你。本文还有配套的精品资源点击获取