简介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、SU22SU21、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 - sidadm tail -n 200 /home/sidadm/.saplog ls -lt /home/sidadm/ # 进程日志实例工作目录 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、SM66SM04 和 AL08 都用来查看当前在线用户区别在于 SM04 是服务器相关的视图只显示当前登录的 SAP 应用服务器上的用户AL08 是服务器无关的全局视图显示整个系统架构里所有在线用户。运维要关注的不只是“有多少人在线”而是“有没有不该在线的用户”“有没有用户正在用不该用的事务码”。比如财务月结期间某测试账号出现在生产系统里就应该警惕。SM51 显示 R/3 服务器概览可以列出系统中的所有应用服务器实例。它的用途是看不同服务器之间的工作进程分布当某台服务器负载很高而另一台很闲时就要考虑登录负载分配的问题。SM51 里双击某个服务器名称可以看到该服务器的工作进程状态这和 SM50 是配合使用的。SM66 是更全局的进程查看器它能看到整个 SAP 系统范围内所有服务器上的进程而不是单台服务器。当用户报告“系统卡死”而你手上有多台应用服务器时SM66 能帮你快速定位是哪台服务器的哪个进程在消耗资源而不是一台台登进去查。4.2 性能基线ST06 与 ST03ST06 是操作系统性能监控看的是 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、ST22SM50 用于查看单台 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/SIDadm→ 进程日志/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 的梳理也能帮你在复习和实战里更快画出属于自己的那张图。本文还有配套的精品资源点击获取