企业官网建设流程全解析

简介：这份资源是一套面向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 把角色挂到人身上。

这张表建议按「字段 → 对象 → 事务码 → 角色 → 用户」的顺序背，而不是按事务码编号背。顺序记住了，遇到没见过的 SU 系列事务码也能猜出它大概落在哪一层。

2.3 权限报错的排查顺序：SU53 先看，PFCG 后改

用户报「没权限」时，最省事的做法其实是先别动角色。让用户在同一个界面复现一次操作，然后立刻看 SU53，它会明确告诉你这次操作缺的是哪个授权对象、哪个字段值不够。拿着这个结果回 PFCG 里比对角色菜单和权限值，改完重新生成授权，再让用户重新登录验证，链路就闭合了。

跳过 SU53 直接凭经验加角色的后果，是权限越加越大，半年后没人说得清某个角色到底能干什么，审计时也解释不通。权限只加不减是运维里最典型的慢性病。

提示：角色改完，用户不重新登录，权限大概率还是旧的。被问「你明明改了怎么还是不行」时，先确认这一步，能省掉大量来回。

3. 集团管理与传输：SCCL 拷贝、SE09 释放、STMS 导入

集团是 SAP 里最像「平行世界」的东西：同一套系统里可以有多个集团，各自有独立的业务数据和定制，互不干扰。传输则是把改动从一个系统搬到另一个系统的通道。这两块经常被放在一起考，因为它们的共同点是——动作一旦执行就很难回退。

3.1 集团的五个动作与不可逆边界

推荐的固定动作顺序是：SCC4 建集团或改属性 → SCCL 拷内容、或 SCC1 灌某个请求 → SCC3 核对结果。中间任何一步做完都不急着进下一步，先把 SCC3 的日志翻一遍，确认没有跳过表和报错项。SCCL 最容易被忽略的是「带不带数据」这个勾选，选错了要么拷了个空壳，要么把测试数据灌进了本不该有的地方。

3.2 一次完整传输的两段式：SE09 放行，STMS 落地

传输分成两段，很多人卡住是因为把两段混成一段。第一段在改动所在的系统里，由 SE09 管理：一个请求下面挂若干任务，任务是实际改动的容器，必须先把任务逐个释放，请求本身才能释放。请求一旦释放，就等于把改动打包封存，之后不能再改这个请求，想补东西只能新建请求。

第二段在 STMS 里：请求释放之后才会进入传输队列，STMS 负责运输路线、集团策略、系统内传输、跨系统传输和队列导入。系统内传输指的是同一个系统里跨集团搬，跨系统传输才是开发机到测试机、测试机到生产机这种。队列里的状态能直接看出是等待、导入中还是已失败。

注意：只释放了任务、没释放请求，STMS 里是看不到这条传输的。这是新手最常见的「我明明点了释放」翻车现场。

3.3 传输卡住时的排查顺序与日志落点

队列长时间不动，按这个顺序查：目标系统是否可达、是否有人在目标系统上占着导入锁、传输目录的对端是否可访问、队列里前面那条是不是失败了在堵着。别一上来就重导，先确认前面那条是不是留下了一半的东西。

四个日志落点是必须记死的，出任何问题都先往这四个目录里翻：

# SID 换成实际系统标识，这里以 PRD 为例 SID=PRD # 传输日志按时间倒序，先看最近一次导入 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、ST22

SM12 管锁。用户断线、程序出错都会留下老的锁对象，攒久了就出现「谁都改不了这条数据」。原则是所有被锁定的老对象都要被分析、更正，而不是一律删锁——删之前至少看一眼是谁锁的、锁了多久、对应哪个事务。

SM13 显示失败的更新动作。失败更新在生产系统里是决不允许存在的，一旦出现要立即让开发介入修改，不能挂着观察。它和锁不一样，锁是暂时的资源占用，失败更新是数据一致性的缺口。

ST22 是 ABAP 短转储。报表或事务因为严重错误中止时，系统会在系统日志里记一条，并把程序终止时的信息写进 SNAP 表。每天查一遍有没有 short dump，有就分析并尝试解决。很多人只看当天有没有，不看重复出现的同一条——同一个 dump 一天出现几十次，说明是个稳定的缺陷，值得单独提出来修。

4.4 日志、审计与系统参数：SM21、SM20、SM02、RZ10、RZ11

SM21 是系统日志，服务器在里头记录系统的事件和问题。所有的警告和错误信息都应该被分析和解决，并且把问题及其解决方案写成文档。这条最容易被跳过，但它直接决定了下一次同类问题是花十分钟还是两小时。

SM20 是安全审计，配合前面提到的账号锁定、异常登录一起看；SM02 用来发系统消息，比如提前通知在线用户晚上停机；SSAA 是系统管理助手，把常用管理功能聚在一个入口，临时找不到事务码时可以用它兜底；SM59 维护远程连接，系统之间连不通，先来这里看 RFC 目标的状态。

RZ10 改参数，RZ11 查参数。要记住的一点是：RZ10 改完不是立刻生效，某个参数能不能动态生效，得去 RZ11 里看它的动态标志。静态参数必须重启实例，所以改之前先确认这个参数属于哪一类，再排进停机窗口，别在生产时段改完等生效。

4.5 数据库：DB13、DB02、DB12、BRTOOLS

DB13 是数据库日常维护日历，把备份、CHECK DATABASE、优化统计更新这类动作排成后台作业，同时也能查这些作业的日志。日常巡检里它更像一个「总控面板」，告诉你昨夜的计划任务有没有按时跑。

DB02 监控数据库表和索引的扩张，同时看碎片情况和优化统计是否需要更新。空间类问题几乎都是渐变而不是突变，每周对比一次增长率比每天看绝对值更有效。

DB12 查数据备份日志，两个动作：确认夜间备份是否成功，以及检查日志目录的剩余空间。备份成功但目录快满了，下一次备份照样会失败，这两件事必须一起看。BRTOOLS 是操作系统侧的数据库管理工具，DB13 里做不了的细活通常落到这里。

# 示例路径，按实际备份目录替换 df -h /backup # 看最近产出的备份文件，确认夜间作业真的落了东西，而不只是状态是绿的 ls -lt /backup | head -n 10

df -h用人类可读单位显示各挂载点使用率，重点看备份所在分区还有多少余量；ls -lt按修改时间倒序，最新一条的时间戳如果还是前天的，说明夜里那次备份根本没产出文件，光看 DB12 的成功标志会漏掉这种情况。

4.6 后台作业与打印：SM36、SM37、SPAD、SP01

SM36 定义后台作业：起名、设启动条件（立即、定时、事件触发）、绑定要跑的程序或外部命令。SM37 负责监控，管理员应该检查所有被取消的作业，必要时分析并修正，把问题和解决方案记录在案。作业的日志和输出列表都要看，别只确认状态是不是绿的——状态正常但输出列表为空，往往比报错更麻烦。

打印这边，SPAD 定义打印设备，包括输出设备、访问方式、主机信息；SP01 管理假脱机请求和输出请求。打印不出来时先看有没有假脱机请求，有的话可以在这里删掉，失败的任务也能重启。这类失败多数是用户端的问题，比如 PC 上的输出程序被关掉了。

注意：SAP 只跟踪打印任务到目标队列，输出控制器里显示「已完成」，并不代表纸上真的打出来了。重要和大批量的打印任务，在被从 TemSe 删除之前必须先确认实际输出成功。

5. 易漏易错：五个最容易翻车的点

第一，权限改完不生效。易漏点：角色改完、授权重新生成了，用户那边还是报没权限。 为什么漏：少做了最后一步验证——用户没有重新登录，会话里还是旧授权。 怎么补：固定成「改角色 → 重新生成授权 → 让用户退出重登 → 用 SU53 复核一次」四步，缺一步都不算完。

第二，打印状态绿了就当打完了。易漏点：SP01 里状态正常，业务方说没收到纸件。 为什么漏：系统只跟踪到目标队列，后面那一段它看不见。 怎么补：重要和批量打印在从 TemSe 删除前人工确认一次；同时把「用户端输出程序被关掉」写进常见问题清单，省得每次从头查。

第三，传输只释放了任务。易漏点：SE09 里点了释放，STMS 队列里死活找不到这条。 为什么漏：请求和任务是两层，任务全释放之后请求本身还要再释放一次。 怎么补：记住「任务先、请求后」，释放完顺手去 STMS 队列确认一眼，而不是回头再查。

第四，只看 SM50 不看 SM66。易漏点：本地实例看着很闲，整个系统却卡。 为什么漏：SM50 只看当前实例，别的实例上跑着大作业它照不出来。 怎么补：巡检固定用 SM66 拿全局进程视图，确认要动手时再回 SM50 定位具体实例。

第五，改参数当场等生效。易漏点：RZ10 改完，观察半天没变化，以为改错了。 为什么漏：没先查这个参数是动态还是静态，静态参数要重启实例才生效。 怎么补：改之前先用 RZ11 查该参数的动态标志，静态的排进停机窗口，动态的改完立刻验证。

6. 复习清单：一张自查表加三个练习习惯

复习到这一阶段，最有效的不是再刷一遍事务码列表，而是拿一张表把「模块—必会事务码—判断标准—出错先看哪」串起来自查。能对着这张表把每一行的判断标准说清楚，基本就算过关了。

配套的三个练习习惯，比死记硬背管用得多。一是手脑动：看完一个事务码，立刻在测试系统里做一遍，把步骤和自己的理解记下来，转成自己的笔记，光念书考试是不行的。二是自答问：别人问你的问题、你自己查出来的答案，都收进一个自己的问题集锦，非压力状态下想通的解法，下次遇到同类问题基本能照方抓药。三是广泛学：别把 Basis 当成纯技术活，使用者启用了哪些功能、业务流程怎么走，直接决定你该怎么管这套系统，缺了使用者验证，就是自卖自夸。

从那以后我每次接手一套新系统，都会先把这九块拼图对着事务码表过一遍，把每块的判断标准写成一句话，再开始动手。这个习惯帮我省掉了不少「以为改完了其实没生效」的返工。希望帮到你。

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