SAP BASIS零基础入门：日常运维、事务码与权限巡检

简介：这份资料面向SAP系统管理员、Basis入门者及需要承担日常运维职责的IT人员，围绕SAP Basis这一角色梳理系统管理中高频使用的事务代码与操作场景，帮助读者在实施交付之后快速进入日常管理与监控的工作状态。压缩包共1个PDF文件，约2.02MB，篇幅紧凑，适合打印或放在手边随时查阅。内容以分类清单的方式展开，覆盖用户权限管理中的SU01、SU10、PFCG、SU53，集团管理中的SCC4、SCCL、SCC1、SCC5，数据库管理中的DB13、DB02、DB12与BRTOOLS，以及后台作业SM36、SM37、打印管理SPAD、SP01等常见事务码；系统监控部分进一步收录ST06、ST03、SM04、AL08、SM21、SM50、SM12、ST22、SM66等，传输管理涉及SE09与STMS，并补充了RZ10、RZ11参数维护、SM59远程连接和启动、进程、传输、数据库四类重要日志的查看路径。资料还对实施与运维的职责差异、数据备份还原的重要性作了说明，可当作日常巡检与排错时的速查手册。目前已有962人学习关注。

1. 先弄明白一件事：SAP BASIS 到底是谁在管这套系统

很多零基础的人第一次听到 SAP BASIS，会以为它是一门编程语言或者某个软件的名字。其实 SAP 是企业里跑业务的一整套大系统，报销、采购、下单、发工资都可能在它上面走；而 BASIS 是这套系统背后的管家角色，日常运维是它占比最大的一块工作——谁能登进来、账号能不能用、数据有没有备份、半夜卡住了谁爬起来看，都归这个角色管。这份资料走的是入门路线：先把角色讲清楚，再给你能照着敲的事务码和能照着看的屏幕。适合想进企业 IT、摸过一点服务器或数据库、哪怕完全没碰过 SAP 的人。

2. 为什么老手都劝你从运维进场：先跑通第一次登录和 ST06

2.1 为什么新手不该一上来就折腾安装

不少人有个直觉：学会安装才算入门，装不上就是没学会。带过新人的前辈给的建议恰好相反——安装是实施方向的活，一次性动作，装完就交付；运维是每天都得面对的事，用户的密码、跑飞的作业、半夜的告警，全都落在运维这边。你把安装练得再熟，也只是在空机器上重复一遍流程，系统的日常状态是什么样、正常的时候长什么样，你依然没有感觉。

还有个更现实的差别。自己家练习用的机器，装坏了重装一遍就行；公司那套生产系统装坏了，是没有后悔药吃的。新手如果在什么都不懂的时候只学会了“点下一步”，很容易在生产环境里也保持同样的手速，这是最危险的习惯。真正的底子在于：你知道 ST06 上那几条曲线代表什么，你知道 SM21 里冒出来的红字通常是什么类型的问题，你知道一个用户说“我进不去”时该让他先跑哪个事务码。这些东西装十次系统都学不到。

从运维入口进来的好处是，你每天都在接触真实问题。用户报过来的问题五花八门，有的根本不是 BASIS 的锅，而是业务流程或者程序逻辑的问题。解答这些问题的过程，会顺带把你对业务模块的理解垫起来，往后不管是做系统规划还是做性能调整，你都知道底下那群人到底在系统里干什么。这种“从使用者的角度看系统”的位置，是纯做安装的人拿不到的。

2.2 零基础去哪儿弄一个能练的环境

练手环境大概有三种来源，按推荐程度排：

第一是公司或者学校的测试系统。这是最理想的，因为它是真实的 SAP 系统，事务码全、数据真、有集团（client）可以随便折腾。跟管系统的同事说明你只在自己的测试集团里操作，别碰生产集团，一般都能商量。

第二是培训环境。有些内训或者课程会给你开一个临时账号，用几天到几周不等。它的好处是有人帮你兜底，环境坏了能重置；坏处是时间短，你只能练最核心的那几个事务码。

第三是自己搭一套。这条路技术上完全可行，但对零基础的人来说成本偏高：你要准备服务器资源、装数据库、装 SAP 实例，中间任何一步卡住都可能耗掉一整周。入门阶段不建议把它当第一件事，等你把日常运维的事务码摸熟了，再回头补安装这一课，效率会高得多。

不管哪种环境，登录前你需要凑齐四样东西：系统地址、系统标识（SID，比如 DEV、QAS 这种三位的代号）、集团号（Client，三位数字）、账号和密码。这四个信息缺一个都进不去，第一次用之前先问清楚，别自己猜。

提示：进系统之后先确认自己在哪个集团。同一个系统里，100 往往是生产、200 是测试、300 是开发，但每个公司的规划不一样，敲 SCC4 能看到当前所有集团的用途和属性。在没搞清楚之前，别在任何集团里按下保存。

2.3 第一次登录之后，先看三个屏幕

登录进去以后别急着乱点。SAP 的界面顶部有一条命令框，所有事务码都往这里敲，前面加/n表示“不保存当前屏幕直接跳走”，比如/nST06。这个习惯能救你很多次——当你在某个录入界面里进退两难时，加个/n就能干净地跳出来。

第一次登录，按这三步走，每一步都对应一个你能看懂的屏幕：

步骤一，敲ST06，回车。这是操作系统的性能概览，你能看到 CPU 使用率、内存使用率、交换区（PAGE SPACE）使用率、磁盘剩余空间。刚开始你看不懂什么叫“正常”，没关系，把这个屏幕的数字记下来，这就是你这套系统“闲着的时候”的样子。

步骤二，敲SM04，回车。这是当前登录到本服务器的用户列表，你自己也在里面。你会看到每台机器上是谁在挂着、用的什么终端、什么时间登进来的。这个屏幕以后会变成你的常用工具——有人反馈系统慢，你先看一眼是不是有一堆会话挂着没退出。

步骤三，敲SM21，回车，把时间范围选成最近一小时。这是系统日志，服务器的警告和错误都记在这里。新装的系统可能很干净，老系统一打开就是一片黄。先别慌，你要做的是认识它，而不是立刻解决它。

这三个屏幕加起来花不了五分钟，但它们构成了后面所有巡检动作的雏形。ST06 是“机器累不累”，SM04 是“谁在用”，SM21 是“系统自己说了什么”。后面你学的十几个监控事务码，说白了都是在这三个问题的延长线上做细分。

3. 第一个跟做的例子：用 SU01 复制一个带角色的账号

3.1 为什么把用户权限放在第一个练

日常运维里被找得最多的事情，不是数据库挂了，而是“我这个账号进不去”“我点这个按钮报没权限”“新来的同事要开个号”。这类需求频率高、影响面小、做完立刻能看到结果，特别适合当第一个练手项目。而且用户和权限这一套，是后面角色设计、传输、安全审计的共同基础，从这里切入，往哪个方向走都顺。

先把三个概念用大白话分开，不然后面全是玄学：

账号（User）是“这个员工是谁”，对应 SU01 里的那个用户名；角色（Role）是“这个岗位能干什么”，对应 PFCG，本质是一堆事务码和权限对象的打包；权限对象（Authorization Object）是“具体到某个动作的开关”，比如“能不能改这个公司的采购订单金额”，由 SU21、SU20 定义，SU22 用来查某个事务码到底受哪些对象管。

打个比方：账号是工牌，角色是岗位说明书，权限对象是门禁上那把锁。工牌发给谁、说明书怎么写、锁装在哪，是三件不同的事。

3.2 SU01 复制账号的完整步骤

假设测试系统里已经有一个配好权限的样板账号，你想造一个权限一样、名字不同的新账号。这时候不要从零建，用复制。

第一步，在命令框输入SU01，回车，进入用户维护的初始屏幕。这个屏幕上有一排按钮：创建、修改、显示、锁定/解锁、复制、删除。你现在要的是“复制”。

第二步，在“用户”字段里填源账号名（比如ZDEMO01），然后点菜单栏的“用户 → 复制”，或者直接点工具栏上那个两人头像的复制按钮。

第三步，弹出对话框后，在“到”字段里填新账号名（比如ZDEMO02），回车。系统会问你要复制哪些内容，一般保留默认，把角色、参数、用户组一起带过去。

第四步，进入新账号的明细页，重点看三个页签。地址页填姓名、部门、邮箱，这些是给别人认的；“登录数据”页设置初始密码、用户类型、用户组；“角色”页确认带过来的角色对不对，多一个少一个都要在这里改。

第五步，保存。保存成功左下角会出现一条提示，同时系统会生成一条变更记录。

复制和新建的差别就在这一步：复制会连角色、参数、默认值一起搬过来，新建出来的是个空账号，什么权限都没有。新人最容易犯的错是新建完忘了配角色，然后跟用户说“好了”，用户一登进去什么都点不动。

SU01 里几个字段值得单独说清楚：

同一个界面里还有两件日常小事：改密码和锁定/解锁。用户打电话说进不去，你先在 SU01 里把账号查出来，看是锁了还是密码过期了，一键处理完再让他试，比让他反复重登快得多。

3.3 复制完别急着交付：用 SU53 验证权限缺口

账号建好、密码给了，用户登进去说“还是不行”，这时候别靠猜。让他把报错的界面留着，直接在命令框敲SU53。这个事务码显示的是当前用户最近一次权限检查失败的具体信息：缺哪个权限对象、哪个字段、需要什么值、实际是什么值。

这是新手最该养成的习惯之一。没有 SU53 的时候，判断权限问题全靠对话——“我点保存报错”“报什么错”“就一个红框”——来回几轮天都黑了。有了 SU53，对方截一张图给你，问题基本就定位了。

需要提醒的是，SU53 只显示最近一次失败记录，所以要让用户在报错之后立刻敲，别中间又去点了别的按钮。如果对方已经点过去了，让他重现一次再敲。

3.4 角色这一层：PFCG 和三个“定义类”事务码的关系

把 SU53 的报错拿到手以后，接下来往往要动角色。这时候就进入 PFCG 的地盘。

PFCG 是角色的创建、修改、显示界面。一个角色的结构大致是：先挂菜单（把一堆事务码、报表、网址丢进去），再生成权限（系统根据菜单推导出需要哪些权限对象），最后在权限页里给每个对象的具体字段填值（比如这家公司、这个工厂、这个金额上限）。填完还要点“生成”，角色才会真正生效。

这里有个很容易翻车的点：改了角色不点生成，或者生成了没传到目标系统，用户那边看起来什么都没变。所以“改了没生效”这类问题，八成不是权限配错，而是漏了生成或者漏了传输。

SU21、SU20、SU22 这三个是更底层的工具箱，新手阶段知道它们是干什么的就行，不用急着动：SU21 管权限类和对，也就是“有哪些门禁类型”；SU20 管权限字段，也就是“这类型的门禁上带哪些输入框”；SU22 是按事务码反查，告诉你这个事务码受哪些权限对象管。当你拿到一个 SU53 报错、看不出该去哪个角色里改的时候，SU22 就是那个查字典的地方。

还有一个 SU10，批量修改用户。比如公司调整部门，二十个人的用户组要一起换，一个一个开 SU01 会疯，SU10 里可以把用户列表粘进去，一次改完。

4. 日常巡检怎么排：一天固定看这 12 个屏幕

4.1 为什么巡检必须固定成清单

系统没出问题的时候，看什么都是正常的；等出了问题，你根本不知道自己系统“正常”长什么样。这就是没有基线的代价。有位做过多年系统管理的前辈讲过一句很实在的话：要在系统还健康的时候，尽可能多地把工作负载数据留下来。你手上有一张系统健康时的清晰照片，才可能在它开始跑偏的时候第一时间察觉。

所以巡检不是走形式，是在给自己攒参照物。下面这套顺序按“从机器到业务”铺开，你每天花十五到二十分钟走一遍，一个月之后就会对系统有手感。

4.2 早上第一轮：机器和进程

先敲ST06。看四样：CPU 使用率、内存使用率、交换区使用率、磁盘剩余。交换区那项要特别留意，它一旦长期高位，说明物理内存不够，系统会莫名其妙地变慢，而且这种慢很难从 SAP 层面看出来。

再敲SM51。这是服务器概览，列出这套系统里所有的应用服务器。想看某一台的进程，鼠标点中服务器名，再选 Processes，就直接跳到那台机器的进程列表。多服务器环境下，SM51 是你的地图。

接着SM50，进程概览。这里能看到每个工作进程在干什么、跑了多久、是哪个用户、什么操作。判断标准很朴素：一个报表或者后台作业跑了几十分钟还没结束，就值得点进去看看它在干嘛。长时间运行的报表和有缺陷的程序会吃掉大量资源，这是运维需要盯的。

再敲SM66，它把全局的进程一次性列出来，不用一台台服务器切过去看。多服务器系统里，SM66 比 SM50 更省事。

最后SM04，看在线用户。除了确认有没有异常登录，这个屏幕还能看出谁挂着会话不动。有些人早上开了系统，中午就再没碰过，会话一直占着资源。要不要清，得跟对方确认，别自作主张。

4.3 第二轮：日志和错误

SM21是系统日志，服务器记录的事件和问题都在这里。方法是按时间倒着看，把所有警告和错误过一遍，能解决的解决，解决不了的记下来。这份记录本身就是资产，同一个错误第二次出现的时候你不用从头查。

ST22是 ABAP 运行时错误，也叫 dump。程序因为严重错误中断时，系统会在这里留下一条记录。这个要每天看，因为 dump 往往是用户已经遇到过、但没人报上来的那种问题。看到 dump，先看它发生在哪个程序、哪个用户、什么时间，再决定是转给开发还是自己处理。

SM13是更新记录，显示失败的数据库更新动作。这个在生产系统里是硬指标：失败的更新动作绝不允许长期挂着，因为它意味着业务数据只写了一半。发现一条，就要立刻找开发定位。

SM12是锁管理。用户断线、程序出错，都可能留下一个老锁，把某张单据或者某个对象锁死，别人一点就提示被占用。处理方法是先看清锁的持有者、锁的类型、锁了多久，再决定删不删。上来就删是最容易出事的做法。

4.4 第三轮：数据库和后台作业

DB13是数据库的日常维护日历，你要在这里确认昨晚的备份、数据库检查、优化统计更新这些作业都跑了，而且成功了。这个界面同时也是看这些作业日志的入口。

DB12是备份日志，专门用来确认夜间备份有没有成功，顺便看一眼日志目录还剩多少空间。备份成功但磁盘快满，等于下一次备份注定失败。

DB02看数据库表和索引的增长情况，还有碎片。它的作用是提前预警：某个表空间快满了，你今天加空间，明天就不用救火。

SM36定义后台作业，SM37查看和监控。SM37 里要重点看被取消的作业——不是看一眼就算，而是点进去看它的假脱机输出，搞清楚为什么被取消。所有被取消的作业都应该有分析结论和处置记录，这是运维最基本的功课。

4.5 第四轮：集团、传输、打印和操作系统日志

集团这一块，SCC4管集团的创建、修改、显示，SCCL做集团拷贝，SCC1在系统内传单个请求，SCC5删除集团，SCC3看集团操作日志。日常最常看的是 SCC3，集团拷贝或者传输出问题时，日志里写得最清楚。

传输这块，SE09管传输请求和任务的释放，STMS管传输队列、集团策略、系统内和跨系统传输。判断标准：请求该放的放了没有，队列里有没有卡住的。

打印这块，SPAD定义打印设备，SP01管假脱机请求和输出请求。用户说“打印不出来”，你先在 SP01 里看有没有他的假脱机请求：有的话可以删掉重发；如果请求状态是完成但纸没出来，那问题多半在用户端，比如他电脑上的打印程序被关了。这里有个坑要记住：SAP 只跟踪到输出队列，状态显示“完成”不代表纸真的打出来了，重要的和量大的打印任务，在从临时存储里删掉之前必须人工确认。

除了事务码，操作系统层的日志也要会看。下面这几条命令是常用的：

# 把 <SID> 换成你的系统标识，例如 DEV；DVEBMGS00 是中央实例目录 # 按时间倒序列出进程日志目录，最新的在最上面 ls -lt /usr/sap/<SID>/DVEBMGS00/work | head -n 20 # 看工作进程日志的末尾，确认启动过程有没有报错 tail -n 200 /usr/sap/<SID>/DVEBMGS00/work/dev_w0 # 传输日志目录，排查传输失败时先看这里最新的文件 ls -lt /usr/sap/trans/log/ | head -n 10 # 启动日志一般在实例用户的家目录下，<sid>adm 中的 sid 用小写 ls -lt /home/<sid>adm | head -n 20

这几条命令解决的是“事务码看不到的那一层”。路径里的<SID>是三位系统标识，实际用的时候要换成大写；<sid>adm是实例管理员账号，习惯上用小写。dev_w0是工作进程的日志文件，编号从 0 开始，对应不同的进程。传输日志目录里会按日期生成文件，出问题先看最新的那个。数据库层的日志位置跟数据库类型有关，以 Oracle 为例，后台进程的跟踪文件在saptrace/background目录下。

5. 新手最容易踩的坑：5 条排查清单和它的现象、原因、解法

5.1 权限类的两个坑

坑一：用户说没权限，直接给他加最高权限。

现象：用户报某个按钮点不动，你嫌麻烦，直接把一个几乎什么都能干的大权限角色挂上去，问题立刻“解决”。

原因：SU53 都没看，根本不知道缺的是哪个对象。用大权限盖过去，表面上是修好了，实际上是把一个本该精确控制的开关焊死了，以后做安全审计、做职责分离的时候全是隐患。

解法：先让对方在报错界面敲SU53，拿到缺失的权限对象和字段值，再去 PFCG 里对应角色补上，补完记得点生成。真的急用，也应该是临时挂一个范围明确的小角色，事后回收。

坑二：角色改了，用户那边还是不行。

现象：你在 PFCG 里加了事务码、生成了角色、保存了，用户重新登录还是报没权限。

原因：大概率是三个漏中的一个——改了菜单没点“生成权限”；生成了但角色还在开发系统没传到测试或生产；用户没有退出重登，会话里还是老权限。

解法：按顺序排查。先看角色状态是不是已生成；再确认角色所在系统是不是用户当前登录的系统；最后让用户完全退出再登一次。三步都过一遍，九成问题能定位。

5.2 系统操作类的两个坑

坑三：看到卡住的进程直接在 SM50 里杀掉。

现象：某个会话跑了很久，你顺手选中它点了删除。

原因：那个会话可能是一笔正在提交的业务，杀掉的瞬间事务只做了一半，数据处在中间状态，比卡着更麻烦。

解法：动手之前先看清是谁的会话、在跑什么程序、跑了多久。能联系到当事人就联系，确认可以中断再动手。真正该杀的通常是明显异常、用户已经放弃、且确认没有写操作的那些。杀进程的操作权限通常给到系统层，这也说明它不是一个可以随手点的按钮。

坑四：SM12 里看到锁就删。

现象：用户说单据被锁，你在 SM12 里找到那条锁，直接删掉，用户马上能用了。

原因：你不知道这个锁是谁加的、为什么加。有些锁是后台作业正在处理数据时加的保护，删掉它等于把保护撤了。

解法：先看锁的持有者、锁的参数、加锁时间。老锁（比如昨天留下、持有者已经下线）可以清理；正在被活动会话持有的锁，先联系持有人，或者等他那边操作结束。批量清理锁这种操作，永远不要在没有确认清单的情况下做。

5.3 变更类的一个坑

坑五：在生产集团里做“临时测试”。

现象：生产系统里有个配置想验证一下，你想着“改完马上改回来”，就直接在 100 集团里动手，顺手用 SCC4 把集团的限制放开了。

原因：生产集团默认应该是不可改的，SCC4 里那个开关之所以存在，就是为了拦住这种“临时”。你一放开，所有人都能改，而且系统不会提醒你改了什么。

解法：所有验证都在测试或开发集团做，做完通过传输传到生产。真的需要在生产做紧急变更，走变更流程、留记录、事后把 SCC4 的开关恢复。顺带说一句，RZ10改系统参数也是同一类风险：改之前备份当前参数文件，改完确认要不要重启生效，别在生产上直接改完就走人。

6. 下一步学什么：从日常运维到实施顾问的路线图

把上面这套巡检走顺之后，你大概会花三到六个月。接下来往哪走，取决于你想做成什么。

如果你只想把运维做扎实，重点补两块：数据库的备份与恢复、传输管理。备份这一块特别提醒一句，DB12显示“备份成功”只代表备份任务跑完了，不代表这份备份能恢复。真正的验证是定期做一次恢复演练，在测试环境里把备份还原出来，看数据完不完整。这件事很多团队一年都不做一次，真出事的时候才发现备份文件是空的。这是我见过最贵的一课。

如果你想往实施方向走，路线大致是这样：

每一阶段都别跳。有人觉得装系统才是“真本事”，急着跳到第四阶段，结果前三个阶段的问题一个都处理不了。系统装出来是给人用的，你不懂用户那边在干什么，装出来的东西也只停留在能开机。

还有一个习惯值得从一开始就养：把每次处理过的问题记下来，现象、原因、怎么解的，三五行走足够。攒到一百条的时候，你会发现新问题里有大半是旧的变种。带新人的前辈讲过一句“教学相长”，你帮别人解答的时候思路反而更清楚，因为不在压力下，脑子转得开。我自己的问题本翻得最勤的那几页，全是当年觉得“这么简单不用记”的小事。

最后一条，是向前看。SAP 这套东西版本换得勤，产品线也在不断加，今天会的事务码过两年可能界面就变了。别把力气全花在背事务码上，那玩意查一下就有；把力气花在理解“这个屏幕在回答什么问题”上，那个不会过期。

我刚开始学的时候，最爱犯的毛病是看到报错就先动手改，改完才想起来问用户当时在做什么。后来我给自己定了个规矩：任何一次处理，先让对方重现一次问题，我在旁边看着，看清楚他点了哪个按钮、走的哪条路径，再动手。这个习惯让我少走了很多弯路。希望帮到你。

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