简介：SAP BASIS日常运维速查手册面向企业SAP系统管理员、运维工程师以及正在转型SAP Basis方向的技术人员，针对日常巡检、用户权限调整、集团维护、数据库备份、后台作业、打印管理和系统监控等高频场景，提供可直接上手的事务代码与操作清单。资源为单个PDF文档，压缩包大小约2.02MB，目前已有962人学习使用。内容以科莱特SAP内训材料为基础，分模块梳理了用户权限管理、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理等核心事务代码，并单独列出SAP重要日志的查看路径，例如启动日志、进程日志、传输日志和数据库日志。同时，资料还给出了学习SAP BASIS的实用建议，说明实施与运维的侧重点差异，强调数据库备份和还原对数据安全的重要性。无论是刚开始接触SAP BASIS的新手，还是需要快速定位事务代码的资深运维人员，都能借此按图索骥，提升日常运维与问题排查的效率。
1. SAP BASIS 运维地图：先分清实施与运维两条线
很多人一听到 SAP BASIS 就以为是“装系统、调参数”，其实日常运维的 BASIS 更像是一个守着系统前台与后台之间的运营角色。梳理下来会发现，BASIS 运维的核心工作可以压缩成八个模块：用户权限、集团管理、数据库、后台作业、打印、系统监控、传输管理，以及参数与日志这类兜底事项。每个模块对应一组固定事务代码，真正上手之后，每天的巡检就是在这些事务码之间来回切换。适合读这份笔记的人有两类：一类是刚接手 SAP 系统运维、需要快速建立事务码地图的初学者，另一类是准备 BASIS 面试或复习的人，想把零散的操作点串成体系。本文不按“安装 SAP”这条线走，而是按“日常运维每天要看什么、坏了怎么查”这个角度来组织，先给出知识地图，再逐模块拆解重点，最后落成一份可自查的复习清单。
2. 用户与集团管理：SU01、PFCG 与 SCC 系列的权限脉络
用户权限是 BASIS 运维里被问得最多、也最容易出乱子的模块。它表面上只是“建账号、给角色”，但实际牵扯到权限对象、授权字段、角色生成参数文件，以及集团层面的拷贝与传输。把这层关系理清楚，后面排权限问题才会快。
2.1 用户维护的四个入口：SU01、SU10、SU53、PFCG
日常用户维护最常用的入口是 SU01。它承担三件事：创建用户、修改用户、显示用户信息。运维里用得最多的不是建号，而是解锁和重置密码。用户被锁定时，用 SU01 输入用户名，进入“锁定状态”页签解锁即可；忘记密码时，在这里重新初始化密码。注意解锁和改密之后，要提醒用户重新登录，因为密码变更不会影响当前已建立的会话，但下一次登录必须用新密码。
SU01 还有一个很实用的功能是复制账号。复制账号的意思是：基于一个已存在的账号（比如模板账号 myCW12），复制生成一个新账号 myCW14，新账号会继承原账号的角色和参数。这种做法适合快速开通一批权限相近的账号，尤其适合新员工入职，但要记住两个风险：一是复制的账号与原账号共享同一套角色，后续原账号权限变更，复制账号不会自动跟着变；二是如果长期靠复制来“攒权限”，很容易出现一个用户带着一堆历史角色的问题，权限最小化原则基本会被破坏。所以复制账号适合临时开通，不适合作为长期的权限管理手段。批量场景交给 SU10，比如批量解锁、批量锁定离职人员、批量改密码，它的本质是把 SU01 的单用户操作变成多用户的一次性处理，处理前务必先下载或核对用户清单，避免误锁。
PFCG 是角色管理的核心。角色不是直接挂在用户上的“权限包”，而是通过角色生成授权参数文件（authorization profile），再通过 SU01 分配给用户。PFCG 里可以创建、修改、显示角色，角色分为单个角色和复合角色，复合角色只是多个单个角色的集合，本身不包含权限数据。这里最容易忽略的一步是：修改角色权限后，必须回到角色维护界面点“比较/生成”或“生成参数文件”，让权限变更写入参数文件并激活，否则用户端看到的权限还是旧的。权限变更通常要等用户重新登录才生效，如果出现“角色改了但用户还是没权限”的反馈，九成是忘了生成，或者用户没重新登。
SU53 是权限检查的排障利器。用户在执行某个事务时报“没有权限”，让用户在该事务的菜单里运行“权限检查”（或直接执行 SU53），系统会显示最后一次权限检查失败的对象、字段和值。运维拿到这个结果，就能定位是缺对象还是缺字段值，再去 PFCG 里补。这套流程是权限运维的基本动作，很多新顾问上来就翻角色，反而绕了远路。
2.2 权限对象三件套：SU21、SU20、SU22
SU21、SU20、SU22 这一组是权限底层配置。SU21 维护授权对象（如 S_TCODE、S_PROGRAM 这类对象），SU20 维护授权字段（如 ACTVT 活动类型、BUKRS 公司代码），SU22 维护事务代码与授权对象之间的对应关系。
它们的使用场景不像 SU01/PFCG 那么高频，但很关键：当一个自定义事务或新上线的事务需要做权限控制时，你得先确认这个事务对应哪些授权对象，这就要看 SU22。SU22 里可以看到某个事务代码在执行时需要检查哪些授权对象，以及哪些对象是默认勾选的。如果权限设计阶段发现“用户有角色但还是进不了某个事务”，也可以从 SU22 入手检查该事务是否引入了新的授权对象检查，角色里没有维护这个对象就会报错。
梳理下来会发现，这组事务码的逻辑是“对象—字段—事务”三层结构：SU21 定义对象和对象里的字段，SU20 定义字段的取值，SU22 把事务挂到对象上，最终角色引用这些对象。理解这个层次，比死记事务码更有用。面试里常问的“权限检查链路”指的就是从用户到角色、从角色到参数文件、从参数文件到授权对象、从对象到字段值这条链路。
2.3 集团生命周期：SCC4、SCCL、SCC1、SCC5、SCC3
集团（Client）管理是 SAP 区别于普通数据库应用的一个关键概念。集团是系统里业务数据和组织结构上的逻辑隔离单元，BASIS 负责集团的创建、拷贝、删除和日志分析，对应事务码是 SCC4、SCCL、SCC1、SCC5、SCC3。
SCC4 负责创建、修改、显示集团。创建集团时最需要注意的是集团属性设置，比如集团的角色（生产、测试、定制）、跨集团定制是否允许、更改与传输的权限级别。这些属性一旦设错，会影响后续能否在集团里做定制，也会影响传输策略。SCCL 是拷贝集团，把源集团的数据和定制拷贝到目标集团。拷贝集团是个重操作，数据量大时必须提前规划后台运行，并且要注意目标集团不能有冲突数据。
SCC1 看起来是“系统内传输单个请求”，本质上也是拷贝，只不过按传输请求粒度拷贝——它把某个传输请求里包含的对象从一个集团复制到另一个集团。这和 STMS 的跨系统传输不是一回事，SCC1 只做系统内、按请求粒度的复制，适合小范围修复，不需要走完整传输链。SCC5 是删除集团，删除前必须确认没有用户在线、没有重要数据留存，最好先做一次数据确认或备份。SCC3 查看集团操作日志，包括拷贝和传输的日志，拷贝失败或者传输中断时，要在 SCC3 里看是哪一步断的。
这五个事务码连起来就是一条集团管理链路：创建集团（SCC4）→ 拷贝集团（SCCL）→ 单请求修复（SCC1）→ 删除集团（SCC5）→ 查日志（SCC3）。日常运维中，最容易混淆的是 SCC1 和 STMS 的分工：SCC1 是系统内的“后悔药”，只影响当前系统；STMS 才是跨系统传输。如果连这个都分不清，传输出了问题就会满世界找原因，结果只是把一个请求拷错了地方。
3. 数据库与后台作业：DB13 备份日历与 SM37 批处理盯盘
数据库是 SAP 系统的黑匣子，日常运维看到的用户报错、作业取消、系统变慢，有一半的根因最后都落在数据库上。BASIS 不需要像专业 DBA 那样天天写 SQL，但必须看懂备份是否成功、表空间是否够用、后台作业有没有按时跑完。
3.1 DB13 维护日历：备份、检查与优化统计
DB13 是数据库日常维护的日历，也是 BASIS 运维在数据库侧的主入口。它负责调度三类常规维护任务：数据库备份、数据库检查（CHECK DATABASE）、优化器统计更新（OPTIMIZER STATISTICS UPDATE）。这三类任务在数据库侧往往对应一组底层命令（如备份对应 BRBACKUP，检查对应 BRCONNECT 相关校验），但 DB13 把它们做成了可以被调度和跟踪的日历项。
使用 DB13 时的要点有两个。第一，备份策略要以恢复为目标：不是“今天备份成功了”就完事，而是要想“如果现在要恢复，我能恢复到哪个时间点”。所以每天晚上要确认的是：备份作业是否成功、是否有完整的日志记录、备份文件是否写入了预期的目录。第二，优化器统计更新是不能省的一步，统计分析过旧会让 SQL 的执行计划走偏，表现就是“数据库没坏但系统莫名变慢”。检查统计更新作业的日志，看它是否真的执行成功，而不是只看到调度记录。
DB13 的操作日志要在 DB13 里的作业日志或后台作业日志中查看。如果备份作业失败，当天就要分析原因，常见原因有磁盘空间不足、归档日志目录满、备份文件被占用。注意，备份失败的当天如果没有补救，意味着恢复点出现空洞，越拖越危险。
3.2 DB02 与 DB12：扩长监控和备份日志
DB02 是数据库表和索引的监控入口。它能看到表空间的增长、表和索引的扩展情况，以及碎片状况。运维盯 DB02 的重点不是“今天有没有告警”，而是“增长趋势是否异常”。比如一张日志表每周增长 10%，但业务量没变，那就可能有程序写了多余数据，或者是清理作业没跑。DB02 里如果看到表和索引的碎片越来越多，通常要考虑重建索引或调整数据库的存储参数，前提是先确认是不是有异常增长。
DB12 是数据备份日志查看器，它和 DB13 的分工在于：DB13 管调度和作业日历，DB12 管结果验证。每天早上看 DB12，确认夜间备份是否成功，同时检查日志目录的剩余空间。这两个检查绑定在一起是有原因的：备份日志会持续写入日志目录，日志目录空间不足会导致备份作业失败，甚至影响数据库的正常写入。所以 DB12 里“日志目录剩余空间”这个指标比想象中更重要。
在这个环节，运维最容易翻车的是把“备份成功”等同于“可以恢复”。备份成功只是写入了备份文件，恢复是否可行还要看备份文件完整性、日志链是否连续。所以更稳的习惯是：定期做恢复演练，哪怕只是恢复到一台测试机，也能验证备份确实可用。否则到了真正要恢复的时候才发现备份文件有问题，那是整个运维工作里最被动的时刻。
3.3 SM36/SM37：后台作业的定义与异常复盘
后台作业是 SAP 系统运行的重要支柱，财务月结、数据抽取、报表生成、接口轮询，全都以后台作业的形式存在。SM36 负责定义后台作业，SM37 负责监控后台作业。
SM36 里定义后台作业需要关注几个要素：作业名、要执行的程序或外部命令、作业步骤、开始条件（立即、日期/时间、周期性）、以及输出 Spool 列表。其中开始条件里的周期设置最容易出错，例如“每天”到底是按工作日还是自然日、节假日要不要排除，如果一开始没想清楚，作业就会在节假日空跑或者在月末漏跑。还有一个容易忽略的点：作业步骤里的用户和打印机设置，会影响 Spool 输出和作业的运行权限。
SM37 是每天必看的监控画面。管理员应该检查所有被取消的作业，而不只是看“有没有红色”。被取消的作业里，有一部分是程序自身报错，有一部分是后台作业进程不足，还有一部分是前面的作业没跑完导致后续作业冲突。每一条被取消的作业，都应该点开日志分析，找到原因后把问题和解决方案记录下来，形成一份后台作业异常台账。这个台账的价值会在月结、年结时成倍放大，因为很多作业失败是周期性重复的，上一次怎么解决、在哪个节点解决，直接照着处理能省大量时间。
另外，SM37 里除了作业日志，输出列表（Spool 列表）也要检查。有些作业其实执行成功了，逻辑也在，但输出列表里能看到程序打印的警告信息，这些警告往往预示着数据边界问题或配置即将失效。作业执行成功不代表输出内容是合理的，这一点很多运维会漏掉。
3.4 数据库日志与 BRTOOLS 兜底
数据库日志的查看路径是排错的关键线索，建议直接记成固定路径：
# 启动日志：<SID> 替换为系统实例标识 su - <sid>adm tail -n 200 /home/<sid>adm/.saplog ls -lt /home/<sid>adm/ # 进程日志：实例工作目录 ls -lt /usr/sap/<SID>/DVEBMGS00/work/ | head -n 20 tail -n 200 /usr/sap/<SID>/DVEBMGS00/work/dev_* # 传输日志：传输目录下的 log 文件 ls -lt /usr/sap/trans/log/ | head -n 20 # 数据库日志：数据库跟踪目录（Oracle 背景下常见） ls -lt /oracle/<SID>/saptrace/background | head -n 20以上命令的含义：第一段是切到系统管理员用户后查看 SAP 的启动日志，系统起不来时先看这里；第二段是查看实例工作目录下的进程日志文件，dev_*是各工作进程的跟踪文件，按文件名能区分是哪个进程；第三段是传输日志目录，传输请求失败时的详细错误在这里；第四段是数据库层的跟踪日志，数据库备份、连接、恢复相关的问题最终要到这里找根因。注意，这些路径里的<SID>、<sid>必须替换成实际系统标识，大小写也有讲究。
BRTOOLS 是操作系统层面的数据库管理工具，它不属于 SAP GUI 里的事务码，而是直接跑在操作系统上的一组命令和工具集。BRTOOLS 的真正价值在于备份与恢复的兜底：当 DB13 里看不到足够细节、或者数据库层面出现严重故障时，BRTOOLS 提供的备份、恢复、一致性检查命令是最后的操作手段。学习建议是：不用把 BRTOOLS 所有参数背下来，但要知道备份命令和恢复命令的入口在哪、日志怎么读，至少在危机时刻能照着文档走完整个流程。
4. 系统监控矩阵：ST06、ST03、SM50、ST22 的联动排查
系统监控是 BASIS 运维每天见得最多的部分。这一块事务码特别多，但不要一个个孤立去记，而是按“用户看得到什么、系统发生了什么、底层资源怎么样”三层来组织。日常巡检和性能问题排查，本质上是在这三层之间定位。
4.1 用户与服务器：SM04、AL08、SM51、SM66
SM04 和 AL08 都用来查看当前在线用户，区别在于 SM04 是服务器相关的视图，只显示当前登录的 SAP 应用服务器上的用户；AL08 是服务器无关的全局视图，显示整个系统架构里所有在线用户。运维要关注的不只是“有多少人在线”，而是“有没有不该在线的用户”“有没有用户正在用不该用的事务码”。比如财务月结期间，某测试账号出现在生产系统里，就应该警惕。
SM51 显示 R/3 服务器概览，可以列出系统中的所有应用服务器实例。它的用途是看不同服务器之间的工作进程分布：当某台服务器负载很高而另一台很闲时，就要考虑登录负载分配的问题。SM51 里双击某个服务器名称，可以看到该服务器的工作进程状态，这和 SM50 是配合使用的。
SM66 是更全局的进程查看器，它能看到整个 SAP 系统范围内所有服务器上的进程，而不是单台服务器。当用户报告“系统卡死”而你手上有多台应用服务器时，SM66 能帮你快速定位是哪台服务器的哪个进程在消耗资源，而不是一台台登进去查。
4.2 性能基线：ST06 与 ST03
ST06 是操作系统性能监控，看的是 SAP 系统所在操作系统的整体资源状况：CPU 使用率、内存使用率、Page Space（交换空间）使用率，以及磁盘 I/O。每天打开 ST06 扫一眼的目的，不是等亮了红灯再去处理，而是建立“正常长什么样”的印象。CPU 长时间跑满、Page Space 使用率台阶式上升、磁盘 I/O 持续偏高，这些都是性能事故的前兆。
ST03 是 R/3 工作负载分析，比 ST06 更贴近用户感知。它展示的是系统在工作负载层面的数据，比如响应时间、数据库调用次数、CPU 时间等。ST03 的价值在原文里有一句很到位的话：没有经验的替代品。管理员应该保留尽可能多的工作量分析数据，尤其是系统没有性能问题时的数据。这其实就是给系统建立性能基线。
有了基线，再遇到“系统变慢了”的投诉，就能做对比：是数据库时间变长了，还是应用服务器 CPU 变高了，还是网络往返时间增加了。ST03 里按事务码看负载，可以定位是某个特定事务拖慢了整体性能，还是全系统性的资源不足。注意，ST03 的历史数据如果定期清理或没人保存，基线就会断掉，等出了问题就来不及补了，这是运维里最容易忽略的“平时功夫”。
4.3 异常信号：SM50、SM21、SM12、SM13、ST22
SM50 用于查看单台 R/3 服务器上的进程概览，能看到每个工作进程的运行状态、正在执行的程序、用户和执行时间。管理员需要全天候留意那些长时间运行的进程：一个后台作业跑了几小时没结束、一个有缺陷的报表程序把数据库 CPU 吃满，都会在 SM50 里暴露出来。但要强调一点——杀掉这些进程前，需要与最终用户协商。因为有时候进程看起来卡住，其实是在等用户确认或者执行长事务，直接杀掉会造成数据不一致。
SM21 是系统日志，记录系统事件和问题。所有警告和错误信息都应被分析和解决，这不仅是排查需要，也是合规要求。运维建议每天定时看 SM21，把警告按来源分类，形成日报；重点不是只盯红色错误，而是持续跟踪那些反复出现的黄色警告，它们往往是隐患的前兆。
SM12 是锁管理。当用户断线、程序出错，系统里的锁可能不会被正常释放，残留的锁会阻塞其他用户对同一对象的操作。用户报“某个表被锁住了”“某个事务进不去”，九成要到 SM12 里查锁。查到的老锁对象要分析是谁、什么时间锁的、是否还有效，确认无用的锁可以从 SM12 里删除。注意删除锁是强操作，删错会导致数据不一致，所以要先联系锁的持有者确认。
SM13 是更新记录。它显示失败的更新动作——生产系统中的失败更新是决不允许发生的。更新失败意味着数据库写操作没有完整执行，会造成数据不一致，一旦发现，开发人员应马上修改。运维的角色是第一时间发现并通知，同时保存失败上下文，配合开发定位。
ST22 是 ABAP 短转储分析。当报表或事务因为严重错误停止工作时，ABAP 开发工作台会发出一个 short dump，系统在系统日志中记录错误信息，并在表 SNAP 中记录程序终止时的信息。ST22 能按错误类型分组显示这些 dump，运维每天要检查是否有新 dump，如果出现，要分析并试图解决问题，至少要把 dump 发送给开发团队。很多系统宕机风险就是从零星 dump 积累起来的，不要因为业务还能跑就忽略 ST22 里的新增条目。
整套监控的联动排查其实是一个固定套路：用户在群里喊系统慢，先看 ST06 是不是 OS 资源爆了；再看 ST03 确认是哪个环节耗时；接着 SM50 看是哪个进程在跑；最后 ST22 有没有 dump 伴随出现。按这个顺序走，基本能把“系统慢”从感性的抱怨变成可定位的技术问题。
5. 易漏点清单：打印、传输、参数与日志里的高频翻车
把前面的事务码都过了一遍之后，真正在运维现场反复翻车的往往是零散的小点。这些点有一个共性：它们不在“标准巡检清单”的第一屏，出了问题时又特别难排查。整理成五条易漏点，帮你在复习和实战时少踩几次坑。
5.1 打印任务已“完成”≠真正打印成功
易漏点：SP01 输出控制器里显示“已完成”的打印任务，实际上可能根本没出纸。很多人看到状态是绿色就认为打印成功，最后用户跑来说没收到打印件，才发现问题。
为什么漏：SAP 系统只跟踪打印任务到目标队列为止，也就是假脱机请求交给操作系统打印服务就算“完成”。后续的物理打印是否成功，SAP 不负责。常见失败原因是用户端的 SAPLPD 程序被关闭，或者打印机本地驱动异常，这些都在 SAP 系统的视野之外。
怎么补：确认重要和大量打印任务时，不要只看输出控制器，要去打印机现场确认纸质输出；从 TemSe 中删除打印任务前，必须先确认任务已经真正完成。SP01 里可以重新启动失败的打印任务，删掉卡住的假脱机请求，但前提是判断清楚失败在系统侧还是用户侧。用户侧问题（SAPLPD 被关）再怎么重启动 Spool 也没用，先解决客户端程序才行。
5.2 杀进程前不看在线用户与后台作业
易漏点：SM50 看到某个进程长时间运行，第一反应是把它 kill 掉。没确认进程的业务属性就动手，结果把用户正在跑的月结或报表杀了，造成数据不一致或业务中断。
为什么漏：SM50 里显示的进程没有直接标明“这到底能不能杀”。进程卡住有两种截然不同的情况：一种是死循环、有缺陷的报表，确实该杀；另一种是长事务在正常执行，比如大数据量汇总、接口批量处理，看起来“没动”其实在跑。后台作业也一样，从 SM37 取消一个作业比从 SM50 杀进程温和，但同样要确认该作业是否已经处理完一部分数据。
怎么补：养成一个习惯——动手前先看 SM04/AL08 确认这个进程对应的用户是否在线，在线就去和用户沟通；后台作业先在 SM37 里看其运行历史和当前步骤；真要杀，优先通过 SM37 取消作业而不是 SM50 杀进程；杀完后记录原因，避免下次重复踩坑。
5.3 传输请求的释放与 STMS 队列
易漏点：开发在 SE09 里释放了传输请求，以为传输就完成了。实际请求只是进入了传输系统，真正的跨系统传输还要看 STMS 的传输队列是否被处理。
为什么漏：SE09 管的是请求的创建、更改、释放，它只负责“把请求交给传输系统”；STMS 才管传输策略、传输队列、跨系统传输。很多人把 SE09 的释放当成终点，结果开发系统里改了东西、测试系统没更新，还找不到原因。
怎么补：确认传输是否落地的正确顺序是：SE09 看请求状态→STMS 看传输队列→传输日志确认成功。STMS 里有传输队列 Display 功能，可以看到请求是否已发送、是否报错；传输失败时去/usr/sap/trans/log/下看传输日志里的具体错误。顺便记住 STMS 还承担集团策略设置，这与 SCC1 的系统内拷贝要区分开——SCC1 是系统内单请求复制，STMS 是跨系统的正式传输，两者用途和配置完全不同。
5.4 RZ10 改完参数不做内外层验证
易漏点：用 RZ10 修改系统参数后直接保存退出，没做验证就等着重启，等到实例起不来才慌了。或者把 RZ10 和 RZ11 搞混，在 RZ11 里以为能修改参数，实际它只能查询。
为什么漏：RZ10 是参数修改的入口，RZ11 是参数查询和说明，但很多人记反了。更隐蔽的一点是：改参数这件事本身有风险，改完参数不一定立即生效，需要重启实例；重启后系统起不来，又缺乏回退手段，等于把自己放进没有后悔药的局面。
怎么补：把参数维护当成一次小变更来管理。改之前在 RZ10 里导出当前参数文件备份；改后在 RZ11 里核对参数的定义、生效方式和取值范围；需要重启才生效的参数，要安排在业务空窗期，并准备好回滚步骤；重启后第一时间看启动日志确认实例正常。凡是“改完参数系统起不来”的案例，基本都缺了备份和验证这两步。
5.5 日志只看错误，不看警告与趋势
易漏点：SM21、ST22、DB12 里只看有没有红色报错，只要没有 error 就关掉界面；对反复出现的警告、short dump 的频次变化、备份日志的增长趋势完全无感。
为什么漏：SAP 系统的日志是“报错导向”的，界面会把 error 标红，但很多问题在变成 error 之前会先以 warning 的形式存在很久。比如某张表空间使用率到了 85%，数据库日志里会先出 warning；某个程序频繁产生 short dump，但还没影响核心业务，就会一直被忽略。
怎么补：把日志检查从“看错误”升级为“看趋势”。SM21 每天记录警告的类型和数量，如果某个警告连续三天出现，就要查原因；ST22 每周统计新增 dump 和失败次数，持续上升就安排开发介入；DB12 不只确认备份成功，也观察日志目录剩余空间的变化曲线。问题和解决方案记录在案——这一步看起来啰嗦，但它是上述所有日志分析能产生长期价值的根基。
6. 复习自查：一张速查表、三条排查线与四个习惯
这份笔记读到这，脑子里已经有了事务码地图、模块要点和易漏点，最后把它压缩成可自查的复习包。复习不是为了重看一遍，而是为了在海量事务码里快速确认“我到底掌握了什么、哪里还虚”。
6.1 按模块归档事务码
把事务码按模块归档，比按字母顺序记忆高效得多。日常运维高频使用的可以压缩成下面这张速查表，每天巡检时对着过一遍：
| 模块 | 核心事务码 | 复习要点 |
|---|---|---|
| 用户权限 | SU01 / SU10 / PFCG / SU53 | 解锁改密、批量处理、角色生成、权限检查 |
| 权限底层 | SU21 / SU20 / SU22 | 对象、字段、事务对应关系 |
| 集团管理 | SCC4 / SCCL / SCC1 / SCC5 / SCC3 | 创建、拷贝、单请求复制、删除、日志 |
| 数据库 | DB13 / DB02 / DB12 / BRTOOLS | 备份日历、扩长监控、备份日志、OS 工具 |
| 后台作业 | SM36 / SM37 | 定义作业、监控作业、分析取消原因 |
| 打印管理 | SPAD / SP01 | 定义设备、假脱机请求管理 |
| 系统监控 | ST06 / ST03 / SM50 / SM51 / SM04 / AL08 / SM21 / SM12 / SM13 / ST22 / SM20 / SM66 | 资源、负载、进程、锁、更新、短转储 |
| 传输管理 | SE09 / STMS | 请求释放、跨系统传输队列 |
| 其他 | SSAA / SM02 / SM59 / RZ10 / RZ11 | 助手、消息、远程连接、参数修改与查询 |
查漏补缺的方法是：看着表格左边的模块，遮住右边，自己说出每个事务码的用途和适用场景；说不出来的，就是需要回看的点。
6.2 三条排查线
复习时把单点知识串成线，才算真正能用。建议记住以下三条排查线，它们覆盖了 BASIS 运维最常被找的三种情况：
- 系统起不来：启动日志
/home/<SID>adm→ 进程日志/usr/sap/<SID>/DVEBMGS00/work→ 数据库日志/oracle/<SID>/saptrace/background，顺序不要乱，启动阶段 SAP 层的问题要先于数据库层排查。 - 系统响应慢：ST06 看资源 → ST03 看负载分解 → SM50 看进程状态 → ST22 看是否有 dump，这条线能区分是资源瓶颈、程序缺陷还是锁等待。
- 数据不保底：DB12 看昨晚备份 → DB13 看备份作业日志 → BRTOOLS 做恢复验证，备份这条线最终要落到“能不能恢复”而不是“有没有备份”。
6.3 四个习惯
最后是学习方法层面的自查。把“如何学好 SAP BASIS”里的经验转化成四个日常习惯：手脑动，看完文档立刻动手验证，把操作过程记录成自己的问题库；广泛学，不把 BASIS 局限在技术层面，了解业务模块如何调用系统、用户实际怎么用功能，才看得懂监控数据的业务含义；自答问，主动解答别人的问题，把答案整理成自己的问题集锦，下次遇到类似就照方抓药；向前看，持续跟进新版本和新产品，补全 OS、数据库、SAP、Web 各层的知识。
我自己有一段时间只看 ST06 和备份日志，觉得系统没报错就万事大吉，直到一个短转储在月结当天爆发才意识到：平时不积累基线、不整理问题台账，出事时只能靠蒙。从那以后，我每天巡检都强制自己走一遍速查表，每处理完一类问题就建一条记录，一段时间之后，那些曾经“云里雾里”的事务码就真的变成了一张地图。希望这份 SAP 日常运维 BASIS 的梳理，也能帮你在复习和实战里更快画出属于自己的那张图。
本文还有配套的精品资源，点击获取
