企业官网建设流程全解析

简介：《SAP日常运维BASIS》是一份面向SAP Basis初学者、运维人员及系统管理岗位的学习资料，聚焦日常系统管理中的常用事务代码与操作要点，帮助读者建立从用户权限、集团管理到系统监控的运维知识框架。压缩包内共1个PDF文件，约2.02MB，便于在电脑或移动端查阅，适合作为岗位入门、日常排障和命令速查的参考材料。内容围绕用户与角色权限、集团拷贝与日志、数据库维护与备份、后台作业、打印管理、系统监控、传输管理及重要日志路径等模块展开，并对SU01、PFCG、DB13、SM37、STMS等常用事务代码的用途作了归纳。目前已有965人学习，适合希望系统梳理SAP Basis日常工作、补全监控与排错思路的读者使用。

1. 一堆 T-Code 背后的日常：SAP BASIS 运维到底在守哪几道门

接手一套 SAP 系统，最先拿到的往往不是架构图，而是一张几十行的 T-Code 清单：SU01、PFCG、SCCL、STMS、ST22、SM13……新手看到的是命令，做过几年的人看到的却是九条必须天天盯着的命脉——用户权限、集团、数据库、后台作业、打印、系统监控、传输、参数、日志。这份内训材料把 SAP BASIS 日常运维的入口一次性铺开，适合刚转岗做 BASIS 的人照着建立巡检节奏，也适合开发顾问和模块顾问用来弄明白「我提的权限申请为什么被退回」。它不教你装系统，讲的是系统装好之后，每天怎么确认它还活着、还安全、还能恢复。

2. 用户与权限：SU01 到 SU53 的一条闭环链路

用户问题永远排在工单第一行。「密码忘了」「账号锁了」「新同事要开号」「这个人要能看不能改」，四句话对应四种完全不同的操作，混着做就会留下审计尾巴。这一章把 SU01、SU10、PFCG、SU53、SU21/SU20/SU22 串成一条链：开号、挂角色、验证权限、出问题回查，走完整一遍再谈批量。

2.1 SU01 复制账号：为什么不能直接改原账号

最常见的错误操作是「离职同事的账号别删，改个名字给新人用」。从技术上看 SU01 改得动，从审计上看这是灾难：所有历史操作记录、更新记录、变更日志里的用户名都指向同一个人，事后追责无从下手。正确做法是用 SU01 的「复制用户」功能，以老账号为模板生成一个新账号。

复制时 SAP 会问你要不要连带复制的内容，几个字段最容易被忽略：

复制完第一件事是解锁并重设密码，第二件事是核对「用户组」。用户组决定了谁能维护这个账号，如果新账号还挂在已撤销的组里，锁账号的人和开账号的人会对不上。日常里我一般要求开号走三步：SU01 复制、SU01 重设密码勾强制修改、SUIM 复核角色归属，三步做完再通知用户。

还有一个细节：账号锁定有几层。SU01 里看到的「用户已锁定」是应用层锁，可能还有数据库层密码错误导致的锁、以及有效期到期导致的失效。看到「锁定」先别急着点解锁，用 SU01 的「显示」看锁定原因和修改记录，否则解了又锁，来回折腾。

2.2 PFCG 里的角色授权对象到底从哪来

PFCG 建角色，界面上有菜单、有权限、有用户三个页签。很多人只会在菜单里加事务码，然后点「生成」，权限页签里冒出一堆对象和值，就以为配好了。实际上一套角色里最容易出错的是「授权对象是从哪冒出来的」。

链条是这样的：SU21 定义权限类（比如 AAAB 是跨应用授权类）和类下挂的对象；SU20 定义权限字段，比如公司代码、工厂、活动（ACTVT）；事务代码本身通过 SU22 维护的「默认值」把需要的对象和字段带出来，进 PFCG 时自动填入。所以你觉得角色生成得莫名其妙，多半是事务代码的默认值没维护——字段被填成了空或者通配，权限范围就失控了。

提示：授权值里出现*，等于把该字段的所有取值范围全放开。审计看得最紧的就是这种写法，尤其是公司代码、工厂、成本中心这类组织级字段。

角色的维护顺序我一向是倒着来：先确认 SU22 里这个事务码的默认对象对不对，再在 PFCG 里手工把组织级字段限定成具体值，最后才点生成。角色生成完，还要回到用户主数据做一次「用户比较」，否则角色改了、用户没生效，用户端依旧报没权限，你来我回能查一下午。

关于角色里到底挂了哪些授权值，图形界面查起来一层套一层，需要跨角色批量比对时我会直接查表。这是数据库层的只读查询，生产上先确认有查询权限：

-- 查某个角色的授权对象与字段取值，用于比对两个角色差异 -- AGR_1251 是角色授权值表，AGR_DEFINE 是角色主表 SELECT d.AGR_NAME, a.OBJECT, a.FIELD1, a.LOW1, a.HIGH1, a.FIELD2, a.LOW2, a.HIGH2 FROM AGR_1251 a JOIN AGR_DEFINE d ON d.MANDT = a.MANDT AND d.AGR_NAME = a.AGR_NAME WHERE a.MANDT = '100' AND d.AGR_NAME = 'Z_FI_DISPLAY' ORDER BY a.OBJECT, a.FIELD1;

MANDT是集团号，跨集团统计时必须带上，否则看到的是别的环境的数据；AGR_NAME是角色名；OBJECT对应 SU21 里的权限对象名。FIELD1/LOW1/HIGH1到FIELD2/LOW2/HIGH2是授权字段及其取值区间，LOW1为空通常意味着没有限定，配合HIGH1看是否被填成了通配。这段 SQL 只读不写，但直接查生产库表仍有风险，能迁到测试环境跑就别在生产上跑。

2.3 SU53 定位与 SU10 批量收口

用户报「点进去说没权限」，标准动作是让他立刻做一个报错截图，里面往往带着「权限对象 XX 的值 YY 检查失败」。SU53 显示的是当前用户最近一次权限检查失败的对象和值，非常好用——但它只保留最近一次，用户中途点过别的按钮，信息就被覆盖了。所以我在企业微信群里放的模板永远是「报错截图 + 时间点 + 事务码」，必要时按时间点去 SM20 审计日志里反查。

SU53 只解决一个人的问题，SU10 解决一批人的问题。批量修改的典型场景：一批合同工到期要统一锁定、一个部门换岗要统一改用户组、某个角色下线要统一解绑。SU10 支持按用户组、按角色、按地址信息把人筛出来，一次改完。这里的翻车点在于筛条件写得宽，勾了几百人，改完才发现多改了一批——所以做批量之前先跑一次「显示」，把名单导出来核对，确认无误再执行。

账号安全这块还有两个配套事务码值得常开：SM20 安全审计，看谁在什么时候用什么账号做了什么；SM19 是它的配置入口，审计级别开到几档直接影响性能，生产上一般是重点用户重点记录，不会全量开满。这两件事放到一起，才叫「权限管得住」。

3. 集团与传输：SCC4 设开关、SCCL 搬数据、STMS 走队列

集团（Client）操作是 BASIS 里最容易「一失手成千古恨」的部分，因为它动的是整库级别的数据。SCC4、SCCL、SCC1、SCC5、SCC3 这五个事务码背后有一条固定顺序：先改属性允许，再拷贝，拷贝后校验，最后把属性改回去并留日志。传输侧则是 SE09 释放、STMS 排队导入，顺序错了就得重来，重来还不一定干净。

3.1 SCC4 的开关：拷贝之前先把属性定死

SCC4 里每个集团有几项关键设置：集团角色（定制/测试/生产）、跨集团对象更改许可、保护级别、集团名和城市。生产集团的跨集团对象更改必须设成「不允许更改」，这不是建议是底线，否则有人在生产环境上直接改一个跨集团配置，重启后直接生效，没有任何传输记录可以回溯。

拷贝集团之前要做的：

1. 确认目标集团是空的，或者确认允许被覆盖（SCCL 不会问你要不要保留，它就按你的选择做）；
2. 把源集团的「更改与跨集团对象」临时改成允许状态，拷贝完成后立刻改回；
3. 确认源集团此刻无人登录，SCCL 会检查，有人在线就中断；
4. 确认目标集团没有正在跑的后台作业。

第 3 步经常被忽略。拷贝计划到晚上十点，九点半还有人挂着会话没退，作业启动直接失败，第二天业务照常开工，数据是旧的。所以我一般在 SCCL 计划前半小时用 SM04 和 AL08 各看一遍在线用户，必要时提前通知踢人，而不是等作业报错再去解释。

3.2 SCCL 与 SCC1：整体搬家和单请求搬移的边界

SCCL 做的是整集团拷贝，适合建新环境、把生产数据刷到测试。它有几个必填参数：源集团、目标集团、要拷贝的配置文件（SAP_ALL / SAP_USER / 自定义）、是否拷贝数据表。SAP_USER 只带用户主数据和权限，SAP_ALL 带业务数据，选错的结果是测试环境里查不到一条单据，或者生产用户数据被覆盖。

SCC1 做的是「系统内传输单个请求」，作用范围完全不同。它的典型用法是：某个传输请求里带着表数据（定制表的内容），跨系统传输时只走结构不走数据，那就先用 SCC1 把这个请求在本系统内导一次，把数据带进来。很多人把 SCC1 当成「小号 SCCL」，结果导完了发现只进来了一个请求里的东西，别的配置还是旧的。

注意：SCC5 删集团只在目标集团确实可以丢弃时才用。它会清掉该集团下的应用数据，执行前先把数据库备份做一次，并且确认备份可用——这一点在第 5 章还会再说，SAP 里「备份跑过了」和「备份能恢复」是两件事。

3.3 STMS 队列与 SE09 释放：顺序错了就得重来

SE09 释放传输请求，先释放任务再释放请求。系统一般会自动按顺序走，但如果有人手工删了其中一个任务，或者两个请求之间有依赖关系却没排好序，导入端就会报「对象不存在」或者「前置请求未导入」。我的习惯是释放前先在 SE09 里展开看一眼请求里的对象清单，确认没有把不该带的调试代码、临时表结构带进去。

STMS 是传输管理的中枢：传输域配置、系统路由、队列、导入监控。跨系统传输时，请求先进入目标系统的队列，再按顺序导入。队列卡住的第一现场永远是日志，传输日志在/usr/sap/trans/log，另外还有/usr/sap/trans下的 cofiles（请求头）和 data（数据文件）。

# 以 <sid>adm 身份执行，检查传输目录的空间与最新日志 SID=PRD TRANS_DIR=/usr/sap/trans # 1) 传输目录所在文件系统使用率，超过 80% 就该清理旧请求 df -h "$TRANS_DIR" # 2) 各子目录占用，data 目录通常是增长最快的一个 du -sh "$TRANS_DIR"/log "$TRANS_DIR"/cofiles "$TRANS_DIR"/data 2>/dev/null # 3) 最近一天内有更新的传输日志，按时间倒序看最新几条 find "$TRANS_DIR/log" -type f -mtime -1 \ -printf '%TY-%Tm-%Td %TH:%TM %10s %p\n' | sort -r | head -20

df -h的-h是人可读单位，看Use%那一列；du -sh的-s是汇总、-h同样是可读单位。find里的-mtime -1表示 24 小时内修改过的文件，-printf自定义输出格式，%TY-%Tm-%Td %TH:%TM拼出时间，%10s是右对齐 10 字符的文件大小，%p是完整路径，最后sort -r按行倒序、head -20只看最新 20 行。这套组合在清理传输积压时特别顺手：先看空间，再看哪个请求的最新日志在报错，日志文件名的前缀通常就带着系统标识和请求号。

传输队列卡住的第二现场是「目标系统有人正在改同一个对象」，导入时锁冲突。这时候不是去 STMS 里硬重试，而是先用 SM12 看锁，找到持锁用户和会话，联系对方退出，再重新导入。硬重试的结果往往是导入一半、状态不一致，后面更难收拾。

4. 系统巡检：ST22、SM13、SM12 与 OS 日志的查看顺序

巡检这件事最怕做成「挨个点一遍然后点关闭」。同样是看 ST22，有人看一眼数量是 0 就走，有人会点开最近三条 dump 看运行时错误是不是同一个程序反复出错。顺序比工具更重要，我一般按「错误 → 阻塞 → 资源 → 趋势」四层往下走，先看有没有已经出事的地方，再看有没有正在恶化但还没爆的地方。

4.1 每天早上先看三个：ST22、SM13、SM12

ST22 是 ABAP 短存储（short dump），报表或事务因为严重错误终止时会在这里留一条。判断标准不是「有没有 dump」，而是「同一个程序、同一个运行时错误是不是在重复出现」。偶发一条DBIF_RSQL_SQL_ERROR可能是数据库瞬时超时，一天出现二十条同一个程序，那就是代码里在硬编码扫大表，得丢给开发改。看 dump 时重点看三样：运行时错误名、出错程序名、发生时间点，这三样凑齐了才好判断影响面。

SM13 是更新记录，显示更新失败的动作。一个原则写在资料里也很直接：生产系统里更新失败绝不允许放着不管，因为它意味着业务单据的实际提交没有落库，用户界面上可能已经显示成功。V1 更新是同步的、V2 是异步的，V2 失败往往滞后暴露，所以每天必须清一遍 SM13 的失败清单，把更新键和用户捞出来，交给开发定位。

SM12 是锁管理。用户断线、程序异常、会话被杀，都可能留下一个没释放的锁，后面的人一操作就报「对象已被锁定」。SM12 里能看到锁的拥有者、事务码、表名和锁参数。处理方式有两种：让持锁用户退出会话，或者在确认对方确实已经不在操作的前提下手工删除锁。后者要谨慎，删错锁会导致数据不一致，「能删」和「该删」是两件事。

4.2 进程与负载：SM50、SM66、ST03、ST06 怎么看

SM50 是单个实例的进程概览，SM66 是全局进程概览（跨实例）。重点看进程类型和状态：DIA 是对话进程，BTC 是后台，UPD 是更新，ENQ 是锁管理。一个 DIA 进程长时间停在 Running 且 CPU 时间一直涨，通常是某个报表在扫大表；停在Priv模式说明进程内存超限，被系统切到私有内存，这时整个实例的响应都会受影响。

SM50 里可以直接终止进程，但终止前必须清楚后果：正在跑更新任务的进程被杀，可能留下半提交的数据。所以我的习惯是先看 SM21 系统日志和 ST22，确认是程序问题、并且已经联系上用户同意中断，再动手。杀进程这个动作在 OS 层也有对应手段，但有 OS 权限不等于有业务决策权，流程该走还得走。

ST03（新版本里是 ST03N）是工作负载分析，看平均响应时间、数据库时间、CPU 时间、用户分布、事务排行。这份数据最有价值的时刻恰恰是系统正常的时候——系统正常时留一份基线，出问题时才知道是「本来就这么慢」还是「突然变慢」。资料里那句「没有经验的替代品」说的就是这个意思：性能调优的痛苦，多半来自平时没攒数据。

ST06 是操作系统性能，看 CPU、内存、页空间（page space）、文件系统。ST06 的数值要从 SAP 应用服务器视角解读，它反映的是这台主机上跑 SAP 实例的进程占用，不是整机。判断页空间是否吃紧，看的是换页速率而不是占用率，占用率高了不一定坏，持续换页才是真问题。

4.3 OS 侧日志：四条路径加一段巡检脚本

SAP 的事务码给的是应用层视角，OS 层日志才是「黑匣子」。日常最常翻的四类：启动日志在/home/<SID>adm下，进程日志在/usr/sap/<SID>/DVEBMGS00/work下（dev_disp、dev_w0这类文件），传输日志在/usr/sap/trans/log，数据库侧的 trace 目录随数据库类型不同，常见结构是<db_vendor>/<SID>/saptrace/background，具体路径以现场为准，别照抄。

把这四条路径固定成一段脚本，比每天手工点四个窗口靠谱：

#!/bin/bash # 用法: ./basis_check.sh PRD 需要以 <sid>adm 或有读权限的账号执行 SID=${1:?用法: ./basis_check.sh <SID>} sid=$(echo "$SID" | tr 'A-Z' 'a-z') ADM=/home/${sid}adm WORK=/usr/sap/${SID}/DVEBMGS00/work TRANS=/usr/sap/trans/log echo "===== 1. 文件系统（只打印使用率 > 80% 的行） =====" df -hP / /usr/sap /usr/sap/trans 2>/dev/null | awk 'NR==1 || $5+0>80' echo "===== 2. 最近一次启动日志的尾部 =====" ls -t "$ADM"/startsap*.log 2>/dev/null | head -1 | xargs -r tail -n 20 echo "===== 3. 工作进程日志中的错误关键字 =====" grep -iE 'error|fatal|panic' "$WORK"/dev_* 2>/dev/null | tail -n 20 echo "===== 4. 最新传输日志的尾部 =====" ls -t "$TRANS"/SLOG* 2>/dev/null | head -1 | xargs -r tail -n 15

第一段df -hP的-P是 POSIX 输出格式，保证列位置固定，否则awk取$5会错位；awk 'NR==1 || $5+0>80'保留表头行，再筛出使用率数值大于 80 的挂载点，$5+0把带百分号的字符串转成数字比较。第二段ls -t按修改时间倒序列出启动日志，head -1取最新一份，xargs -r在没有输入时不执行后面的tail，避免空路径报错。第三段对工作进程日志做关键字过滤，-i忽略大小写，-E用扩展正则。第四段同理取最新的传输日志。

脚本本身不复杂，价值在于把「今天我该看哪几眼」变成固定动作，不依赖记忆。实际用的时候我会把它挂到一台跳板机的计划任务里，每天早上把输出发给自己，看到异常再去事务码里深挖。

5. 常见问题排查：五个「显示成功但实际没成」的坑

SAP 里最耗时间的不是报错，是「看起来成功了」。界面绿勾、状态 completed、作业 finished，业务那边一句「东西没出来」，就得从头翻。下面这五条都是血泪经验堆出来的，每一条都能对应到工作里真实发生过的返工。

5.1 数据库侧的两个假象

现象一：DB12 里备份日志显示成功，真出问题时恢复不出来。

原因通常有三个：备份写到了磁带或某个共享目录但没做校验；归档日志（archive log）中途断了，备份只覆盖到断点之前；备份文件被后续的清理脚本删了一部分。DB13 里配的是日常维护日历（备份、数据库检查、优化统计更新都挂在这），它只负责「按时发起」，不负责「结果可用」。

解决方式是把「备份成功」的判断标准从「DB13 里有绿勾」改成「最近一次恢复演练通过」。具体动作：DB12 看备份日志和历史；确认归档日志连续，日志目录剩余空间要单独监控；定期在测试环境做一次恢复，恢复完对一遍关键表的行数。BRTOOLS 是 OS 层的数据库管理工具，做恢复演练时比图形界面更可控，但这套工具的操作权限要单独管，不能让所有人随手能跑。

现象二：DB02 里表空间和索引一直没人看，某天突然扩不动。

DB02 监控数据库表和索引的增长、碎片情况，还带优化统计的信息。日常最该看的是表空间的剩余空间和增长速率，以及大表的索引碎片。没人看的后果是磁盘写满，数据库挂起，整个 SAP 实例不可用——这时候再清日志、扩表空间，业务已经停了半小时。

解决动作很朴素：把 DB02 的关键指标纳入每日巡检，设一条「剩余空间低于阈值就告警」的线；对增长快的表提前做归档或分区，不要等到报警再想办法。这不是技术难题，是纪律问题。

5.2 作业与打印的两个假象

现象三：SM37 里作业状态是已结束（Finished），但业务说数据没生成。

原因一般是作业里的程序自己捕获了异常没往外抛，SAP 认为它正常退出。也有一种情况是作业启动时带的选择参数和预期不一致，跑是跑了，跑的不是那份数据。

解决方式：SM37 不要只看状态列，要看假脱机（spool）列表里有没有输出、输出内容对不对。资料里那句「检查所有日志包括输出列表」就是这个意思。对关键作业，我会额外在作业步骤里加一步写日志表，作业跑完把影响行数落库，第二天直接查行数比对，比翻 spool 快。

现象四：SP01 里假脱机请求显示完成，打印机没出纸。

这是打印管理里最经典的坑。SAP 只跟踪打印任务到目标队列，输出控制器里显示「已完成」并不代表纸上真的打出来了。常见原因是用户 PC 上的 SAPLPD 程序被关掉了、打印目标队列指向了错误的设备、或者纸张/驱动问题。

解决路径：先在 SP01 里看请求状态和目标设备，再在 SPAD 里确认设备定义和输出设备的主机名、访问方式是否对得上；失败的任务可以重启，但重要和大量的打印任务在从 TemSe 里删除之前必须确认实际已输出，否则重打不出来。

5.3 参数侧的一个假象

现象五：RZ10 改完参数，RZ11 里查到还是旧值。

RZ10 改的是配置参数文件，RZ11 查的是运行时的当前值，两者不同步是常态。参数分动态和静态：动态参数改完保存、激活后立即生效；静态参数必须重启实例才生效。还有一种情况是改了实例参数文件，但默认参数文件里也有一份同名参数，加载顺序导致你以为改的那份没被读到。

解决方式：RZ10 改完先「检查」再「激活」，然后去 RZ11 确认值变没变；静态参数安排到变更窗口重启，重启后用 SM21 和启动日志确认参数被正确加载。像rdisp/gui_auto_logout这种会话超时参数是动态的，改完即时生效；而涉及内存和进程数量的参数基本都是静态的，改之前先想清楚这次重启什么时候能批下来。

6. 把巡检压成 20 分钟：一份可落地的日常清单

我做 BASIS 的前两年，每天到岗第一件事是打开十几个事务码挨个点一遍，快则四十分钟，慢则一上午。后来把「看什么、看哪个值、超过多少算异常」固定成一张表，巡检时间压到二十分钟，剩下的时间留给真正需要判断的事。

表是骨架，落地还得靠脚本把「打开十几个窗口」这一步省掉。第 4 章那段巡检脚本可以直接跑，但真正省时间的是把输出按「异常 / 正常」两段分开，异常段没人看就等于没写。我自己的做法是脚本输出里只保留需要人判断的行：文件系统只打超阈值的，日志只打包含错误关键字的，其余全部丢掉。

关于怎么把这件事学扎实，资料里提的四点我认同其中三条。「手脑动」——先做用户支持，一天接十几个「我登不上」「我没权限」，比闷头看安装文档快得多，因为你会从使用者视角理解每个事务码到底在改什么。「广泛学」——BASIS 装的系统是给业务用的，不了解业务模块在跑什么，性能调优就是瞎猜。「向前看」——SAP 的产品线一直在变，OS、数据库、应用层、Web 层的知识都得跟着更新。至于「自答问」，可以理解成把每次排查结论沉淀下来：同一个错误第二次出现时，你应该能在三分钟内找到上次的记录，而不是重新查一遍。

一个具体的技巧是给所有关键动作留「后悔药」。改 SCC4 之前先截图保存原值，改 RZ10 之前先把参数文件导出一份，删 SM12 的锁之前记录锁的拥有者和事务码，做 SCC5 之前确认备份可恢复。这些动作每次多花两分钟，真出事时能省两天。

有人问我最初的教训是什么：刚上手时觉得装系统才是 BASIS 的本事，日常巡检是杂活，结果一次测试集团拷贝把生产用户的邮箱全刷成了测试数据，一次 RZ10 改完没重启就通知业务「已优化」，被追着问了两天。从那以后我每次动生产配置，都强制走一遍「截图原值、记录变更单、确认回退方案」，哪怕只是改一个打印设备。希望帮到你。

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