简介这份资源是一套面向SAP Basis初级运维人员与转岗学习者的日常运维命令速查资料围绕系统管理岗位的实际操作场景梳理常用事务代码的用途与关注点帮助读者在用户权限、集团管理、数据库维护、系统监控等工作中快速定位入口。资源包共1个文件为PDF格式大小约2.02MB结构按管理模块分章排列便于按主题检索或打印随身查阅适合作为日常值班与交接时的对照手册。目前已有965人学习下载说明其在SAP运维入门群体中具备一定参考价值。内容涵盖SU01用户维护与解锁改密、SU10批量修改、PFCG角色权限、SU53权限检查SCC4与SCCL集团创建拷贝DB13维护日历、DB02表与索引监控、DB12备份日志核查SM36与SM37后台作业定义与监控SPAD与SP01打印设备及假脱机管理ST06操作系统性能、ST03工作负载、SM04与AL08在线用户、SM21系统日志、SM50与SM66进程查看、SM12锁管理与ST22短存储分析以及SE09与STMS传输请求管理等并附常用日志路径与Basis角色职责说明可作为查漏补缺的入门索引。1. 运维视角的 SAP Basis九块拼图与一条主线把 SAP Basis 的日常运维摊开看其实是九块拼图用户权限、集团管理、数据库、后台作业、打印、系统监控、传输管理、系统参数、日志落点。反直觉的地方在于新手最容易把精力全压在安装和配置上而真正每天要交差的恰恰是这九块里最枯燥的那些巡检动作。这份笔记按「事务码 → 判断标准 → 出错先看哪里」重排了一遍适合正在系统学 Basis、或者临考前想把知识地图重新对上号的人。2. 用户与权限管理SU01、PFCG、SU53 这条链怎么串Basis 这个角色按工作偏向粗分是两块实施偏规划、安装、配置交付时还要留下一批文档相当于把大局定下来运维偏管理、监控、维护在大局已定的前提下把日常守住。新人常以为实施一定比运维高一头其实两边领域不同没有绝对高下。但有一件事两边都绕不开——数据安全所以数据库备份和还原是必须认真掌握的基本功。运维侧的第一块拼图就是用户与权限。2.1 SU01 的三个日常动作解锁、改密、复制账号SU01 是用户维护的总入口日常真正高频的只有三件事。第一件是解锁和改密用户被锁要先分清原因是密码输错次数超限还是管理员手动锁的。前者要顺手去 SM20 安全审计里看一眼确认不是有人在反复试密码后者问清楚业务原因再解别养成「报障就解锁」的习惯。第二件是复制账号。手工堆角色最容易漏标准做法是拿一个已经跑通的账号当模板比如 mycw12在 SU01 里复制成新账号 MYCW14把角色、用户组、参数一起带过来再单独设初始密码并要求首次登录修改。复制过去的是权限配置不是密码这一点经常被记混。第三件是批量处理交给 SU10。人事变动、离职清理这类一次改一批的场景用它但批量操作没有后悔药执行前先把受影响用户导一份清单核对确认范围没多也没少。2.2 权限对象的生成顺序SU20 → SU21 → SU22 → PFCG权限体系是分层搭出来的跳过任何一层后面都会出现「角色建了但事务码不认」的怪现象。字段是最小单位SU20 管它对象是字段的组合SU21 管权限类和对象事务码执行时要去检查自己对应的授权对象这层关系在 SU22 里维护PFCG 把对象和值打包成可分配的角色最后由 SU01 把角色挂到人身上。事务码管什么典型动作出问题先看SU01用户主数据创建、修改、显示、解锁、改密、复制账号锁定原因、角色是否真的挂上SU10批量用户批量改用户属性、有效期、用户组改动范围有没有超PFCG角色建角色、挂菜单、生成参数文件改完有没有重新生成授权SU53权限检查看某次操作缺哪个对象、缺哪个字段值是缺对象还是缺值SU21权限类与对象建对象、维护对象包含的字段对象有没有分配给事务码SU20权限字段建字段、维护字段类型字段有没有被对象引用SU22事务码授权对象维护事务码与授权对象的对应关系新上的事务码是否已登记这张表建议按「字段 → 对象 → 事务码 → 角色 → 用户」的顺序背而不是按事务码编号背。顺序记住了遇到没见过的 SU 系列事务码也能猜出它大概落在哪一层。2.3 权限报错的排查顺序SU53 先看PFCG 后改用户报「没权限」时最省事的做法其实是先别动角色。让用户在同一个界面复现一次操作然后立刻看 SU53它会明确告诉你这次操作缺的是哪个授权对象、哪个字段值不够。拿着这个结果回 PFCG 里比对角色菜单和权限值改完重新生成授权再让用户重新登录验证链路就闭合了。跳过 SU53 直接凭经验加角色的后果是权限越加越大半年后没人说得清某个角色到底能干什么审计时也解释不通。权限只加不减是运维里最典型的慢性病。提示角色改完用户不重新登录权限大概率还是旧的。被问「你明明改了怎么还是不行」时先确认这一步能省掉大量来回。3. 集团管理与传输SCCL 拷贝、SE09 释放、STMS 导入集团是 SAP 里最像「平行世界」的东西同一套系统里可以有多个集团各自有独立的业务数据和定制互不干扰。传输则是把改动从一个系统搬到另一个系统的通道。这两块经常被放在一起考因为它们的共同点是——动作一旦执行就很难回退。3.1 集团的五个动作与不可逆边界事务码作用使用边界SCC4创建、修改、显示集团维护集团属性生产集团的属性改动影响所有在线用户改前必须确认定位SCCL拷贝集团可选择带定制、带数据大库拷贝耗时长挑业务低峰执行SCC1系统内传输单个请求到指定集团常用于把定制从一个集团搬到另一个集团SCC5删除集团不可逆删前确认备份和日志SCC3集团操作日志拷贝或传输做完先看这里别假设成功推荐的固定动作顺序是SCC4 建集团或改属性 → SCCL 拷内容、或 SCC1 灌某个请求 → SCC3 核对结果。中间任何一步做完都不急着进下一步先把 SCC3 的日志翻一遍确认没有跳过表和报错项。SCCL 最容易被忽略的是「带不带数据」这个勾选选错了要么拷了个空壳要么把测试数据灌进了本不该有的地方。3.2 一次完整传输的两段式SE09 放行STMS 落地传输分成两段很多人卡住是因为把两段混成一段。第一段在改动所在的系统里由 SE09 管理一个请求下面挂若干任务任务是实际改动的容器必须先把任务逐个释放请求本身才能释放。请求一旦释放就等于把改动打包封存之后不能再改这个请求想补东西只能新建请求。第二段在 STMS 里请求释放之后才会进入传输队列STMS 负责运输路线、集团策略、系统内传输、跨系统传输和队列导入。系统内传输指的是同一个系统里跨集团搬跨系统传输才是开发机到测试机、测试机到生产机这种。队列里的状态能直接看出是等待、导入中还是已失败。注意只释放了任务、没释放请求STMS 里是看不到这条传输的。这是新手最常见的「我明明点了释放」翻车现场。3.3 传输卡住时的排查顺序与日志落点队列长时间不动按这个顺序查目标系统是否可达、是否有人在目标系统上占着导入锁、传输目录的对端是否可访问、队列里前面那条是不是失败了在堵着。别一上来就重导先确认前面那条是不是留下了一半的东西。四个日志落点是必须记死的出任何问题都先往这四个目录里翻日志类型路径看什么启动日志/home/SIDadm实例启动过程、启动失败的早期错误进程日志/usr/sap/SID/DVEBMGS00/work对话进程、调度器、后台进程的跟踪文件传输日志/usr/sap/trans/log/每次导入的详细过程卡在哪一步数据库日志数据库 trace 目录形如 …/saptrace/background数据库侧的报错SAP 层看不出来的问题# SID 换成实际系统标识这里以 PRD 为例 SIDPRD # 传输日志按时间倒序先看最近一次导入 ls -lt /usr/sap/trans/log/ | head -n 5 # 进程日志dev_disp 看调度器dev_w0 看对话进程日志是追加写的所以看末尾 tail -n 200 /usr/sap/${SID}/DVEBMGS00/work/dev_disp # 启动日志在实例用户的 home 目录下 ls -lt /home/${SID}adm参数说明SID替换成三位的系统标识DVEBMGS00是中央实例的目录名编号随实例号变化对话实例通常是D编号的形式head -n 5只看最近五条因为日志目录里堆积的历史文件可能成百上千tail -n 200取文件末尾跟踪文件是持续追加的开头部分往往是上一次启动的记录参考价值低。4. 系统监控与日常巡检从 ST06 到 SP01 的固定顺序监控这块事务码最多硬背很容易乱。有效的做法是排一个固定顺序先看操作系统再看负载再看人再看进程最后看锁、更新和转储。顺序固定下来每天照着走一遍就不会漏出问题时也知道该从哪一层往下剥。4.1 操作系统与工作负载ST06、ST03 的基线思维ST06 每天必看看的是整个操作系统的资源状况CPU 使用率、内存使用率、PAGE SPACE 使用率。单看一个瞬时数值意义不大真正有价值的是趋势——同样的时段这周比上周高了多少是不是每次月结都顶到同一个位置。ST03 是 R/3 工作负载分析它最反常识的一点是最该保留的数据是系统还没出问题时的那份。手里有一张系统正常时的清晰画像你才能认出什么叫异常甚至提前预见到将要发生的问题。等到用户开始投诉才去抓数据往往已经错过了对照基准。这条属于血泪经验没有替代品。4.2 用户、服务器与进程SM04、AL08、SM51、SM50、SM66这一组要分清「服务器相关」和「服务器无关」。SM04 看的是当前这台服务器上的在线用户AL08 看的是所有服务器上的在线用户人多实例的环境下差别很大。日常巡检该用 AL08 拿全局视角排查具体某个实例的问题才切回 SM04。SM51 显示服务器列表点中某台服务器再选 Processes 就能看到它的进程SM50 看本地实例的进程概览SM66 是全局进程视图能跨实例看到正在跑的进程。只盯 SM50 会漏掉别的实例上那个吃了大量资源的报表程序这是很常见的一个盲区。杀进程之前先和最终用户确认。长时间运行的后台作业、有缺陷的报表程序确实会消耗大量系统资源但那是用户跑了几小时的结果杀掉只要一秒重跑要半天。4.3 锁、更新与短转储SM12、SM13、ST22SM12 管锁。用户断线、程序出错都会留下老的锁对象攒久了就出现「谁都改不了这条数据」。原则是所有被锁定的老对象都要被分析、更正而不是一律删锁——删之前至少看一眼是谁锁的、锁了多久、对应哪个事务。SM13 显示失败的更新动作。失败更新在生产系统里是决不允许存在的一旦出现要立即让开发介入修改不能挂着观察。它和锁不一样锁是暂时的资源占用失败更新是数据一致性的缺口。ST22 是 ABAP 短转储。报表或事务因为严重错误中止时系统会在系统日志里记一条并把程序终止时的信息写进 SNAP 表。每天查一遍有没有 short dump有就分析并尝试解决。很多人只看当天有没有不看重复出现的同一条——同一个 dump 一天出现几十次说明是个稳定的缺陷值得单独提出来修。4.4 日志、审计与系统参数SM21、SM20、SM02、RZ10、RZ11SM21 是系统日志服务器在里头记录系统的事件和问题。所有的警告和错误信息都应该被分析和解决并且把问题及其解决方案写成文档。这条最容易被跳过但它直接决定了下一次同类问题是花十分钟还是两小时。SM20 是安全审计配合前面提到的账号锁定、异常登录一起看SM02 用来发系统消息比如提前通知在线用户晚上停机SSAA 是系统管理助手把常用管理功能聚在一个入口临时找不到事务码时可以用它兜底SM59 维护远程连接系统之间连不通先来这里看 RFC 目标的状态。RZ10 改参数RZ11 查参数。要记住的一点是RZ10 改完不是立刻生效某个参数能不能动态生效得去 RZ11 里看它的动态标志。静态参数必须重启实例所以改之前先确认这个参数属于哪一类再排进停机窗口别在生产时段改完等生效。4.5 数据库DB13、DB02、DB12、BRTOOLSDB13 是数据库日常维护日历把备份、CHECK DATABASE、优化统计更新这类动作排成后台作业同时也能查这些作业的日志。日常巡检里它更像一个「总控面板」告诉你昨夜的计划任务有没有按时跑。DB02 监控数据库表和索引的扩张同时看碎片情况和优化统计是否需要更新。空间类问题几乎都是渐变而不是突变每周对比一次增长率比每天看绝对值更有效。DB12 查数据备份日志两个动作确认夜间备份是否成功以及检查日志目录的剩余空间。备份成功但目录快满了下一次备份照样会失败这两件事必须一起看。BRTOOLS 是操作系统侧的数据库管理工具DB13 里做不了的细活通常落到这里。# 示例路径按实际备份目录替换 df -h /backup # 看最近产出的备份文件确认夜间作业真的落了东西而不只是状态是绿的 ls -lt /backup | head -n 10df -h用人类可读单位显示各挂载点使用率重点看备份所在分区还有多少余量ls -lt按修改时间倒序最新一条的时间戳如果还是前天的说明夜里那次备份根本没产出文件光看 DB12 的成功标志会漏掉这种情况。4.6 后台作业与打印SM36、SM37、SPAD、SP01SM36 定义后台作业起名、设启动条件立即、定时、事件触发、绑定要跑的程序或外部命令。SM37 负责监控管理员应该检查所有被取消的作业必要时分析并修正把问题和解决方案记录在案。作业的日志和输出列表都要看别只确认状态是不是绿的——状态正常但输出列表为空往往比报错更麻烦。打印这边SPAD 定义打印设备包括输出设备、访问方式、主机信息SP01 管理假脱机请求和输出请求。打印不出来时先看有没有假脱机请求有的话可以在这里删掉失败的任务也能重启。这类失败多数是用户端的问题比如 PC 上的输出程序被关掉了。注意SAP 只跟踪打印任务到目标队列输出控制器里显示「已完成」并不代表纸上真的打出来了。重要和大批量的打印任务在被从 TemSe 删除之前必须先确认实际输出成功。5. 易漏易错五个最容易翻车的点第一权限改完不生效。易漏点角色改完、授权重新生成了用户那边还是报没权限。 为什么漏少做了最后一步验证——用户没有重新登录会话里还是旧授权。 怎么补固定成「改角色 → 重新生成授权 → 让用户退出重登 → 用 SU53 复核一次」四步缺一步都不算完。第二打印状态绿了就当打完了。易漏点SP01 里状态正常业务方说没收到纸件。 为什么漏系统只跟踪到目标队列后面那一段它看不见。 怎么补重要和批量打印在从 TemSe 删除前人工确认一次同时把「用户端输出程序被关掉」写进常见问题清单省得每次从头查。第三传输只释放了任务。易漏点SE09 里点了释放STMS 队列里死活找不到这条。 为什么漏请求和任务是两层任务全释放之后请求本身还要再释放一次。 怎么补记住「任务先、请求后」释放完顺手去 STMS 队列确认一眼而不是回头再查。第四只看 SM50 不看 SM66。易漏点本地实例看着很闲整个系统却卡。 为什么漏SM50 只看当前实例别的实例上跑着大作业它照不出来。 怎么补巡检固定用 SM66 拿全局进程视图确认要动手时再回 SM50 定位具体实例。第五改参数当场等生效。易漏点RZ10 改完观察半天没变化以为改错了。 为什么漏没先查这个参数是动态还是静态静态参数要重启实例才生效。 怎么补改之前先用 RZ11 查该参数的动态标志静态的排进停机窗口动态的改完立刻验证。6. 复习清单一张自查表加三个练习习惯复习到这一阶段最有效的不是再刷一遍事务码列表而是拿一张表把「模块—必会事务码—判断标准—出错先看哪」串起来自查。能对着这张表把每一行的判断标准说清楚基本就算过关了。模块必会事务码判断标准出问题先看用户权限SU01 / PFCG / SU53用户能进事务码且权限没越界SU53 的缺失对象集团SCC4 / SCCL / SCC1 / SCC3集团属性与定位一致日志无跳过项SCC3 操作日志传输SE09 / STMS请求已释放队列已清空STMS 导入监控 trans/log系统监控ST06 / ST03 / SM66与正常期基线相比无明显偏移ST06 → SM66锁与更新SM12 / SM13无长期老锁无失败更新锁的持有者与事务码短转储ST22无新增 dump重复项已提单SNAP 表与 dump 详情数据库DB13 / DB02 / DB12备份成功、目录有余量、表空间有余量DB12 → DB02作业与打印SM37 / SP01无被取消作业无积压假脱机请求作业日志与输出列表配套的三个练习习惯比死记硬背管用得多。一是手脑动看完一个事务码立刻在测试系统里做一遍把步骤和自己的理解记下来转成自己的笔记光念书考试是不行的。二是自答问别人问你的问题、你自己查出来的答案都收进一个自己的问题集锦非压力状态下想通的解法下次遇到同类问题基本能照方抓药。三是广泛学别把 Basis 当成纯技术活使用者启用了哪些功能、业务流程怎么走直接决定你该怎么管这套系统缺了使用者验证就是自卖自夸。从那以后我每次接手一套新系统都会先把这九块拼图对着事务码表过一遍把每块的判断标准写成一句话再开始动手。这个习惯帮我省掉了不少「以为改完了其实没生效」的返工。希望帮到你。本文还有配套的精品资源点击获取
