简介：这份SAP日常运维BASIS学习资料面向刚接触SAP系统管理或需要梳理日常运维事务的从业者，围绕用户权限、集团管理、数据库维护、后台作业、打印管理、系统监控、传输管理等核心场景，帮助读者建立Basis运维事务代码与工作流程的整体框架。压缩包内共1个PDF文件，约2.02MB，内容以事务代码说明、操作要点和日常检查思路为主，便于按模块查阅和对照实践。已有962人学习，适合用于入门阶段快速熟悉常见运维入口、理解监控与日志查看的重点，也可作为日常工作的备忘清单。读者可从中获得较系统的Basis职责认知、常见问题排查方向以及如何学好SAP BASIS的基础建议，对后续深入权限设计、数据库备份还原和系统性能观察具有参考价值。
1. 运维地图：九个格子与四十个事务码的分层
把 SAP BASIS 的日常摊开，落点只有九个格子：用户权限、集团、数据库、后台作业、打印、系统监控、传输、参数、日志。格子不多，事务码却散着四十多个，逐个背容易出错，按层归位才记得住。这份运维笔记的骨架就是这九块，梳理下来更像一张巡检地图，而不是一份命令清单。
地图上有一条分水岭：实施偏规划、安装、配置，交付的是文档和大局；运维在大局已定的前提下做管理、监控、维护。同一批事务码，实施关心“建成什么样”，运维关心“今天有没有异常”。调优两头都沾，更偏实施，但不绝对。
适合两类人：已经在做日常支持、想把零散命令串成体系的人；准备转岗或面试、需要一次性把基础铺开的人。看完至少知道哪个事务码该在什么时间点打开。
2. 权限链：从 SU01 到 SU22 的四层授权结构
日常工单里，“我没有权限”这四个字能占掉一半。听起来是个小问题，拆开看是四层结构里任意一层断了——从账号本身的有效期，到事务码该查哪个授权对象，任何一环不匹配，用户点进去就是一句“未授权”。把这条链路的顺序记牢，比记住四十个事务码都值。
2.1 四层结构：一次授权检查要经过哪些地方
用户登录后执行一个事务码，系统不是直接查角色，而是先按事务码找到它要检查哪些授权对象，再比对用户通过角色拿到的授权值，不通过就记一条失败。四层各管一段，分工如下。
| 层级 | 承载内容 | 主要事务码 | 变更频率 |
|---|---|---|---|
| 用户主数据 | 账号、有效期、用户组、角色分配、锁定状态 | SU01 / SU10 | 高，每天都有 |
| 角色 | 菜单、授权对象取值、生成的概要文件 | PFCG | 中，按需求走 |
| 权限对象与类 | 授权检查的颗粒度、字段定义 | SU21 / SU20 | 低，设计期才动 |
| 事务码映射 | 某个事务码会触发哪些授权对象检查 | SU22 | 低，排错期才看 |
排错的顺序应该反过来走：先 SU53 看失败的是哪个对象哪个字段，再回 PFCG 看角色里这个字段的取值，最后才怀疑 SU22 的映射配错了。反过来从 SU21 一层层往下查，往往查半天发现只是角色里少勾了一个值。
提示：SU21、SU20、SU22 属于改系统设计的动作，生产环境基本不动。九成工单落在 SU01 和 PFCG 这两层。
2.2 SU01 的三个高频动作：解锁、改密、复制账号
这个事务码是用户维护的总入口，日常真正高频的只有三个动作。
解锁：用户连续输错密码被锁，进去把“锁定/解锁”状态改回来。要注意区分“因密码错误自动锁定”和“管理员手工锁定”，前者解锁就完事，后者得先问清是谁锁的、为什么锁。
改密：直接设定新密码，同时勾上“用户下次登录必须修改”。给外包或临时账号改密时这个勾一定要勾，不然新密码就长期挂在邮件里。
复制账号：以已有账号为模板新建。比如把 ZTEST01 复制成 ZTEST02，复制过来的是角色分配、用户组、登录语言、默认打印设备这些属性，密码需要单独设置。这里有个容易忽略的点：如果源账号的角色是通过岗位或组合角色间接分配的，复制后不一定是完整的一套，复制完要用“显示授权数据”核对一遍，别直接把账号交给用户。
SU10 是批量维护，用于一批用户同时改用户组、锁定状态、密码策略这类属性。它不负责把角色批量加给一批人，那是 PFCG 的用户比较或者 SU01 逐个分配。这条最容易混，界面看起来像“什么都能批量改”，实际上能改的只是用户主数据字段。
2.3 SU53 与 PFCG：排错侧和配置侧的两套动作
SU53 只保存当前会话里最近一次失败的授权检查。用户一句“我点进去报错”，如果你半小时后才连过去，SU53 里很可能已经是另一条记录了，前面那条现场就没了。所以工单模板的第一句应该是：报错时立刻打开 SU53 截图，别等。
PFCG 侧的动作固定三步：菜单页签里加事务码或文件夹；授权页签里点“更改授权数据”，给具体对象的字段填值；最后生成概要文件。第三步不做，前面填的全是草稿，用户重新登录也不会生效。
注意：PFCG 改完要生成概要文件并做用户比较，否则角色里的新值和用户主数据里的旧值对不上，表现就是“明明改了还是没权限”。
2.4 权限设计上的三个取舍
第一，不给大权限。直接甩 SAP_ALL 最省事，但审计过不去，出事时 SM20 里也查不出异常行为，等于把追溯能力一起关掉了。
第二，角色分层。单一角色对应单个事务码，组合角色按岗位拼装。人员调岗时只动组合角色，不用去翻几十个单一角色。
第三，变更走传输。角色在开发机改，通过请求传到测试和生产，别在三套系统里各改一遍。手工在生产的 PFCG 里改角色，下次传输一进来就被覆盖，这种反复出现过的问题排查起来非常耗时间。
3. 变更搬运：SCCL 拷贝、SE09 释放与 STMS 队列
权限管的是“谁能进”，这一层管的是“东西怎么进去”。集团是容器，传输是搬运，后台作业是定时器，三者经常在同一次上线窗口里连着用，顺序错了就得回退重来。
3.1 集团管理的五个事务码与执行顺序
集团相关的操作有明确的先后关系，乱序执行是常见失误。
| 事务码 | 作用 | 典型场景 | 风险 |
|---|---|---|---|
| SCC4 | 集团属性：集团角色、是否允许更改、货币、逻辑系统 | 新建集团后第一件事 | 中 |
| SCCL | 拷贝集团，分本地拷贝与远程拷贝 | 建测试集团、从生产刷数据到测试 | 高 |
| SCC1 | 系统内传输单个请求到指定集团 | 把某个定制单独搬进某集团 | 中 |
| SCC5 | 删除集团 | 清理临时集团 | 极高 |
| SCC3 | 集团操作日志 | 拷贝或传输后验证结果 | 低 |
正常顺序是：SCC4 先定属性，SCCL 做拷贝，SCC3 看日志确认，必要时用 SCC1 补单个请求。SCC4 里那个“不允许更改”的开关很关键，一旦打开，SCC1 往这个集团传东西会被直接拒绝，很多“传输跑完了但没生效”的现场，最后都追到这个开关上。
SCCL 的表分类有三档：不拷贝、仅结构、全部数据。选“全部数据”会把日志表、集群表一起搬过来，拷贝耗时翻好几倍；选“不拷贝”又可能把配置表漏掉。做之前先确认这次拷贝是为了“要数据”还是“要配置”，目的不同，分类策略完全不同。
SCC5 在生产上基本没有恢复手段。删除前先确认集团号、做好数据库备份、确认没人登在这个集团里，三个条件缺一不可。
3.2 请求与任务：SE09 里的父子关系
一个传输请求下面挂若干任务，任务按开发人员分。释放顺序是先释放任务，再释放请求，任务没释放完，请求释放不了。
释放这个动作是不可逆的转折点：对象清单从此固定，再想往里加东西，只能新建一个请求把它带上。所以释放前必须打开对象清单逐条看，重点找标着“本地”的条目——那是在开发机直接改出来、落在 $TMP 里的对象，不进请求，测试环境看着没问题，传到生产一跑就少东西，这种场景在跨系统上线时出现得最多。
对象数量也要对。开发说“我只改了一个程序”，清单里躺着二十个对象，多出来的那些要么是误改，要么是别的需求搭车，无论哪种都得在释放前问清楚。
3.3 STMS：队列、路由与返回码
STMS 里主要看三块：传输概览里的系统与路由、每个系统的导入队列、集团策略。导入队列是串行的，前面一个请求卡住，后面全部排队，所以队列里出现长时间不动的请求，要优先处理它而不是往后加。
返回码是最直接的判断依据：0 表示成功，4 表示有警告，8 表示部分对象未导入，12 表示严重错误。这里有个血泪经验——返回码 0 也不代表所有对象都进去了，日志里可能仍然有被跳过的条目，尤其是跨版本传输时。
提示：每次导入完都点开日志看一遍，别只看返回码。集团策略决定默认导到哪个集团、是否允许覆盖，改策略要走变更评审。
3.4 后台作业：SM36 定义与 SM37 复查
SM36 定义作业，要填四样东西：作业名（按团队规范命名，比如 Z_DAILY_ 开头）、作业类（A 高、B 中、C 低）、开始条件（立即、指定日期时间、事件触发、前一个作业结束后）、步骤（ABAP 程序加变式，或者外部命令）。作业类选错是性能问题的一个隐蔽来源，把大批量报表设成 A 类，它会跟在线对话用户抢工作进程。
SM37 是复查入口，按作业名、用户、状态筛选，重点是“已取消”这一档。管理员每天应该把所有被取消的作业过一遍，分析原因并记录解决方案，否则同一个作业会天天在同一时间点失败，只是没人看。
| 作业状态 | 含义 | 该做什么 |
|---|---|---|
| 已调度 | 时间未到或前置条件未满足 | 确认开始条件是否正确 |
| 已释放 | 已进入调度器等待执行 | 正常，无需干预 |
| 就绪 | 等待空闲工作进程 | 查 SM50 是否有长作业占用 |
| 运行中 | 正在执行 | 看 SM50 对应进程的动作与耗时 |
| 已结束 | 正常完成 | 抽查假脱机输出是否合理 |
| 已取消 | 异常终止 | 看作业日志定位原因 |
4. 观测面：数据库、进程与日志的四条查看路径
前三层是“改”，这一层是“看”。看的能力决定你发现问题的时间差：同样的故障，有人等用户打电话才知道，有人在早上巡检时就已经处理完。观测面按资源、会话、一致性、日志四段分开记，比混在一起背要清晰得多。
4.1 数据库：DB13 日历、DB02 空间、DB12 备份日志
DB13 是数据库维护日历，把备份、CHECK DATABASE、优化统计更新这些周期性动作挂成后台作业，也能在这里查看这些作业的执行日志。它的价值在于“统一入口”，不用去操作系统的计划任务里翻。
DB02 看的是增长：表空间有没有快满、索引是不是膨胀、碎片情况如何。原文里专门提到“监控数据库的扩长”，这件事要提前做，等到表空间满了再扩，系统已经在报错了。
DB12 看夜间备份是否成功，同时要看日志目录的剩余空间。备份失败的原因里，空间不足排第一，其次是归档目录写满。
BRTOOLS 是操作系统侧的数据库管理工具，SAP 层看不到的细节从这里进，通常以数据库用户身份运行。还原演练也在这个层面做。
备份这件事，原文特意点了一句：数据安全靠的是“备份和还原”两件事，不是一件。备份成功只是前半程，还原演练是后半程。没有演练过的备份，只是一个未经验证的假设。
4.2 资源与会话：ST06、ST03、SM04/AL08、SM51/SM50/SM66
这一组动作是每天打开系统后的第一轮工作。
| 事务码 | 看什么 | 服务器相关 | 典型异常 |
|---|---|---|---|
| ST06 | CPU、内存、PAGE SPACE、文件系统 | 本机 | 内存吃满、页交换频繁 |
| ST03 | 对话、后台、更新各类任务的负载与响应时间 | 全局 | 平均响应时间抬升 |
| SM04 | 当前登录用户与会话 | 本机 | 异常账号、越权事务码 |
| AL08 | 全部应用服务器的登录用户 | 全局 | 用户分布严重不均 |
| SM51 | 应用服务器列表 | 全局 | 某台实例失联 |
| SM50 | 本机工作进程（对话、后台、更新、假脱机） | 本机 | 进程长时间 Running |
| SM66 | 全局工作进程 | 全局 | 跨实例定位阻塞点 |
ST03 的重点不在看今天的数字，而在留基线。系统正常时的数据留得越全，出问题时对照越准，能分清是整体抬升还是某个事务码单独拖累。平时不做这件事，第一次打开 ST03 往往就是故障当天，那时候没有参照物，只能凭感觉。
SM50 杀进程要谨慎。先看进程类型、用户、正在操作的表、动作和耗时，判断它卡在哪；再跟用户确认会话是否还要保留；最后才动手。直接终止会让会话中断、未提交的事务回滚，生产上处理不当会引来一串后续工单。
4.3 一致性与错误：SM12、SM13、ST22、SM21、SM20
SM12 是锁管理。用户断线、程序异常退出，锁都可能挂在里面。判断能不能删，看两个条件：锁持有了多久，持锁用户是否还在 SM04 里。两个条件都满足才动手。
SM13 显示失败的更新。生产环境出现失败更新属于必须立即处理的问题，开发要马上介入改代码，运维这边先看更新请求对应的记录和错误文本，把现场留下来。
ST22 是 ABAP 短存储，也就是常说的 dump。每天扫一遍是固定动作，记录落在表 SNAP 里，可以按用户、程序、时间筛选。看三样东西：错误类型（比如数据库访问类错误、类型转换错误）、触发程序、出错的具体位置。
SM21 是系统日志，服务器相关，记录系统事件和问题，所有警告和错误都应该被分析和解决，并且把问题和解决方案做成文档。跨多台应用服务器时，要逐台看。
SM20 是安全审计，登录失败、权限检查失败、关键事务码启动都能查到，按审计要求定期导出。
注意：SM21、ST22、SM13 这三处是排查的原始现场，出问题时先把内容导出来再动手处理，事后回查往往就没有了。
4.4 四条日志路径与参数开关：RZ10、RZ11、SM59、SSAA、SM02
事务码看的是已经解析过的信息，有些东西只有到文件系统里才看得见。四条路径记牢，排障能省很多时间。
# 把 PRD 换成实际系统标识，实例号 DVEBMGS00 按现场确认 SID=PRD # 1. 启动日志：实例启动过程的第一现场 ls -lt /home/${SID,,}adm/ | head -20 # 2. 工作进程日志：ST22 与 SM21 之外的原始输出 ls -lt /usr/sap/${SID}/DVEBMGS00/work/dev_w* | head -20 # 3. 传输日志：每次导入的完整记录 ls -lt /usr/sap/trans/log/ | head -20 # 4. 数据库日志：以 Oracle 为例的后台进程跟踪文件 ls -lt /oracle/${SID}/saptrace/background/ | head -20 # 顺手确认文件系统余量，比 ST06 更直接 df -h /usr/sap /oracle /sapmnt${SID,,}是 bash 的小写转换写法，把 PRD 变成 prd，因为启动日志目录是小写的 adm 用户主目录，需要 bash 4 以上。工作进程日志里的 dev_w* 是按进程号滚动的，时间最新的那个对应正在出问题的进程。传输日志目录会按日期切分，导入失败时在这里能看到比 STMS 日志更细的报错。数据库跟踪文件的位置随数据库类型不同而不同，上面这条是 Oracle 的常见路径。
参数这一层，RZ11 查当前生效值、默认值、是否支持动态修改；RZ10 改参数文件。改完要激活，多数参数需要重启实例才生效，所以动参数之前先确认这个参数是不是动态的，别在不该重启的时间点要求重启。
SM59 维护 RFC 连接，跨系统调用、传输、集成都依赖它，连接测试失败时先分清是网络不通、账号密码错，还是目标系统没起来。SSAA 是系统管理助手，把常用管理事务码收在一个菜单里，新人记不住事务码时从这儿进最省事。SM02 发系统消息，停机维护前给全体用户弹一条，比邮件通知到达率高得多。
5. 易漏点：巡检表上没写、出事才想起的五件事
巡检清单能列出“做什么”，列不出“容易在哪儿出错”。下面这五条都是从“明明按流程做了，结果还是出事”的场景里反推出来的。
5.1 数据侧的三处松动：备份、请求、空间
备份绿灯不等于能恢复。易漏点在于只看 DB12 里备份状态是成功，从不做还原演练。为什么漏？因为备份是自动跑的，半年没出过事，慢慢就没人看后半程了。怎么补：每个季度挑一个非生产环境做一次真实恢复，记录耗时和步骤；DB12 里同时看日志目录剩余空间，空间不足是备份失败的头号原因。
传输请求不检查对象清单就释放。易漏点在于 SE09 里直接点释放，不看对象数、不找 $TMP 本地对象。为什么漏？因为开发说“我改完了”，运维默认改完就等于进请求了，中间那一层没人验证。怎么补：释放前必看清单，重点找标着“本地”的条目；跨系统上线时用 STMS 的请求对象列表和开发给的清单逐条对照。
数据库空间只盯当前值，不看增长曲线。易漏点在于 DB02 只看“有没有满”，不看“多久会满”。为什么漏？因为没满的时候什么都不用做，等到报警再处理，留给扩容的窗口往往只剩几个小时。怎么补：每周记录一次主要表空间的占用，算出周增长量，把扩容动作排到增长到阈值之前，而不是报警之后。
5.2 会话侧的两处误判：SU53 与 SP01
SU53 现场丢失、SU10 用错地方。易漏点有两个，一是用户报权限错误，等运维连过去时 SU53 已经被下一次检查覆盖；二是想批量给用户加角色，结果打开了 SU10。为什么漏？因为 SU53 只保留最近一次，而 SU10 的界面看起来像“批量改一切”。怎么补：工单模板里加一句“报错时立刻截 SU53”；批量加角色走 PFCG 的用户比较或 SU01 逐个分配，SU10 只负责改属性。
SP01 里“已完成”不等于真的打出来了。易漏点在于看到状态完成就关单，用户说没出纸又重新开一张。为什么漏？因为 SAP 只跟踪打印任务到目标队列，出纸这一段发生在系统之外，客户端那台机器上的打印进程被关掉，系统这边完全不知道。怎么补：重要和批量打印任务在从 TemSe 删除之前，确认实际已经出纸；失败的任务可以重启，但重启前先查客户端那一段，否则还是失败。
5.3 把易漏点变成动作的三个做法
第一，把上面五条写进自己的巡检表，而不是记在脑子里。巡检表的价值不在内容多全，在于每次都会被执行一遍。
第二，每个易漏点都配一个可
本文还有配套的精品资源，点击获取
