简介在企业的信息化体系中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 分配给用户。三层结构是理解权限体系的钥匙。事务代码职责典型场景SU01用户主数据维护解锁、改密码、复制账号SU10批量修改用户批量加锁、批量重置密码、批量调整参数PFCG角色维护创建角色、改角色菜单、分配权限对象SU53权限检查用户报“无授权”错误时分析缺失的具体权限对象SU21权限对象维护定义新的权限对象开发用得较多SU20权限字段维护维护权限字段的文本和值SU22事务代码授权对象维护查某个事务代码关联哪些授权对象最容易漏的是 SU53。用户报权限问题时很多人第一反应是去 PFCG 里找角色改权限但 SU53 能直接告诉你在当前事务代码下系统拒绝了哪个权限对象、缺哪个字段值。先跑 SU53 再动角色能避免“改了角色、影响了一堆人、结果还不是这个原因”的尴尬。权限问题排查顺序应该是SU53 定位 → SU22 查事务代码关联的授权对象 → PFCG 找对应角色 → 调整后分发。2.3 集团操作SCC4 到 SCC5 的完整生命周期集团Client是 SAP 特有的逻辑隔离单位。SCC4 负责创建、修改、显示集团属性SCCL 拷贝集团SCC1 做系统内单传输请求拷贝SCC5 删除集团SCC3 看日志。事务代码用途SCC4定义集团属性如跨集团授权、集团角色、更改记录设置SCCL拷贝集团跨集团复制配置和数据SCC1系统内传输单个请求远程拷贝传输请求SCC5删除集团SCC3查看集团复制/传输日志SCCL 拷贝集团耗时很长且不能随便中断中途失败后SCC3 是定位问题的第一入口。SCC1 用于在同一个系统内把某个传输请求从一个集团复制到另一个集团——这和不跨系统传输是两个概念很多人一开始会把 SCC1 和 STMS 搞混。集团层面最容易翻车的是SCC4 里把某个集团设为“不可更改”后忘了改回来导致配置传输进不来SCC5 删集团前没确认备份删完才发现里面还有测试数据。删集团是“后悔药”很少的操作动手前务必确认。3. 数据库、备份与后台作业黑匣子打开之后其实有套路3.1 DB13 不只是“备份按钮”数据库管理是 BASIS 里容错率最低的模块。DB13 是数据库日常维护日历绝不只是每天看一眼备份成不成功那么简单。它背后是三条并行的维护线备份、检查、统计。素材里明确提到DB13 里能看到数据库备份、CHECK DATABASE、OPTIMIZER STATISTICS UPDATE 等后台作业并且可以查看这些作业的日志。事务代码用途日常必看DB13数据库维护日历备份作业、CHECK DATABASE、统计更新作业及日志DB02表、索引监控表/索引扩张、碎片情况、优化统计DB12备份日志夜间备份是否成功、日志目录剩余空间BRTOOLS操作系统层数据库管理工具备份恢复、一致性检查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 监控作业执行情况重点是检查被取消的作业分析原因、修正后重启并记录问题和解决方案。事务代码用途关键检查点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看当前在线用户一个区分服务器一个不区分SM51R/3 服务器概览列出所有应用服务器SM50某台服务器的工作进程概览可以 kill 掉异常进程SM21系统日志记录系统事件和问题SM12锁管理处理被锁定的对象SM13更新记录查看失败的更新动作ST22ABAP short dump 分析报表或事务因严重错误终止时系统在表 SNAP 中记录出错信息SM20安全审计日志。这些代码不是孤立存在的。一个典型的排查路径是SM50 发现有进程长时间占用工作进程 → 去 SM04 看是哪个用户触发的 → 如果涉及数据修改进 SM13 看更新是否失败 → 再到 SM21 看有无错误日志 → 最后用 ST22 看有没有对应的 short dump 记录。四五个事务代码串起来才能拼出一个完整的故障画面。这里要单独强调三点。第一SM50 杀进程前必须与最终用户协商——素材里明确说在杀掉这些进程前需要与最终用户协商因为直接 kill 可能导致用户未保存的数据丢失这是实践中容易引发投诉的操作。第二SM12 锁管理要盯“老对象”——用户断线、程序出错都会导致对象锁残留长期不清理会阻塞其他用户的操作。第三SM13 里失败的更新动作在生产系统里绝对不允许存在发现即处理哪怕只是零星几次也可能预示着程序逻辑或主数据有问题。4.4 日志体系四个目录搞清日志去哪找日志查看是 BASIS 排障的基本功素材里给出了四个固定位置启动日志在/home/SIDadm进程日志在/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 本章易错点清单五个最容易漏的环节易漏点 1SU53 权限检查没有按“先定位后修改”的顺序来。用户报无权限第一反应就是去 PFCG 改授权对象。但如果缺失的是某个字段值而不是对象本身改角色等于白改还影响所有同角色用户。正确做法是先跑 SU53 看具体拒绝的是哪个对象、哪个字段再决定是调角色、补参数文件还是该权限其实不该给。易漏点 2ST03 工作负载数据没有留存“健康时”的基线。性能调优最难的不是处理故障而是不知道“正常长什么样”。很多人只在系统出问题时才打开 ST03等出了问题再想对比发现历史数据早已被覆盖只能凭感觉判断是“卡了”还是“就这速度”。建议每周围绕 ST03 定期留存一份关键指标快照坚持一段时间后系统慢和正常波动一眼可分。易漏点 3SP01 里的“已完成”不等于打印机真的打印了。SAP 只保证把打印任务传到目标队列输出控制器里显示的完成状态和实际打印成功之间隔着一条用户端链路。重要打印任务在 TemSe 中删除前必须先和用户确认纸质或 PDF 输出确实生成。这条逻辑不知道的话很容易在用户投诉“没打出来”时发现作业已被清掉连重新触发的依据都没了。易漏点 4SM50 杀进程前没有和最终用户确认。长时间运行的后台作业、有缺陷的报表程序会大量消耗系统资源杀掉异常进程前必须与最终用户协商。直接 kill 可能让用户正在处理的数据瞬间消失比系统慢更让用户崩溃。任何杀进程操作前先确认是谁的任务、是否可中断、有没有替代方案。易漏点 5RZ10 和 RZ11 的生效机制混淆。RZ10 改的是静态参数通常要重启实例才生效RZ11 改的是动态参数可以在线生效。用 RZ10 改完发现系统没变化大概率是没重启用 RZ11 改了个静态参数重启后又被配置值覆盖大概率是没查清楚参数类型。改任何参数前先 RZ11 查该参数的可动态性再决定用哪个事务代码。5.5 其他事务代码速查表素材里“其他”部分的事务代码在日常工作中同样高频单独列出便于复习时速查事务代码用途注意SSAA系统管理助手不熟事务代码时的功能入口汇总SM02系统消息发送停机维护前提前通知在线用户SM59远程连接管理排查 RFC 连接失败时优先检查RZ10修改系统参数静态参数通常需重启实例RZ11查询/修改动态参数先查参数属性再改避免无效操作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 看资源占用。每次出现“漏看”导致的问题就强制在清单里加一项。从那以后我每次处理完一个故障都会顺手写进自己的问题集锦包括现象、排查路径、解决方法和当时的教训——素材里“手脑动、广泛学、自答问、向前看”那四句落到日常就是这么件事动手验证、跨模块了解、主动记录问题、持续更新版本知识。这份笔记提供的是地图但地图只有在你每天拿出来用的时候才有价值。希望帮到你。本文还有配套的精品资源点击获取