SAP Basis 运维核心：七类事务与日常监控排查指南

简介：SAP日常运维BASIS方向的内训讲义，面向初入SAP系统管理岗位或从开发、业务模块转向Basis运维的技术人员，用以搭建日常管理事务代码的整体框架。文档按用户权限、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理等模块组织，逐条列出SU01、PFCG、SCCL、DB13、SM36、SPAD、ST03、STMS等常用事务代码及其用途，并补充操作要点，如账号解锁与复制、数据库备份日志检查、假脱机请求处理、系统日志与进程监控的判读思路，以及启动日志、进程日志、传输日志、数据库日志的存放路径。末尾还附有“如何学好SAP BASIS”的经验性说明，区分实施与运维的职责侧重，强调数据安全与备份还原的重要性。整包为1个PDF文件，压缩包约2.02MB，方便按事务代码随查随用，已有962人学习。

1. 一句话说清：SAP Basis 是那套系统的“物业管家”

SAP Basis 是 SAP 系统里的一个角色，管的是这套系统从无到有、从早到晚的运转：规划、安装、配置、监控、维护、调优。这些活按偏重分成两半：偏规划和安装配置的叫实施，偏日常管理、监控和维护的叫运维。刚入门的人容易以为 Basis 就是背一堆事务码，其实事务码只是工具，这套角色真正要保的是“系统今天别出事，出了事能查明白”。

打个比方，一栋写字楼里有装修队、有住户、有物业。装修队决定墙怎么砌、线怎么走；物业管电梯、水电、门禁、保洁和消防。住进去之后墙歪不歪，住户往往第一个发现，但能不能当天修好，看的是物业手里那套巡检表和值班日志。SAP Basis 的运维就是后面这个角色：业务顾问和用户在楼里办公，Basis 在楼下盯着配电箱，看负荷、看告警、看谁拿了不该拿的钥匙。

2. 为什么需要专人“看着”：系统上线之后才是真正的开始

一套 SAP 系统交付给业务部门使用的那天，业务顾问的工作告一段落，Basis 的工作才进入长跑阶段。业务顾问交付的是流程怎么走，Basis 交付的是这套流程能跑起来的空气和水：服务器有算力、数据库有空间、用户有权限、打印机能出纸、补丁和变更能按顺序从开发环境走到生产环境。这些事平时做得对，没人会注意到；做得不对，全公司都会注意到。

这也是为什么运维岗看起来“日常”，实际却最考验判断力。系统跑得顺的时候，所有日志都是绿的，人容易松劲；而真正出问题的时刻，往往是你手里没有基线数据、没有历史记录、也没有确认过还原路径的时候。世上没有经验的替代品，这句话放在这个岗位上格外贴切。

2.1 实施和运维：同一个角色的两段接力，不是两种水平

很多人把实施和运维看成两个等级：实施高级，运维基础。这个看法只对了一半。从要求上说，实施确实要规划系统架构、装系统、配参数，交付时还得留下大量文档，等于把“大局”定了；运维是在这个大局已定的前提下做日常，有点像萧规曹随，按既定规矩把手上的事做扎实。

但“要求更高”不等于“所有方向都更专业”。实施的强项在设计、在一次性把事情做对；运维的强项在时间维度上的观察，比如某个表空间三个月涨了多少、某个后台作业以前跑二十分钟现在跑两个小时、某类短转储每个月出现几次。这些判断靠的是长期的、连续的观察，是实施阶段拿不到的素材。反过来说，实施如果把系统装歪了，运维每天补窟窿也补不出一个好系统。

所以更准确的说法是接力：实施把系统交到运维手里的时候，交接清单上写了什么，决定了运维接下来几年过得舒不舒服。清单里少了备份策略、少了参数变更记录、少了传输路径说明，运维就得靠踩坑一条条补回来，这个过程里有太多血泪经验是没法写进交付文档的。

2.2 七类日常事务：运维每天在防的是七种事故

日常运维的工作面看起来杂，其实可以归到七摊事上，每一摊背后都对应一类具体事故。

用户权限管理对应的是“钥匙发错人”。账号该锁没锁、离职人员权限还挂着、某个角色给了超出岗位需要的授权对象，平时看不出来，一审计就是一堆问题。

集团管理对应的是“数据被覆盖”。集团拷贝方向搞反、拷贝时选错了配置文件、拷贝完没核对数据量，都是能把测试数据盖到生产上的操作。

数据库管理对应的是“空间满了全线停摆”。表空间增长、索引碎片、备份是否成功、统计信息是否更新，这些指标平时缓慢变化，一旦越线就是全局性的。

后台作业对应的是“月结做不完”。作业定义好了没释放、释放了没启动、启动了被取消、取消了没人看输出列表，链条上任何一环断了，业务侧的账就结不上。

打印管理对应的是“发票和单据出不来”。假脱机请求堆在队列里，用户在那边催，这边一看是终端上的输出程序没启动。

系统监控对应的是“小毛病拖成大故障”。CPU、内存、页交换、进程、锁、更新失败、短转储，这些信号从来不缺，缺的是有人每天固定看一遍。

传输管理对应的是“版本错乱”。请求释放顺序不对、该走的系统没走、生产上少了某个对象，最后表现为“测试环境明明是好的”。

七摊事不需要每天全做一遍深度检查，但需要每天都有人扫一眼。运维的价值不在于解决多大的难题，而在于让这七类事故在变成事故之前被看见。

2.3 备份的意义在还原，不在“备份成功”

这一条值得单独拎出来说。日常检查里最容易走过场的一项，就是看备份。打开备份日志，昨天的作业状态是绿色，勾掉，完事。可备份这件事的唯一意义是“需要的时候能还原回来”，而“备份作业成功”和“能还原”之间隔着好几步：备份文件在不在、介质可不可读、还原流程有没有人真跑过、恢复出来要多久、业务能容忍停多久。

很多团队第一次真正验证这件事，是在真出事的那天。那天才发现备份策略是别人定的、还原步骤没人写过、数据库工具的命令行参数得现查。这种时候没有后悔药可吃。所以负责任的运维会把还原演练排进计划，把它当成一项和备份同等重要的日常任务，而不是等审计来问才想起来。

3. 一天的工作长什么样：七类事务代码背后的七件事

SAP 的事务码有几千个，Basis 日常用的那一小撮，本质上是七个抽屉的把手。记字母不如记抽屉：这个码打开的是“人”的问题，那个码打开的是“空间”的问题，第三个打开的是“时间”的问题。下面按抽屉说，每个抽屉里挑几个最常用的，讲清它在防什么。

3.1 用户与权限：SU01 只是入口，PFCG 才是主体

SU01 是用户维护，创建、修改、显示、锁定、解锁、改密码、复制账号都在这里。新人最先学会的往往是“帮人解锁”和“帮人改密码”，因为这两件事来得最频繁。复制账号也是它的常用功能：拿一个已经配好权限的老账号当模板，复制出一个新账号，把权限带过去，省得从头配。

真正的权限体系主体在 PFCG：角色里挂菜单、挂授权对象、生成授权参数文件，再把角色分配给用户。SU01 只是把人和角色连起来的那一步。SU53 则是排查入口：用户在某个事务里被拒绝，让他当场执行 SU53，屏幕上会显示缺的是哪个权限对象、哪个字段值，管理员拿着这个结果回 PFCG 补，比凭感觉猜快得多。

SU22 常被忽略，但它解决的是“这个事务码到底要什么权限”的问题。有些报错看着莫名其妙，查一遍 SU22 就明白，是某个后台校验要求了一个谁都没注意的授权对象。

3.2 集团管理：SCC4 定规则，SCCL 搬数据，SCC3 留证据

集团在 SAP 里是一个独立的业务单元，同一套系统里可以并存多个集团，分别承担开发、测试、生产等职责。SCC4 管的是集团的“户口本”：类型是生产、测试还是定制，货币、日历、变更记录的开关都在这里。这个码平时动得少，但它决定了这个集团允许做什么、不允许做什么，设置错了后面处处掣肘。

SCCL 是集团拷贝，用来把一个集团的数据搬到另一个集团。它要选源、选目标、选配置文件，还要决定带不带用户、带不带表数据。这个操作的危险性在于方向：源和目标填反了，就是把测试数据盖到生产上。所以规范的做法是拷贝前把源、目标写在纸上核对一遍，拷贝后看 SCC3 的日志确认结果。

SCC1 解决的是另一个场景：手里有一个传输请求，想在本集团里再执行一遍请求里的内容。它不跨系统，只在当前集团内生效，常用于把某个变更在本地重放。SCC5 是删除集团，属于“按下去之前手会抖”的那类操作。SCC3 则是所有集团操作的流水账，拷贝和传输的记录都在里面，出问题第一个翻它。

3.3 数据库与后台作业：DB13 定计划，SM37 收结果

数据库这一摊的核心问题是空间和时间：空间够不够，备份来不来得及。DB13 是数据库日常维护日历，备份、数据库检查、优化统计更新这些周期性动作都在这里排，排完之后它本身也能看到相关后台作业的日志。DB02 看的是表和索引的增长与碎片情况，是判断“还能撑多久”的主要依据。DB12 是备份日志，用来确认夜间备份到底成没成。BRTOOLS 则是操作系统层的数据库管理工具，有些操作在 SAP 界面里做不了，得下到这一层。

后台作业是让这些周期性动作真正跑起来的机制。SM36 定义作业：作业名、步骤、开始条件、优先级、跑在哪台服务器上。SM37 是监控台，能看到作业处于已排程、已释放、就绪、运行中、已完成还是已取消。

# 数据库与后台作业的日常检查顺序（示意，不是可直接执行的脚本） # 1. 先看昨夜备份是否成功：DB12 # 2. 再看数据库维护日历里的任务有没有跑：DB13 # 3. 然后看作业层的结果：SM37 过滤“已取消”和“运行中超过预期时长” # 4. 最后核对表空间增长趋势：DB02

这段顺序的意思是先看结果、再看计划、最后看趋势。很多新手一上来就扎进 SM37 翻几百条作业，翻到眼花也看不出问题。正确的做法是先按状态过滤，把所有“已取消”的挑出来，再对照那些运行时长明显超过历史均值的作业。作业被取消不可怕，可怕的是取消了没人管——所有被取消的作业都应该被分析，原因和处置方式记进文档。

3.4 系统监控：从 ST06 到 ST22 的一条纵线

监控这条线是从下往上的。ST06 看操作系统层：CPU 使用率、内存、页交换空间、磁盘。这一层是地基，地基出问题，上面所有表现都是症状。ST03 看工作负载：响应时间、数据库时间、CPU 时间、用户和事务的分布，它的价值在于对比——系统正常时的画像存下来，出问题时才有参照物。

再往上是实例和进程。SM51 列出所有应用服务器，SM50 看当前实例的进程概览，能看见进程类型、状态、正在跑什么，紧急情况下可以在这里处理卡死的进程。SM66 提供的是全局视角，跨实例看所有进程。SM04 看当前登录用户，AL08 看的是不分服务器的全局在线用户。SM12 管锁，用户断线或程序出错会留下老锁，得定期清理。SM13 看更新记录，失败的更新在生产系统里是必须马上处理的。

最上面一层是日志和转储。SM21 是系统日志，记录系统级的事件和问题；ST22 是 ABAP 短转储，程序因为严重错误停下来的时候，这里会留下程序名、行号和调用栈。SM20 是安全审计，SSAA 是系统管理助手，把常用的监控入口汇总在一起；SM02 则是给在线用户发系统消息的地方，比如“今晚十点系统维护”。

这些码串起来是一条纵线：操作系统 → 工作负载 → 实例与进程 → 用户与锁 → 日志与转储。排查的时候顺着线走，比乱点效率高得多。

3.5 打印与传输：SP01 看队列，STMS 看方向

打印这一摊，SPAD 定义输出设备：设备类型、主机、访问方式。设备定义错了，前端怎么弄都出不来纸。SP01 是假脱机请求和输出请求的管理台，失败的打印任务可以在这里重启，堆着的请求可以在这里删。

这里有个容易被忽视的细节：SAP 只跟踪到目标队列，输出控制器里显示“已完成”，并不代表纸真的打出来了。中间还隔着终端上的输出程序。所以重要和量大的打印任务，在从临时存储里删掉之前必须先确认确实打完了，否则重打一遍的成本得自己承担。

传输这一摊是两个码的分工。SE09 管请求本身：修改请求、修改任务、释放。释放之后请求才成为可以导入的文件。STMS 管的是传输的路线和队列：传输路径怎么配、集团策略是什么、系统内传输和跨系统传输怎么走、队列里排了哪些请求。

传输的方向性比速度重要得多。开发到测试再到生产，这条链是单向的，反着走就是给自己埋雷。日常检查里应该固定看队列有没有积压、生产导入有没有失败、有没有人绕过流程直接在目标系统改东西。

4. 常见误区：五组最容易搞混的事务码

事务码长得很像，名字也很像，混起来用不会立刻报错，但会得出错误结论。下面五组是初学者最容易糊在一起的。

4.1 SM04 和 AL08：都叫“当前用户”，一个看一间屋，一个看整栋楼

易混点：两个码都能看到在线用户列表，界面还都挺像。

为什么混：名字里的差别只有一行说明，一个是“服务器相关”，一个是“服务器无关”，不留意就滑过去了。

怎么区分：记住范围。SM04 看的是你当前登上的这台应用服务器实例上的用户，换一台服务器看，名单就不一样。AL08 看的是整个系统里所有实例的在线用户，不管人连在哪台机器上。要判断“某个人现在是不是还挂着”，用 AL08；要判断“这台机器是不是被人连满了”，用 SM04。查一个具体用户在哪台实例上，也是先在 AL08 里定位，再回对应实例用 SM04 看细节。

4.2 SM50 和 SM66：进程看得见，不等于看得全

易混点：两个都是进程概览，都能看到正在跑的东西，紧急时都能处理。

为什么混：功能确实重叠，差别藏在“本实例”和“全局”这两个词里。

怎么区分：SM50 是当前实例的进程，SM66 是跨所有实例的全局进程视图。系统只有一台应用服务器时，两者看起来几乎一样，所以很多人在单机环境里学，到了多实例环境就糊涂。真正的用法是：日常巡检用 SM66 扫全局，发现某类进程异常堆积再进 SM50 看具体实例的细节。另外，处理进程之前必须与最终用户协商，长时间运行的后台作业和有缺陷的报表程序都会吃掉大量资源，但直接处理掉可能让某个正在跑月结的同事前功尽弃。

4.3 RZ10 和 RZ11：一个改，一个看

易混点：两个码的界面高度相似，都是参数列表。

为什么混：RZ11 也能看到参数值，看起来像“参数管理”，实际上它只能查和临时改当前值，不能持久化。

怎么区分：RZ10 是参数修改，改的是配置文件，改完通常需要重启实例才生效；RZ11 是参数查询，用于确认某个参数当前的实际取值和它来自哪个配置文件。RZ11 里确实可以做临时修改，但那只在本次运行期内有效，重启就回到配置文件的值，用它来“修好”一个参数是会翻车的。正确的顺序是先用 RZ11 查清楚当前值和来源，再用 RZ10 改配置文件，改完确认依赖关系，最后安排重启窗口。

4.4 DB12 和 DB13：备份日志不等于备份计划

易混点：两个码都跟数据库维护有关，都带“DB”前缀。

为什么混：名字太像，而且都跟备份沾边。

怎么区分：DB13 是“计划表”，你在这里排备份、排数据库检查、排统计更新，它回答的是“应该什么时候做什么”。DB12 是“成绩单”，回答的是“昨天排的那次到底成没成”。检查备份的正确姿势是两边对着看：先在 DB13 确认计划还在、没被人误删，再到 DB12 确认执行结果。只看 DB12 会漏掉“计划被删了所以一直没有新日志”这种情况，只看 DB13 则会以为排了就一定跑了。

4.5 SCCL、SCC1 和 STMS：搬数据、放录像、修马路不是一回事

易混点：三个都跟“把东西从一处弄到另一处”有关。

为什么混：都涉及传输这个词，中文语境下更容易混。

怎么区分：SCCL 是集团拷贝，搬的是整个集团的数据，重量级操作，方向错了就是事故。SCC1 是在当前集团内重放一个传输请求的内容，范围小，只在本地生效。STMS 管的是系统之间的传输路线和队列，是“马路”本身。三者层级完全不同：STMS 决定路怎么修，SE09 决定货车什么时候发车，SCC1 是在本地把货再卸一遍，SCCL 则是把整个仓库搬走。搞清楚谁管路线、谁管发车、谁管卸货，这一组就不会再混。

5. 出问题先看哪儿：日志是有固定位置的，别乱翻

系统出问题时，新手最容易做的是在事务码里到处点，指望屏幕上蹦出一句解释。有经验的人第一步是去固定的几个目录看文件。这不是玄学，是设计如此：SAP 把不同层面的信息写在不同地方，知道位置，就等于知道该问谁。

5.1 四类日志文件分别放在哪儿

# 启动日志：实例启动过程中的输出，起不来时第一个看这里 /home/<SID>adm # 进程日志：工作进程的详细输出，某个进程异常时看这里 /usr/sap/<SID>/DVEBMGS00/work # 传输日志：请求导入过程的记录，传输失败时看这里 /usr/sap/trans/log/ # 数据库日志：数据库层的跟踪文件，怀疑数据库问题时看这里 # 以某类数据库为例，具体路径随部署方式不同 /oracle/<SID>/saptrace/background

这四个路径对应的层级是从下往上的：启动日志回答“系统为什么没起来”，进程日志回答“某个进程为什么异常”，传输日志回答“这个请求为什么导不进去”，数据库日志回答“数据库那边报了什么”。参数里的 SID 是系统标识，DVEBMGS00 是实例目录的命名，实际环境里编号会不一样，照现场目录看。

提示：路径记不住没关系，关键是记住“启动、进程、传输、数据库”这四层各自有独立的落盘位置。界面里的日志是汇总视图，文件里的日志才是原始记录。

5.2 排查顺序：先判断现象属于哪一层

一次典型的排查是这样走的：用户报“系统很慢”，先上 ST06 看操作系统层有没有 CPU 打满、内存吃紧、页交换频繁；如果没有，再看 ST03 的响应时间分布，判断慢在应用层还是数据库层；如果怀疑是某个进程卡住，用 SM66 全局扫一遍，再进 SM50 看细节；如果怀疑是锁，看 SM12；如果是程序报错，直接看 ST22 的短转储。整条路径走完，现象基本能定位到某一层。

反过来，如果一上来就翻 SM21 系统日志，会被大量无关条目淹没。SM21 的用法是带着筛选条件看：限定时间窗口、限定用户、限定事务码，把它当成“事后核对”的工具，而不是“第一现场”。

日志的价值还在于对比。系统正常的时候把关键指标抄下来，比如某类后台作业的平均耗时、某个时段的在线用户峰值、表空间的月增长量。有了这条基线，异常才显得出来。没有基线，所有数字看起来都正常。

5.3 把解决方案写下来这件事

运维岗位上真正拉开差距的，不是谁见过的报错多，而是谁的问题记录整理得好。同一个短转储，一年后可能换个程序名再来一次；同一个传输失败，半年后换个同事再踩一遍。每次处理完把“现象、定位过程、根因、处置方式”四段写清楚，攒上一年就是自己的知识库。

这件事没有技术含量，但极少有人坚持。多数人解决问题就关单，下次再遇到时凭模糊记忆重来一遍。文档写下来还有另一个好处：它会逼你把根因说清楚。很多“重启一下就好了”的处置，其实没找到原因，写的时候就会发现这一点。

6. 什么时候用它、什么时候别硬套：一条能落地的判断线

这套事务码清单和日常检查思路，适用的场景其实很明确：你已经接手或即将接手一套正在运行的 SAP 系统，需要每天用固定动作扫一遍关键面；你遇到一个具体报错，需要顺着层级往下定位；你在准备上线前的检查，需要确认权限、作业、备份、传输这几条线都通了。这些场景里，按抽屉分类、按纵线排查，比背命令有效得多。

需要说清楚的“别用”也有几条。系统还没上线、架构还没定，就别急着练运维动作，基础没打好直接跳去学安装和调优，看着快，实际会在某个概念上卡很久。备份没做过还原演练，就别把“昨天备份成功”当成后悔药。生产系统上任何一次 SM50 里的处理、任何一次传输导入、任何一次参数修改，都不该在没有确认影响面和窗口的情况下动手。

我自己的习惯是：任何要碰生产环境的动作，先在测试集团里原样走一遍，把事务码、参数、预期结果写在便签上，走完对一遍再上生产。这个习惯救过我很多次，尤其是在集团拷贝和传输这两件事上——这两件事的共同点是，做错了不会立刻报错，而是安静地把错误数据铺开。从那以后我每次动手前都强制走一遍这个流程。

希望帮到你。

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