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 表示进程没起来，比如 disp+work 变灰了，用户基本就登录不上了。GetQueueStatistic 这个命令很多人不常用，但它在排查“系统没报警但是业务慢”的场景特别好使——队列长度持续往上涨，说明工作进程处理不过来，请求全堵在队列里。

GUI 层面，SM50 看当前实例的工作进程占用，SM66 跨实例看全局工作进程，SM37 看后台作业状态，SM13 看数据库更新请求有没有报错，SM04 看在线用户。这些事务码是 BASIS 的“仪表盘”，每天早上花五分钟扫一遍，比事后看 ST03N 的负载统计有用得多。SAP GUI 客户端本身也值得注意，前几年很多人还在用 7.x 的旧版，新装环境已经普遍到 8.10 甚至更高，客户端版本过旧会导致部分事务显示异常，登录报错先看 GUI 版本不是玄学，真遇到过好几回了。

2.2 巡检指标不要拍脑袋：把负载、队列、数据库卡点设成一张表

很多刚做 BASIS 的同事巡检没有章法，登录系统后东点点西看看，最后啥结论都没有。我建议把巡检固化成一张表，列清楚检查项、工具、阈值和异常处理动作，这样新手照着做也能上手。

如果你们的系统跑 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 靠谱得多。给权限相关的事务码列一张表：

“万能权限” 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_NR=00 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" ops@example.com fi

这个脚本的要点有两个：一是用grep -c 'GREEN'统计正常进程数，低于预期值时告警；二是把结果写入独立日志文件，每天累积形成趋势。实际场景里告警的发送方式可以是企业微信机器人脚本、钉钉机器人或者邮件，按团队现有的通信工具接入即可。把脚本加到 crontab 里每天 08:30 执行，运维值班的人只需要等告警，没告警就意味着早上这一关过了。

脚本要做得可靠，还要处理一个问题：sapcontrol 命令路径和环境变量要在脚本里显式声明，否则 crontab 执行时往往因为 PATH 不对找不到命令。这也是很多自动化运维脚本“手动跑没事、定时跑失效”的原因。

6.3 给配置变更留一个“黑匣子”

系统出问题的时候，第一反应是看最近改了什么。这是排障的黄金法则，但前提是你有记录。我现在带团队有一条硬规矩：每次修改系统参数、传输请求、补丁级别、打印机配置、权限角色，都要在共享的变更记录里写一行，内容包括变更时间、操作人、变更内容和影响范围。这个习惯养成了，排查问题时打开记录一看，大概率心里就有数了。好的 BASIS 运维不是靠记性，而是靠留痕。系统配置的变更记录就是你的黑匣子，平时看着不起眼，出问题时它就是最快找到根因的路径。这行记录不需要多复杂，Excel 表格、企业微信文档、SAP 备注都可以，关键是坚持记。

希望帮到你。

本文还有配套的精品资源，点击获取