企业官网建设流程全解析

简介：在企业的信息化体系中，SAP系统的稳定运行离不开高效的日常运维。BASIS作为SAP的技术管理核心，要求运维人员掌握一套结构化的事务代码操作体系。用户权限的分配与解锁、数据库的备份与验证、后台作业的调度与监控、传输请求的发布与跟踪，共同构成了运维工作的基础。比如SU01负责用户管理，PFCG维护角色权限，DB13管理数据库维护计划，SM36/SM37控制后台作业，STMS处理跨系统传输。从技术原理上看，这些事务代码并非孤立存在，而是通过日志与状态相互关联，形成系统巡检的闭环。理解这些工具的价值在于，当系统出现性能下降、打印失败、备份异常或权限报错时，运维人员能快速定位根因，避免盲目操作带来的影响。在实际应用场景中，无论是每日早上的常规检查，还是变更上线的传输流程，这张事务代码地图都能提供清晰的方向。这份运维知识地图与易漏点清单，正是为了帮助BASIS从业者从按下按钮的机械操作升级为掌控全局的主动管理。

1. BASIS 运维知识地图：60 个事务代码撑起的日常

很多人以为 BASIS 是 SAP 的“安装工”——装好系统、调好参数就完事了。真正干过运维会发现恰恰相反：BASIS 的日常不是安装配置，而是用户权限、集团管理、数据库备份、后台作业、打印、监控、传输这几条线反复交叉的长期值守。系统能不能稳定跑，不取决于上线时实施做得有多漂亮，而取决于运维每天有没有把该看的东西看一遍。梳理完这份 SAP 日常运维 BASIS 笔记，最直观的感受是：整个岗位就是一张事务代码地图，SU01 管人、SCC4 管集团、DB13 管备份、SM36 管作业、SPAD 管打印、ST06 看性能、STMS 管传输，各占一块，互相独立又彼此牵连。适合正在学 BASIS 的人拿来搭体系，也适合已经上手但总觉得自己在“点按钮、不知道全局”的人对照查漏——从这张地图出发，逐个模块过一遍，心里就有底了。

2. 用户权限与集团：BASIS 日常里最频繁的两件事

2.1 SU01 能做的不只是建用户

用户权限管理是 BASIS 运维里操作频率最高的一块。SU01 是最核心的事务代码，创建、修改、显示用户信息都走这里。但实际工作中 SU01 最常见的三个用途是：解锁、改密码、复制账号。

解锁和改密码很好理解——用户密码过期或者多次输错被锁，都是日常工单的高频来源。复制账号则是一个容易被忽略的效率操作：当新人要开通和某老员工相同权限的账号时，不需要重新配角色，直接基于已存在账号复制即可。素材里提到的场景是mycw12是已存在账号，MYCW14是要新建的账号，用 SU01 复制后，再微调差异即可。这个操作能省掉大量重复的角色配置时间，但复制后一定要检查，复制过来的账号可能带着旧人的个人信息、默认打印机、起始菜单，这些都需要按新人情况调整。

2.2 角色和权限对象的层级关系

如果说 SU01 是管“谁能用”，那 PFCG 就是管“能用什么”。角色在 SAP 权限体系里是中间层：权限对象（SU21 维护）由权限字段（SU20 维护）组成，角色把权限对象聚合起来，最后通过 SU01 分配给用户。三层结构是理解权限体系的钥匙。

最容易漏的是 SU53。用户报权限问题时，很多人第一反应是去 PFCG 里找角色改权限，但 SU53 能直接告诉你在当前事务代码下，系统拒绝了哪个权限对象、缺哪个字段值。先跑 SU53 再动角色，能避免“改了角色、影响了一堆人、结果还不是这个原因”的尴尬。权限问题排查顺序应该是：SU53 定位 → SU22 查事务代码关联的授权对象 → PFCG 找对应角色 → 调整后分发。

2.3 集团操作：SCC4 到 SCC5 的完整生命周期

集团（Client）是 SAP 特有的逻辑隔离单位。SCC4 负责创建、修改、显示集团属性，SCCL 拷贝集团，SCC1 做系统内单传输请求拷贝，SCC5 删除集团，SCC3 看日志。

SCCL 拷贝集团耗时很长，且不能随便中断；中途失败后，SCC3 是定位问题的第一入口。SCC1 用于在同一个系统内，把某个传输请求从一个集团复制到另一个集团——这和不跨系统传输是两个概念，很多人一开始会把 SCC1 和 STMS 搞混。集团层面最容易翻车的是：SCC4 里把某个集团设为“不可更改”后，忘了改回来，导致配置传输进不来；SCC5 删集团前没确认备份，删完才发现里面还有测试数据。删集团是“后悔药”很少的操作，动手前务必确认。

3. 数据库、备份与后台作业：黑匣子打开之后其实有套路

3.1 DB13 不只是“备份按钮”

数据库管理是 BASIS 里容错率最低的模块。DB13 是数据库日常维护日历，绝不只是每天看一眼备份成不成功那么简单。它背后是三条并行的维护线：备份、检查、统计。素材里明确提到，DB13 里能看到数据库备份、CHECK DATABASE、OPTIMIZER STATISTICS UPDATE 等后台作业，并且可以查看这些作业的日志。

DB02 是很多人忽略的重灾区。备份没失败不代表数据库健康——表空间持续扩张、索引碎片堆积，最终会在某一天触发“表空间不足”或者“SQL 性能骤降”。DB02 的价值在于趋势观察：今天的扩张速度和上周比怎么样？碎片率是不是在缓慢上涨？这些问题在 DB12 里看不到，在 DB13 的备份日志里也看不到，只能靠 DB02 长期观察。

BRTOOLS 则是把视角从 SAP 层拉到操作系统层。它是在操作系统上直接运行的数据库管理工具，可以做备份、恢复、日志切换、一致性检查。日常运维里，DB13 排的是计划任务，BRTOOLS 解决的是“计划之外”——比如手工做一次恢复演练，或者数据库异常时做离线检查。建议运维至少完整操作一次 BRTOOLS 的备份和恢复流程，才能真正理解 DB13 在后台替你做了什么。

3.2 夜间备份的验证闭环

备份验证是 BASIS 里最典型的“平时没事、出事才想起”的场景。DB12 检查备份日志，不能只看“备份成功”四个字，要确认备份文件实际写入了磁盘、文件大小没有异常、日志目录空间充足。这里的坑在于：有些备份作业显示成功，但备份文件因为磁盘满或者路径问题实际没写全，系统不会主动报错，直到恢复时才发现“备份不可用”。

一个可以照做的日常检查序列：先看 DB13 里所有维护作业的当日执行状态 → 再进 DB12 核对备份日志，确认备份文件和时间戳 → 最后看一眼 DB02 的表空间增长趋势。三步走完，数据库这一块才算真正“看过”了。这套顺序最好固定下来，做成每天早上的例行动作，不要等出了问题再去翻日志。

3.3 SM36 和 SM37：后台作业的完整生命周期

后台作业管理是 BASIS 日常工单的重要组成部分。SM36 定义后台作业——设置作业名、步骤、开始条件（立即执行、定时执行、事件触发）、运行服务器；SM37 监控作业执行情况，重点是检查被取消的作业，分析原因、修正后重启，并记录问题和解决方案。

SM37 的检查不能只挑红着的看。作业执行成功但逻辑没生效，比作业失败更难查——比如某个接口作业显示“完成”，但处理的数据量是 0，这种不会报错，只能对比过往输出判断。所以 SM37 的正确打开方式是：看状态，也要看输出列表。取消的作业要分析是程序问题、权限问题还是资源不足；长时间运行的作业要判断是正常慢还是卡死——判断标准最好是手头有历史运行时长的记录，否则全凭感觉。

后台作业里还有一个常见误用：作业的“步骤”不区分 ABAP 程序、外部命令、外部程序，不同步骤类型的错误日志位置不同。ABAP 程序报错看 SM37 日志，外部命令报错可能要看操作系统层面的日志，很多作业改了步骤类型后莫名失败，就是在这里踩了坑。

4. 打印管理、系统监控与日志分析：一眼看穿系统的状态

4.1 SPAD 与 SP01：打印问题的两个排查入口

打印管理模块不大，却常常是工单数量最多的模块之一。SPAD 定义打印设备——打印机名称、设备类型、输出队列；SP01 管理假脱机请求和输出请求。用户报“打印不出来”时，SP01 是第一排查入口。

素材里有一段非常实操的提示：SP01 里能查看有没有假脱机请求，如果有可以删除，失败的打印任务可以重新启动，而这些打印任务的失败往往是用户端问题，比如 PC 上的 SAPLPD 程序被关闭了。更要留意的是：SAP 系统只跟踪打印任务到目标队列为止，输出控制器里显示的“已完成”状态，并不代表实际打印成功。因此，重要和大量的打印任务在被从 TemSe（临时顺序文件）中删除前，必须先确认是否真的完成了。

这是打印管理里最容易被忽略的认知断层。SAP 说“已传给打印机了”，和打印机真的吐出一张纸，中间隔着一整条用户端链路——SAPLPD 是否在运行、打印机是否在线、驱动是否匹配。所以处理打印工单的顺序应该是：SP01 看假脱机请求状态 → 确认队列里有无积压 → 联系用户确认打印机端状态 → 再决定是重启动、删除还是换队列。

4.2 ST06 与 ST03：性能看板的两个维度

系统监控是 BASIS 日常工作中信息密度最高的部分。ST06 看操作系统性能，每天观察 CPU 使用率、内存使用率、PAGE SPACE 使用率；ST03 看 R/3 工作负载，是分析 SAP 应用层性能的核心入口。

两者的关系可以理解为：ST06 是“物理层体检”，ST03 是“应用层账本”。CPU 满了不一定是物理资源不够，可能是某个报表程序在跑全表扫描；ST03 能告诉你哪些事务代码最耗资源、哪些时段负载最高、关键事务的响应时间在什么区间。

素材里有一句话值得反复读：管理员应该保留尽可能多的工作量分析数据，特别是系统没有性能问题时候的数据——“拥有一副系统工作正常时的清晰的系统图，将使你具有对你的系统的不可估量的感觉”。这句话是性能调优的底层方法论：调优最难的不是处理故障，而是不知道“正常长什么样”。建议从接手系统第一天起，定期把 ST03 的关键指标导出存档，坚持一段时间后，再遇到系统慢，你能快速判断是新问题还是老问题，是和上次一样的波动还是真出了状况，而不是像进了黑匣子一样瞎猜。

4.3 进程、锁、更新：SM50 到 SM13 的联动排查

系统监控里有一串事务代码，各自负责一个维度：

• SM04 / AL08：看当前在线用户，一个区分服务器，一个不区分；
• SM51：R/3 服务器概览，列出所有应用服务器；
• SM50：某台服务器的工作进程概览，可以 kill 掉异常进程；
• SM21：系统日志，记录系统事件和问题；
• SM12：锁管理，处理被锁定的对象；
• SM13：更新记录，查看失败的更新动作；
• ST22：ABAP short dump 分析，报表或事务因严重错误终止时，系统在表 SNAP 中记录出错信息；
• SM20：安全审计日志。

这些代码不是孤立存在的。一个典型的排查路径是：SM50 发现有进程长时间占用工作进程 → 去 SM04 看是哪个用户触发的 → 如果涉及数据修改，进 SM13 看更新是否失败 → 再到 SM21 看有无错误日志 → 最后用 ST22 看有没有对应的 short dump 记录。四五个事务代码串起来，才能拼出一个完整的故障画面。

这里要单独强调三点。第一，SM50 杀进程前必须与最终用户协商——素材里明确说在杀掉这些进程前需要与最终用户协商，因为直接 kill 可能导致用户未保存的数据丢失，这是实践中容易引发投诉的操作。第二，SM12 锁管理要盯“老对象”——用户断线、程序出错都会导致对象锁残留，长期不清理会阻塞其他用户的操作。第三，SM13 里失败的更新动作在生产系统里绝对不允许存在，发现即处理，哪怕只是零星几次，也可能预示着程序逻辑或主数据有问题。

4.4 日志体系：四个目录搞清日志去哪找

日志查看是 BASIS 排障的基本功，素材里给出了四个固定位置：启动日志在/home/＜SID＞adm，进程日志在/usr/sap/＜SID＞/DVEBMGS00/work，传输日志在/usr/sap/trans/log/，数据库日志在 oracle 目录下的/oracle/＜SID＞/saptrace/background。

# 以 SID 为 PRD 为例（实际按系统内 SID 替换） # 查看启动日志 ls -lt /home/prdadm/ | head # 查看进程日志（DVEBMGS00 为实例目录，E 表示应用服务器） cd /usr/sap/PRD/DVEBMGS00/work ls -lt *.log | head tail -f dev_disp # 查看传输日志 cd /usr/sap/trans/log ls -lt | head # 查看数据库后台日志（Oracle 数据库路径示例） cd /oracle/PRD/saptrace/background ls -lt | head

日志位置定了，排障时先查哪个就有讲究：系统起不来优先看启动日志和dev_disp进程日志；传输出问题去看传输日志；数据库相关异常直接去数据库 trace 目录。最容易犯的错是拿进程日志去分析数据库问题、拿传输日志去查启动故障——工具拿错了，排查方向就偏了。

4.5 其他高频事务代码补充

除了上述几类，素材里还列了几个日常会用到的事务代码：SSAA 系统管理助手，相当于 BASI 功能入口汇总，适合不熟事务代码时按图索骥；SM02 发系统消息，比如系统计划停机时提前通知所有在线用户；SM59 定义远程连接，看 RFC 目标是否可用；RZ10 改参数、RZ11 查参数。其中 RZ10 改的是配置文件里的静态参数，改完通常要重启实例才能生效，RZ11 改的是动态参数，可以在线生效——这两者的区别最容易混淆，也是“改了没生效”问题的常见原因。动手前先用 RZ11 查一下参数的可动态性，能省掉一次不必要的重启。传输管理相关的 SE09 和 STMS 在下一章单独展开，因为它们和变更流程绑定得更深。

5. 传输管理流程与易漏点：变更上线的完整链路

5.1 SE09 与 STMS：一个管请求，一个管分发

传输管理是 BASIS 与开发协作最频繁的模块，也是流程理解成本最高的模块。SE09 管理传输请求——创建改变请求、分配改变任务、释放请求；STMS 负责传输管理，包括集团策略、系统内传输、跨系统传输、传输队列。两者分工明确：SE09 管“请求在源系统内怎么组织”，STMS 管“请求在系统之间怎么走”。

梳理下来会发现，很多初学者卡在“传输请求”和“传输任务”的区别上。简单说：改变请求是容器，属于某个变更项目；改变任务是具体的工作单元，开发人员在自己的系统里干活时创建任务，任务挂到请求下，请求释放后，任务跟着走。日常运维里，BASIS 更常和 STMS 打交道——看传输队列有没有卡住、传输是否成功、集团策略是否正确。

5.2 同一系统内的三种传输，最容易混

SAP 的传输有多个层次，素材里集团管理部分的 SCC1 就是“系统内传输（拷贝）单个传输请求”。这涉及一个高频混淆点：SCC1 和 STMS 里的系统内传输到底什么关系？

简单区分是：SCC1 是直接在一个系统内的集团之间拷贝请求，比如把开发集团的某个配置拷贝到测试集团；STMS 是把请求按传输路径从一个系统发到另一个系统，比如开发系统传到 QA 系统。跨系统的请求传到目标系统后，如果目标系统里配置了集团策略，会自动分发到指定集团。素材里 STMS 的说明明确覆盖了“集团策略、系统内传输、跨系统传输、传输队列”这几个概念，说明 STMS 本身也能处理系统内传输——关键区别在于 SCC1 是手工拷贝单请求，STMS 是按线路和队列自动分发。实际运维中，小范围、紧急的单请求复制可以直接用 SCC1，大批量、按流程走的变更必须走 STMS。

5.3 传输问题排查的基本顺序

传输故障是 BASIS 运维里比较让人头疼的一类问题，因为报错可能出在多个环节：请求没释放、传输队列卡住、目标系统导入失败、集团策略不对、RFC 连接断了。一套可行的排查顺序是：先看 SE09 确认请求是否已释放 → 进 STMS 看传输队列里请求的状态（是否在等待、是否报错）→ 看传输日志/usr/sap/trans/log/里的具体报错 → 确认目标系统集团策略允许导入 → 还可以用 SM59 检查源系统和目标系统之间的 RFC 连接。

传输日志是定位问题的核心依据，常见的报错类型包括：版本冲突（目标系统已有同编号对象）、组件缺失（依赖的请求没一起传）、权限不足（目标系统导入账号权限不够）、序列出错（请求的先后顺序乱了）。这些错误基本都是可以通过日志快速判断的，难的是很多运维只看“传失败了”就干等，不去开日志——这是传输管理里最浪费时间的做法。

5.4 本章易错点清单：五个最容易漏的环节

易漏点 1：SU53 权限检查没有按“先定位后修改”的顺序来。用户报无权限，第一反应就是去 PFCG 改授权对象。但如果缺失的是某个字段值而不是对象本身，改角色等于白改，还影响所有同角色用户。正确做法是先跑 SU53 看具体拒绝的是哪个对象、哪个字段，再决定是调角色、补参数文件，还是该权限其实不该给。

易漏点 2：ST03 工作负载数据没有留存“健康时”的基线。性能调优最难的不是处理故障，而是不知道“正常长什么样”。很多人只在系统出问题时才打开 ST03，等出了问题再想对比，发现历史数据早已被覆盖，只能凭感觉判断是“卡了”还是“就这速度”。建议每周围绕 ST03 定期留存一份关键指标快照，坚持一段时间后，系统慢和正常波动一眼可分。

易漏点 3：SP01 里的“已完成”不等于打印机真的打印了。SAP 只保证把打印任务传到目标队列，输出控制器里显示的完成状态和实际打印成功之间隔着一条用户端链路。重要打印任务在 TemSe 中删除前，必须先和用户确认纸质或 PDF 输出确实生成。这条逻辑不知道的话，很容易在用户投诉“没打出来”时发现作业已被清掉，连重新触发的依据都没了。

易漏点 4：SM50 杀进程前没有和最终用户确认。长时间运行的后台作业、有缺陷的报表程序会大量消耗系统资源，杀掉异常进程前必须与最终用户协商。直接 kill 可能让用户正在处理的数据瞬间消失，比系统慢更让用户崩溃。任何杀进程操作前，先确认是谁的任务、是否可中断、有没有替代方案。

易漏点 5：RZ10 和 RZ11 的生效机制混淆。RZ10 改的是静态参数，通常要重启实例才生效；RZ11 改的是动态参数，可以在线生效。用 RZ10 改完发现系统没变化，大概率是没重启；用 RZ11 改了个静态参数，重启后又被配置值覆盖，大概率是没查清楚参数类型。改任何参数前，先 RZ11 查该参数的可动态性，再决定用哪个事务代码。

5.5 其他事务代码速查表

素材里“其他”部分的事务代码在日常工作中同样高频，单独列出便于复习时速查：

6. 复习清单与查漏补缺：从事务代码表到运维习惯

走到最后一步，这份笔记的用途就明确了：拿来复习，而不是放在收藏夹里吃灰。前面几章的知识点，到最后要能压缩成一张“能默写出来”的运维地图。推荐的自检方式是：不看资料，把九大模块的事务代码按模块默写一遍——用户权限 7 个（SU01、SU10、PFCG、SU53、SU21、SU20、SU22），集团 5 个（SCC4、SCCL、SCC1、SCC5、SCC3），数据库（DB13、DB02、DB12、BRTOOLS），后台作业（SM36、SM37），打印（SPAD、SP01），系统监控（ST06、ST03、SM04、AL08、SM21、SM51、SM50、SM12、SM13、ST22、SM20、SM66），传输（SE09、STMS）。默写不出来的，就是查漏补缺的起点。

默写完事务代码，再做一轮“场景→代码”的逆向训练：用户被锁了用哪个代码？备份失败看哪个日志？打印机没反应查什么？传输卡了看哪里？能不看资料回答上来，才算真正记住了。这一轮训练比背代码表有效得多，因为日常工作中你遇到的从来不是“SU01 是干什么的”，而是“用户说密码不对打不开系统”——这两个问题的查漏方式完全不同。

复习的最后一步，是把自己平时容易漏的动作列成检查清单。我自己的习惯是每天早晨固定走一遍：DB12 看夜间备份 → SM37 看后台作业 → ST22 查 short dump → SM12 看锁对象 → SM21 扫一眼系统日志 → ST06 看资源占用。每次出现“漏看”导致的问题，就强制在清单里加一项。从那以后，我每次处理完一个故障，都会顺手写进自己的问题集锦，包括现象、排查路径、解决方法和当时的教训——素材里“手脑动、广泛学、自答问、向前看”那四句，落到日常就是这么件事：动手验证、跨模块了解、主动记录问题、持续更新版本知识。这份笔记提供的是地图，但地图只有在你每天拿出来用的时候才有价值。希望帮到你。

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