简介《SAP日常运维BASIS》是一份面向SAP系统管理员与Basis入门者的实操型命令手册聚焦日常运维中高频事务代码的定位与用途适合刚接手系统管理、需要快速找到操作入口的运维人员查阅。全包仅1个PDF文件压缩后约2.02MB篇幅紧凑可随查随用也便于打印成纸质速查表。内容按用户权限、集团管理、数据库管理、后台作业、打印管理、系统监控与传输管理分块编排权限侧给出SU01、SU10、PFCG、SU53等账号与角色维护命令系统侧整理SCC4/SCCL集团操作、DB13/DB02/DB12数据库监控与备份日志、SM36/SM37后台作业、SPAD/SP01打印队列以及ST06、ST03、SM50、SM66、ST22、SM13等性能与进程排错入口。文中还标注了启动日志、进程日志、传输日志与数据库日志的常见存放路径并简述实施与运维两类Basis角色的职责差别。已有965人学习适合作为日常巡检与故障排查时的案头索引。1. 一张事务码地图SAP 日常运维 BASIS 的七个工作面SAP 日常运维 BASIS 这个角色站在操作系统、数据库、SAP 实例和业务用户之间日常干的活其实很有边界感。刚上手的人常犯的错是先背事务码背了几十个却不知道出事该从哪个入口进真正值钱的是脑子里有一张按工作面切开的地图。手头这份整理把它分成七块用户权限、集团、数据库、后台作业、打印、系统监控、传输管理外加参数、连接、系统消息这类杂项。实施偏规划、安装、配置运维偏监控、维护、巡检两条线共用同一套事务码只是使用频率和深度不同。这张地图先立住后面每一块再往下拆细节。2. 用户与权限SU01 到 PFCG 的四层结构权限工单在运维日常里出现的频率极高新人入职、转岗、离职、临时授权、越权投诉全走这条路。真正麻烦的地方在于很多人把「建用户」和「给权限」当成一件事结果建出来的账号能登录却点不动业务或者权限给大了没人发现。把用户主数据、权限对象、角色、权限检查这四件事分开看排错时才知道该停在哪一层。2.1 用户主数据SU01 的解锁、改密、复制三件事SU01 是用户维护的总入口创建、修改、显示都在这里。日常最高频的是三个动作解锁、改密码、复制账号。用户连续输错密码被锁是常态直接在 SU01 里把锁定标志去掉即可改密码要注意不要顺手把「用户下次登录必须修改密码」勾上否则业务方第二天又会来找你。复制账号是新人入职时最省事的做法以某个同岗位的老账号为模板复制角色、参数、用户组一起带过来再改姓名、工号、邮箱和有效期。这里有个容易忽略的细节——复制会把源账号的一些状态一并继承包括有效期和用户类型复制完必须逐项核对尤其是对话用户和系统用户不能混用。离职处理反过来做先锁账号、再删角色最后确认没有后台作业还在用这个账号跑。提示用户类型决定了这个账号能不能用于后台作业和系统间通信改名和复制时都要单独确认不要只看角色对不对。2.2 权限的四层结构字段、对象、类、角色权限体系是 BASIS 里最像迷宫的一块但拆开只有四层。最底层是权限字段由 SU20 维护往上是权限对象由 SU21 维护对象归属于某个对象类再往上是角色由 PFCG 组装菜单和权限值并生成授权配置文件最上层是用户由 SU01 把角色分配给具体账号。层级事务码管什么典型动作权限字段SU20字段本身如活动、公司代码新建自定义字段权限对象与类SU21对象类、对象、字段组合新建对象并挂字段角色PFCG菜单、权限值、生成配置文件改权限值后重新生成用户SU01用户主数据、角色分配建号、锁号、复制梳理下来会发现权限不生效的原因八成集中在两处一是 PFCG 里改了权限值但没点生成授权配置文件还是旧版本二是用户会话没刷新让对方退出重新登录就好。这两条能解释掉大部分「明明给了权限却用不了」的工单比从头查对象快得多。2.3 SU22 与 SU10两个容易放错位置的补位码SU22 的定位经常被误解它维护的是事务代码对应的授权对象也就是反查「这个事务码会检查哪些权限对象」。排权限问题时它的价值极高用户报某个事务码点不进去先用 SU22 看这个事务码检查什么再用 SU53 看用户实际缺什么两头一对结论就出来了。反过来自定义事务码挂错授权对象也会造成权限怎么加都加不上的假象。SU10 是批量修改用户适合组织调整、批量锁号、批量改用户组这类场景。批量操作的风险在于一次改一大片改错了回滚成本很高稳妥的做法是先拿两三个测试账号跑一遍确认字段映射没问题再全量执行。这两个码平时用得不多但都属于「需要时找不到就会卡住」的类型值得在笔记里单独留一行。2.4 SU53权限报错的第一现场用户说「我没有权限」最有效的第一句话是让对方立刻执行 SU53 并截图。SU53 显示的是最近一次权限检查失败的信息能直接看到缺哪个对象、哪个字段值、需要什么级别的活动权限。拿着这张截图去 PFCG 里补值通常几分钟就能闭环。它的局限也要记住只保留最近一次失败记录用户多点几个按钮就会被覆盖所以一定要强调「先截图再重试」。另外 SU53 显示的是「缺什么」不负责解释「为什么缺」常见的根因是组织级别字段没给值比如公司代码、工厂、采购组织这类维度为空看着对象有权限实际一条数据都访问不到。这类问题在跨组织架构调整后特别集中属于典型的踩坑高发区。3. 集团与传输SCCL 拷贝与 STMS 队列的配合集团和传输这两块平时安静一动就是大事。拷贝集团会拉起一批后台作业跑几小时传输请求导错系统能把生产环境搞出定制不一致。它们的共同点是操作门槛不高但后果不可逆所以真正要练的不是手速而是每次动手前的确认清单目标是哪个集团、源是什么状态、有没有人正在登录、失败之后能不能回到原点。3.1 集团管理的五个事务码SCC4、SCCL、SCC1、SCC5、SCC3SCC4 管集团的属性创建、修改、显示都在这里生产集团通常要限制更改避免有人直接在生产线改定制。SCCL 做集团拷贝从一个源集团整体复制到目标集团拷贝前要确认目标集团没有用户在线否则会拷不干净或者中途失败拷贝启动后会产生后台作业用 SM37 盯进度是最稳妥的方式。SCC1 做系统内传输把单个传输请求从一个集团搬进另一个集团常用于把测试集团验证过的定制同步到另一个集团。SCC5 是删除集团属于不可逆操作删之前必须先做备份并二次确认别指望有后悔药。SCC3 记录集团复制和传输的日志是事后追溯「谁在什么时候动过哪个集团」的唯一凭据。事务码用途风险点SCC4集团属性维护生产集团更改限制被放开SCCL集团整体拷贝目标集团有人在线导致拷贝失败SCC1单个请求系统内传输请求跨集团不兼容SCC5删除集团不可逆必须先备份SCC3集团操作日志平时不看出事才找3.2 SE09 与 STMS从释放到导入的两段路传输的完整链路分两段开发侧用 SE09 管理传输请求把任务和请求依次释放目标侧用 STMS 管理导入队列按系统路径把请求导进测试系统、生产系统。顺序不能乱先释放任务再释放请求任务没释放完请求就释放不掉这是新人最常见的卡点。STMS 里除了导入还管集团策略、系统内传输、跨系统传输和传输队列。日常最需要盯的是队列积压某个请求导入失败会卡住后面一串越积越多最后整条链路停摆。所以每次导入后都要看一眼队列是否清空失败项要么修要么删不能留着过夜。注意生产系统的导入窗口要提前约别在业务高峰期手动导请求失败的代价远大于等一个窗口。3.3 SCC3 与传输日志事后追溯的证据链系统层的记录在事务码里操作系统层的记录在文件里。传输日志在/usr/sap/trans/log/目录下按时间和系统标识分文件导入失败时先看这个目录里最新的一批文件比在 STMS 界面里翻队列更快定位到具体报错行。# 传输日志目录按修改时间倒序先看最近一次导入产生的文件 cd /usr/sap/trans/log ls -lt | head -20 # 文件名一般带系统标识和日期配合 STMS 队列里的请求号一起看这段命令的作用是先按时间排掉干扰把注意力集中到最近一次操作上。如果目录体积异常增长说明日志长期没有归档需要和传输目录的数据文件一起做容量规划。SCC3 负责集团维度的记录日志目录负责文件维度的记录两条线对上了责任链才完整。4. 系统监控ST06、SM50、ST22 的判读顺序监控这件事最怕没有顺序。同样一堆告警摆在面前有人十分钟定位到根因有人查了两小时还在猜。比较稳的路子是自下而上先看操作系统资源再看 SAP 进程和锁再看短存储和系统日志最后落到数据库和后台作业。这个顺序的价值在于上层的大部分异常都能在下层找到解释反过来查容易越查越乱。4.1 先看操作系统再看应用ST06 与 ST03ST06 展示的是操作系统层面的资源状况CPU 使用率、内存使用率、PAGE SPACE 使用率这些指标每天扫一眼能提前发现资源见底的征兆。它回答的是「机器累不累」不回答「哪个业务在累」所以要和 ST03 配合。ST03 是 R/3 工作负载分析看的是系统整体负载、响应时间、最耗资源的会话和报表。这里有一条经验值得写进笔记性能调优最痛苦的不是改参数而是没有问题发生时的基线数据。平时系统健康的时候要多留工作量分析数据手里有一张「正常时长什么样」的图出问题时才有对比的参照物很多隐患在变成故障之前就能被看出来。没有基线所有判断都只能靠感觉那才是真正的黑匣子。4.2 进程、锁与更新SM50、SM66、SM12、SM13SM50 是服务器进程概览能看到当前实例上每个工作进程在跑什么、跑了多久。长时间运行的后台作业、有缺陷的报表程序如果不加控制会吃掉大量系统资源管理员要全天盯这一屏。发现异常进程时杀掉之前必须先和最终用户沟通确认不是月结、不是正在跑的接口否则容易造成数据不一致。SM66 提供的是全局视角跨实例看所有 SAP 进程多服务器架构下用它比逐个登服务器快。SM12 管锁用户断线、程序异常退出都会留下锁对象老锁不清理会阻塞后续业务需要定期检查并分析原因。SM13 记录失败的更新动作生产系统里失败的更新是绝不允许存在的一旦出现开发必须立即介入修数据或修程序拖久了影响面会扩大。4.3 短存储与系统日志ST22、SM21、SM20ST22 是 ABAP 短存储分析报表或事务因为严重错误中止时会生成 dump程序终止时的现场信息记录在 SNAP 表里。管理员应每天检查是否有新的短存储有就分析并推动解决重复出现的 dump 往往指向同一段有问题的代码。SM21 是系统日志记录服务器层面的事件和问题所有警告和错误都应当被分析并留下处理记录。SM20 是安全审计用于回溯关键操作。这三个码构成了一条时间线ST22 告诉你程序在哪崩了SM21 告诉你系统当时发生了什么SM20 告诉你谁做了什么操作串起来才能还原一次故障的全貌。4.4 数据库三件套DB13、DB02、DB12DB13 是数据库日常维护日历数据库备份、一致性检查、优化统计更新这些作业都挂在这里也能查这些后台作业的执行日志。它的定位是「计划与执行」不是「检查结果」备份到底成没成要看 DB12。DB02 监控数据库表和索引的增长与碎片情况关注的是空间够不够、碎片多不多、优化统计是否及时更新。表空间涨到阈值才发现通常已经晚了日常看趋势比看绝对值更重要。DB12 检查数据备份日志确认夜间备份是否成功同时看日志目录剩余空间。备份这件事的逻辑很朴素没验证过的备份等于没有备份定期做一次还原演练比每天看绿灯有用得多。操作系统层还有 BRTOOLS用于数据库的管理操作属于 DBA 和 BASIS 交界的地带出问题时知道它在哪、能干什么比会敲每一条命令更实际。4.5 后台作业与打印SM37 的取消作业与 SP01 的假脱机后台作业用 SM36 定义步骤、开始条件、优先级三件事配好剩下的交给 SM37 监控。SM37 里最该关注的是被取消的作业每一个取消都要分析原因并修正问题和解法记录在案同时要检查作业日志和输出列表输出列表往往是唯一能证明作业真的跑完的证据。打印用 SPAD 定义打印设备SP01 管理假脱机请求和输出请求。打印失败时先看 SP01 里有没有对应的假脱机请求有就删掉重试很多失败其实是用户端的问题比如本机输出程序被关掉了。这里有个特别容易误解的点SAP 只跟踪打印任务到目标队列为止输出控制器显示「已完成」并不代表纸上真的打出来了重要和大量的打印任务在从 TemSe 删除之前必须人工确认实际打印成功。4.6 用户与服务器视角SM04、AL08、SM51SM04 看当前登录用户是服务器相关的只能看到本实例上的会话AL08 是服务器无关的全局用户列表多实例环境下用它才准。管理员应全天关注在线用户及其活动是否存在异常账号、是否有人正在使用不该用的 事务代码这些都属于日常巡检范围。SM51 列出所有应用服务器点进某台服务器可以看它的进程情况用来判断不同服务器之间的负载是否均衡。这四个码单独看都不复杂组合起来的价值在于用户说「系统卡」你可以先确认他在哪台服务器、那台服务器上还有谁、负载如何再决定往哪个方向查。5. 易漏点那些不出事想不起来的事务码有些知识点看一遍就懂真出事时却想不起来用这是运维里最典型的翻车方式。下面五条是梳理过程中反复出现的盲区每条都按「漏在哪、为什么漏、怎么补」写清楚。其一权限改完只在 SU53 里验证没回业务场景复测。漏的原因是 SU53 给的是即时反馈看起来问题已经闭环。实际上 SU53 通过只说明那一次检查过了用户真正要跑的事务可能还缺别的对象。补法很简单改完权限让对方在测试环境把完整业务流程走一遍尤其是跨模块的操作别拿一个事务码的绿灯当全部通过。其二把打印状态「已完成」当成打印成功。漏的原因是界面给了确定性的信号人本能地相信它。SAP 只跟踪到目标队列队列之后的环节它看不见。补法是养成习惯重要打印任务在 TemSe 清理前让业务方确认实物到手大批量打印尤其要先打一张样张。其三在 SM50 里看到一个进程跑太久就直接终止。漏的原因是当下只想着释放资源。被杀掉的可能是月结作业、可能是正在写数据的接口后果比慢一点严重得多。补法是终止前必须和最终用户确认确认不了就先查这个进程对应的作业号和用户再决定动不动手。其四性能问题发生时才想起没有基线数据。漏的原因是系统正常时没人愿意花时间留数据。等 ST03 里全是异常时段的记录对比就失去了意义。补法是固定节奏每周或每月系统平稳时留一份工作负载快照和巡检记录放一起。其五日志目录和备份还原长期没人真正看过。漏的原因是它们不在事务码界面里翻文件系统需要额外一步。启动日志在/home/SIDadm进程日志在/usr/sap/SID/DVEBMGS00/work数据库日志在数据库自己的 saptrace 目录下这些路径平时不痛不痒出问题时是唯一的线索来源。补法是把目录巡检写进月度清单并且定期做一次真实的还原演练。6. 复习清单把事务码和日志路径串成一条巡检线复习这个方向最有效的方式不是重背事务码而是按「一天、一周、一月」三个节奏把动作排出来让每个码都有归属。下面这张表是我自己过一遍就会用的版本按工作面分组右侧标注建议频率照着走一遍基本能覆盖日常。工作面事务码看什么频率系统资源ST06、ST03CPU、内存、页空间、工作负载每日进程与锁SM50、SM66、SM12长跑进程、全局进程、残留锁每日日志与异常SM21、ST22、SM13系统日志、短存储、失败更新每日数据库DB13、DB12、DB02备份结果、日志空间、表与索引增长每日加每周后台作业SM37被取消的作业、输出列表每日打印SP01失败假脱机、TemSe 清理前确认按需用户SM04、AL08、SU53在线用户、权限报错现场每日加按需传输STMS、SCC3队列积压、集团操作记录每次导入后文件系统日志目录磁盘占用、trace 体积每月文件系统这一行容易被表格漏掉单独给一段命令方便直接抄。检查的重点是传输目录和进程日志目录的占用涨得快说明日志没归档或者有异常在刷日志。# 月度巡检确认传输目录没被日志和数据撑满 df -h /usr/sap/trans du -sh /usr/sap/trans/log /usr/sap/trans/data # 进程日志目录trace 文件长期堆积会吃掉大量空间 du -sh /usr/sap/SID/DVEBMGS00/work ls -lt /usr/sap/SID/DVEBMGS00/work | head -10df -h看的是文件系统剩余空间du -sh看的是具体目录体积两条配合能快速判断是整体磁盘不够还是某个目录失控。第二条命令里的SID要换成实际系统标识先按时间排序再决定清哪些不要按名字批量删。清单之外还有几个码值得在复习时过一眼SSAA 是系统管理助手把常用管理功能聚在一起找不到入口时先翻它SM02 发系统消息停机维护前通知在线用户SM59 维护远程连接接口不通时先来这里看连接测试RZ11 查参数当前值RZ10 改参数改完要不要重启、实例参数和默认参数哪个优先这两件事必须在动手前搞清楚否则改完不生效会以为是系统问题。从那以后我每次接手一个新系统第一件事不是看它有多少用户而是把这九个工作面的入口挨个点一遍确认自己能进去、能看到数据、知道异常长什么样再开始处理工单。这套动作花不了半小时但能省掉后面无数次「这个码在哪」的停顿。希望帮到你。本文还有配套的精品资源点击获取
