简介SAP日常运维BASIS是面向SAP系统管理/运维人员的一份Basis基础速查资料围绕SAP系统日常运维中的常见任务系统梳理了用户权限、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理以及重要日志查看等核心模块适合刚接触Basis的顾问或需要快速查找常用事务代码的运维工程师使用。资源包内共有1个PDF文件整体大小为2.02MB以科莱特SAP内训讲义为基础逐块列举了SU01、PFCG、SU53、SCC4、DB13、SM36、ST06、SM21等高频事务代码并辅以简要操作说明和注意事项例如数据库备份检查、打印假脱机处理、系统日志分析等可帮助读者快速定位日常运维所需命令也能当作备用速查手册。目前已有962人学习或下载该资源适合SAP BASIS零基础或初级运维者用于建立知识框架、对照练习与现场排查。1. SAP BASIS 日常运维先摸清这套系统的运行脉搏SAP BASIS 日常运维在不少团队里像个黑匣子系统在线时没人觉得这活儿重要哪一天登录卡死、后台作业取消、数据库空间告急才想起 Basis 顾问的价值。很多刚转运维的开发者问我的第一个问题就是每天都该点哪些事务代码其实 BASIS 日常运维是有清晰脉络的——用户权限、集团管理、数据库维护、后台作业、打印管理、系统监控、传输管理每一条线都有固定的工具组合和巡检顺序。这篇文章把我在生产环境里筛过一遍的常用事务代码和踩坑记录整理出来从高频操作讲到验证方法新手照着走能建立自己的巡检清单熟手可以拿来做标准化流程对照。后续章节依次展开每个事务代码都说明它管什么、怎么用、容易在哪里出问题。2. 用户权限与集团管理SU01、PFCG、SCC4 的高频操作2.1 SU01 用户维护解锁、改密、复制账号的标准动作在 BASIS 运维的所有事务代码里SU01 的出场率绝对排第一。用户密码忘了找你、账号被锁了找你、新同事入职要开号还是找你。SU01 承担的是创建、修改、显示用户信息这个职责界面清爽输入用户名直接回车就能看到用户主数据的所有页签。处理密码重置和解锁时标准路径是SU01 → 输入用户名 → 回车 → 切到Logon data页签 → 点Unlock解除锁定同时在New password字段里输入临时密码。这里有两个参数容易被忽略一是User type对话用户Dialog和系统用户System的密码策略不一样给接口账号重置密码时选错类型会导致登录行为异常二是有效期设置如果用户主数据里之前维护了过期日期重置密码后要顺手清掉不然用户第二天登录又报密码过期工单会再次打到你这来。很多运维新手会被一个现象搞蒙用户说密码是对的但登录报错。打开 SU01 一看用户状态是 locked原因是连续输错次数超过系统参数login/failed_user_attempts配置的阈值默认一般是 3 次。这时候直接解锁并重置密码就行不用改任何参数。如果同一个用户频繁被锁就要考虑是不是有人在暴力试探账号该走安全审计的走 SM20别只闷头解锁。我在某公司接手系统运维的头一个月就遇到过外包账号连续七天早上被锁的情况后来查 SM20 才发现是上一个项目残留的脚本在定时用旧密码尝试登录属于典型的自动化作业没清理干净。复制账号也是 SU01 的高频功能。新员工入职时最省事的做法是以一个权限相近的既有账号为模板SU01 → 输入新用户名 → 回车 → 界面提示用户不存在 → 选择复制功能填入模板用户名。复制过来的账号会连带角色、参数文件等主数据但密码字段是空的需要单独设置。我一般会提醒一句复制前先确认模板账号的权限是正确且干净的不然新员工还没入职就把旧账号的失控权限全部继承过去了这是权限管理里最常见的隐形风险。批量场景用 SU10。比如季度末有几十个外包账号要统一锁定SU10 支持根据用户组、最后登录时间等条件筛选出用户列表然后统一执行锁定、密码重置或删除操作。这个事务代码在账号生命周期管理里特别有用做季度账号巡检时能省下大量重复点击的时间。SAP 标准的用户信息类型里Dialog 用户对应人工登录Communication 用户对应 RFC 接口Service 用户对应匿名服务访问批量修改前先按用户类型筛一遍别把接口账号锁了导致外围系统报错。2.2 权限对象与角色维护PFCG、SU21、SU53 的授权链PFCG 是角色维护的中枢它把一组事务代码、权限对象和授权字段打包成角色再批量分配给用户。创建角色的大致步骤输入角色名 → 创建 → 在菜单/事务页签中加入事务代码 → 在权限页签中维护权限对象 → 生成概要文件 → 分配用户。看起来简单实际最容易翻车的是最后一步生成概要文件很多新手配完角色忘记点生成或者生成失败也没发现用户那边权限一点变化都没有报障回来才一层层排查。角色类型有两种单个角色Single Role和复合角色Composite Role。复合角色下挂多个单角色分配账号时只需要分配复合角色简化了管理。但如果复合角色下某个单角色改了权限要记得重新生成概要文件并等待传输。这个传播过程有时候像玄学明明改了角色用户权限没生效别急着查用户先去角色生成日志里看概要文件是否生成成功。我碰到过最隐蔽的一次是某个角色在开发系统里正常生成但传输到生产系统后概要文件没带过去用户在生产环境始终拿不到权限查了半天才发现是 STMS 传输队列里有一个相关请求被卡住了。SU21 和 SU20 是权限对象和权限字段的底层维护工具。普通运维用的频率不高但遇到自定义权限对象需求时绕不开。SU22 则负责维护事务代码与授权对象的关联关系当你在 SU01 里给用户授权某个事务代码时系统会自动带上它的标准授权对象。理解这条链路很重要事务代码 → 授权对象 → 授权字段 → 字段值任何一个环节不对权限都不生效。SU53 是我眼里最实用的权限排查工具。用户执行某个事务报没有权限时不要对着角色列表瞎猜让用户在报错界面输入/nSU53系统会把他本次缺失的权限对象、字段、值清清楚楚列出来。拿着这个输出回 PFCG 调角色一次到位。在运维交接时我会专门培训用户学会这个操作能少接一半的权限工单。这个习惯帮我省下了大量沟通成本也让业务用户从只会报障变成了能带着 SU53 截图来报障。2.3 集团管理SCC4、SCCL、SCC1 与 SCC5 的实操集团Client是 SAP 系统数据隔离的容器。SCC4 管集团的创建、修改和显示集团属性里最重要的参数是集团角色比如生产、测试、定制。生产集团建议设为生产并勾选禁止直接修改配置否则业务顾问在生产系统里乱改配置最后传到其他环境时牵一发动全身。我自己一般会定一个集团命名规范000、001 这类留给 SAP 标准集团自定义集团从 100 起步避免和系统集团混淆。SCCL 拷贝集团。运维场景里把配置从开发集团复制到测试集团是很常见的。SCCL 的机制是按逻辑数据库把源集团的数据复制到目标集团操作时要注意目标集团必须干净没有业务数据拷贝期间系统不要做其他在线变更否则容易造成数据不一致。SCCL 是重量级操作耗时随数据量增长我一般安排在业务低峰期执行并且提前通知业务侧这个集团暂时不要登录。SCC1 是单传输请求的系统内拷贝工具。开发顾问释放了传输请求后SCC1 可以用来把某个请求直接拷到同一个系统里的另一个集团不需要走 STMS 跨系统传输。SCC1 在配置传输的快速验证场景里很有用比如测试集团刚建好想快速验证某个请求的配置效果用 SCC1 比 SCCL 整个集团快得多。SCC3 查看集团操作日志什么人在什么时间对哪个集团做了什么操作审计排查时一查一个准。SCC5 删除集团属于高危操作。删之前一定先确认集团可销毁最好做一次数据备份。生产系统里我基本不会执行 SCC5删集团这个动作只发生在测试或沙盒环境。运维团队如果对某个废弃集团不确认宁可多留半年也不要因为省空间去删删了数据可就真没了。提示集团管理操作尽量纳入传输请求统一管理而不是在系统里直接改配置。否则后续跨系统传输时会漏掉这部分配置这种漏配置的翻车经历我遇到过不止一次。3. 数据库维护与备份检查DB13、DB02、BRTOOLS 组合拳3.1 DB13 维护日历备份、Check 与统计信息更新DB13 是数据库日常维护的调度入口在 SAP Oracle 架构下数据库的备份、完整性检查、优化器统计信息更新都可以在 DB13 里定义成周期性任务。它的核心思路是把人肉运维变成日历运维提前把每天的备份、每周的检查排进去系统自动执行运维只需要盯日志。配置方法DB13 → 定义维护日历 → 选择动作备份/检查/统计信息更新→ 设置频率每日/每周/每月→ 保存。备份动作最好区分在线备份和离线备份。在线备份不中断业务适合生产系统离线备份在数据库关闭状态下做数据一致性最干净但要停几分钟。增量备份用来减少备份窗口但恢复时依赖全量备份加归档日志链路比全量备份长需要提前演练恢复流程。备份类型是否停机恢复复杂度适用场景离线备份是最简单测试、维护窗口在线备份否需归档日志配合生产系统日常备份增量备份否需要全量增量链完整数据量大、备份窗口小DB13 里还关联了数据库后台作业的日志可以直接查看每个维护动作上次运行时间和返回码。我每天早上到工位第一件事就是打开 DB13 看昨晚有没有作业报错。返回码非 0 的作业不能放过必须点进去看详细日志。曾经有一次备份作业返回码 8点进去发现是归档日志目录空间不足数据库自动切换归档失败所幸发现得早否则整个数据库可能挂起。3.2 DB02 与 DB12表增长、索引碎片和备份日志DB02 是数据库表和索引的监控台运维打开它主要看两个指标空间扩展和碎片情况。SAP 表数据量增长后表空间会不断扩展如果某个表频繁扩展扩展次数很多说明它的初始空间设置不合理扩容频率太高这时候需要和开发确认是否能做表压缩或归档。索引碎片化严重时优化器选错执行计划SQL 性能就会恶化最典型的现象是同一个查询白天还快晚上突然慢了几十倍。DB12 是数据备份日志入口功能单一但极其重要。每天早上必须确认夜间备份是否成功同时检查日志目录剩余空间。日志目录空间满了会导致数据库挂起这种故障一旦发生影响的是整条业务链。我习惯在 DB12 里不只检查备份的返回码还会看备份文件的生成大小如果某天的备份文件比平时小很多要警惕是不是数据写入异常或者备份中断这种隐性风险比直接报错的备份更危险。3.3 BRTOOLS操作系统层的数据库管理工具BRTOOLS 是 Oracle 数据库在操作系统层的工具箱DBA 场景下经常直接用命令行执行备份恢复不依赖 SAP GUI。最常用的命令是brbackup备份、brrestore还原、brconnect连接测试它们位于/sapmnt/SID/exe或/usr/sap/SID/exe目录下。比如手动跑一次数据库在线备份brbackup -u / -c force -t online参数说明-u /表示使用操作系统认证连接数据库-c force强制按配置文件中的模式执行-t online指定在线备份。在线备份需要数据库运行在归档模式否则备份出来的文件无法保证恢复一致性。执行完成后brbackup 会在备份日志中输出备份集文件名和耗时运维要确认返回码非 0。数据库的跟踪日志和告警日志在/oracle/SID/saptrace/background目录下我排查数据库异常时最先看这个目录里的 alert 日志。注意区分SAP 应用层的日志走/usr/sap/SID/DVEBMGS00/work数据库层的日志走/oracle/SID/saptrace/background两层日志别搞混。遇到过同事在应用层日志里翻了一个下午找数据库报错最后发现方向完全错了从数据库层日志入手五分钟就定位到是 redo log 切换异常。BRTOOLS 还有一个实用的场景是日常健康检查brconnect -u / -c state可以快速查看数据库实例状态、数据文件是否在线、表空间使用情况。这套命令行工具在服务器无法打开 SAP GUI 时是救命稻草远程排障基本靠它。4. 后台作业与打印管理SM36、SM37、SPAD/SP01 的盯防4.1 SM36 定义后台作业步骤、周期与服务器SM36 是后台作业的定义工具。一个后台作业包含三个核心要素作业步骤Job Steps、运行周期Periodic Values、运行服务器Start Conditions。作业步骤指定要执行的 ABAP 程序或外部命令运行周期决定是每天、每周还是每月执行开始条件可以指定服务器实例、立即启动或按时间启动。定义作业的习惯建议作业名使用统一的命名约定例如ZDAILY_REPORT、ZMONTHLY_CLEANUP方便在 SM37 里按前缀过滤。每个作业步骤前加上程序名或说明字段这样监控时不用点进日志就能知道这个作业在干什么。后台作业的执行优先级也值得注意日常报表放在低优先级数据库备份相关作业放在高优先级避免互相抢资源。如果同一台应用服务器上既跑着大量报表作业又跑着数据库备份备份时间会被明显拉长DB13 的备份窗口不够用就是这个原因。SM36 里还有一个经常被忽略的参数是作业开始条件中的实例选择。多实例环境下不指定运行服务器的话作业可能被分配到任意一个应用实例上执行。如果某个作业依赖特定实例的本地文件或 RFC 配置就必须固定运行实例否则作业偶发失败排查半天才发现是实例漂移的问题。4.2 SM37 监控作业取消、日志与重跑SM37 是后台作业的监控窗口运维每天要看的核心数据是哪些作业今天跑完了、哪些取消了、哪些还在 running。筛选条件支持按作业名、用户名、时间段和作业状态。我一般会按今天已完成/已取消/已计划三个视图分别拉一遍确保没有遗漏。被取消的作业CANCELLED必须逐个分析原因。常见原因有几类数据库连接断开、作业运行期间系统重启、ABAP 程序运行时报错、权限不足。查看作业日志可以看到具体 ABAP 错误号但有时候日志里只有一句Program terminated这时候需要结合 ST22 看是否有短转储。如果作业在凌晨两点被取消而系统昨晚确实重启过那大概率是重启时作业窗口被跳过重新调度一次通常就能解决。输出列表Output List也要检查。后台报表程序生成的输出列表会占用 spool 空间定期清理过期列表是运维好习惯。SM37 里的重跑操作不复杂选中取消的作业 → 重新调度 → 系统会基于原作业定义重新执行。重跑前先确认底表数据是否已经部分写入避免重复数据。比如一个日结汇总作业在中途失败但前半小时的数据已经汇总入表直接重跑可能导致重复累计这时候要和业务确认是覆盖式还是追加式逻辑。4.3 SPAD 与 SP01打印设备定义与假脱机请求排错SPAD 负责定义打印设备。每台打印机在 SAP 里都对应一个输出设备Output Device一般绑定到应用服务器主机名和打印命令。SPAD 里设置设备类型、驱动类型和打印参数时要注意主机字符集中文环境下打印乱码多半是设备定义里的字符集没配对。新接入一台网络打印机时我会先在 SPAD 里用现有的设备复制一份再改参数比从零定义少踩很多坑。SP01 是假脱机请求和输出请求的管理器。打印任务提交到 SAP 后先进入 TemSe临时顺序文件再被假脱机处理。如果用户反映打印不出来先打开 SP01 看这个任务的输出状态。输出状态停在in process或一直显示planned通常是打印服务器不接受任务。这时可以选中任务重新启动输出也可以直接删除请求让用户重新打印。一个很容易误判的情况SP01 里输出状态显示完成但打印机实际没出纸。原因在于 SAP 的假脱机管理只跟踪打印任务到达输出队列为止并不跟踪打印机是否真正出纸。所以重要的打印任务不能在看到完成状态后就从 TemSe 删除要先和用户确认纸已经出来。删除假脱机请求也是 SP01 里最常见的操作之一失败任务可以选中后重新启动。前端 SAPLPD 被关闭是最常见的根因用户端程序没起来任务堆积在队列里让用户重启 SAPLPD 或重新登录即可。注意从 TemSe 删除假脱机请求是不可逆的删除前务必确认任务已完成或用户已确认不需要。宁可多留一天也不要手快误删。5. 系统监控与常见问题排查ST06、SM50、ST22 巡检与避坑5.1 ST06 与 ST03操作系统资源与工作负载基线ST06 是操作系统性能监控入口。运维每天要看的指标是 CPU 使用率、内存使用率、Page Space 使用率和磁盘 IO。CPU 长期高于 80%先考虑是否有失控报表在跑内存使用率高要看是 SAP 缓冲区还是操作系统文件缓存两者处理方向完全不同。Page Space交换分区使用率持续攀升是危险信号说明物理内存已经不够用系统开始频繁交换整个应用响应会显著恶化。ST03 是工作负载监控它能按小时、天、周显示系统的总负载、响应时间和处理时间。最有价值的用法是做基线对比在没有性能问题的时候保存一份完整的负载数据当系统变慢时拿当前数据和基线对比很快能定位到是哪个时间段的哪个事务变慢了。业内有一句话叫世上没有经验的替代品——基线数据越全你对系统的感觉越准。所以我一接手新系统第一件事就是把 ST03 历史数据全部导出归档这些数据在调优时价值巨大。5.2 SM50、SM51、SM66进程与服务器管理SM51 显示 SAP 应用服务器列表。如果系统是多实例架构多个应用服务器SM51 是你确认每台服务器是否在线的地方。双击某个服务器可以看到它的工作进程状态。SM50 显示单台服务器的工作进程包括对话、更新、后台、打印等各类进程。SM66 则跨服务器显示所有进程适合全局排障。进程管理中最敏感的操作是 kill 进程。SM50 里选中一个长时间 running 的进程可以查看其会话 ID、程序名和 CPU/内存占用量。确认是失控的报表程序后先和用户协商再终止不能直接杀——如果这个进程正在做数据更新强行终止可能造成数据不一致。我处理过最惊险的一次就是一个长报表卡了四个小时用户舍不得放弃后来说是程序死锁最终协商后 kill 掉了没有造成数据问题。SM04 和 AL08 都用来查看当前在线用户区别在于 SM04 是基于当前服务器的会话列表AL08 是跨服务器的全局用户列表。运维监控时用 AL08 能一把看到整个系统多少人在线有没有可疑账号。我每周会用 AL08 对一遍在线用户清单和考勤系统对比找出那些人不在岗但账号在线的会话多半是账号被共享了。5.3 SM12、SM13、SM21、ST22锁、更新与异常日志SM12 是锁管理器。用户在操作过程中断线、程序出错可能导致数据库对象锁没有被释放。SM12 列出所有当前锁老化的锁对象要逐条分析确认业务任务已经终止后手动删除锁。删除锁之前一定要确认没有正在执行的事务还在用这个对象否则会引发数据不一致。锁管理有一个经验值凌晨自动释放的锁通常是正常的白天空闲时间长期挂着的锁才可疑。SM13 显示更新请求的状态。失败的更新动作状态为 V1/V2 终止在生产系统中不允许存在一旦出现要立刻定位原因要么是数据库错误要么是程序 bug需要开发介入处理。如果一个失败的更新请求长时间不处理后续依赖它的业务流程会不断堆积报错。我处理过最典型的是财务月结时更新失败导致成本分摊流程中断最后是更新功能模块配置错误导致的。SM21 是系统日志。SAP 服务器会把系统事件、警告、错误都记录在这里。每天巡检的原则是所有警告和错误信息都要过一遍能解决的当场解决不能解决的记录到问题跟踪清单里。SM20 是安全审计日志配合用户权限巡检异常登录、多次失败尝试等行为会在里面留痕。实施类项目里 SM20 平时不太有人看但运维阶段它是对抗暴力破解的重要情报来源。ST22 是 ABAP 短转储short dump的分析入口。当 ABAP 程序因为严重错误终止时系统除了在日志里记录错误还会把出错的详细信息存到表 SNAP 中。ST22 里可以看到 dump 时间、出错程序、错误类别和堆栈。运维每天要扫一遍 ST22即使业务用户不报障后台作业也可能产生短转储。遇到生产系统里的 short dump不能只知道重启程序要顺着错误类别排查代码逻辑问题。5.4 常见问题与避坑清单汇总一下我实际碰过的典型坑每一条都是现象→原因→解决的闭环给正在做 BASIS 运维的同行一个参考。坑1用户账号反复被锁现象用户连续多天报登录不上提示 has been locked。原因连续输错密码次数超过系统策略也可能是密码过期后用户还在输旧密码。解决SU01 解锁并重置密码同时用 RZ11 查看login/failed_user_attempts参数确认阈值是 3 次还是 5 次。如果某账号频繁被锁结合 SM20 安全审计日志确认是不是异常访问。曾经遇到过某个接口账号每周一早上被锁后来发现是外围系统在每周一凌晨用旧密码重连密码更新后旧密码没有同步到对方配置里。坑2SM37 作业取消作业日志无有效报错现象作业状态 CANCELLED打开作业日志只有一行 Program terminated without message。原因作业运行期间数据库连接断掉或系统在作业启动前经历了一次重启。解决先看系统启动时间SM51 里的实例启动时间如果作业计划时间和系统重启时间重合基本上是重启错过窗口。重新调度作业并确认数据库处于正常状态。这类问题在系统自动重启后特别容易成批出现处理时不要一个个点用 SM37 的批量重调度功能一次拉起来。坑3DB02 表空间使用率告警现象DB02 页面红色告警某表空间使用率超过 95%。原因业务数据增长快或归档日志没有定期清理表空间数据文件无法自动扩展。解决扩展表空间数据文件清理过期归档日志。同时在 DB13 里确认统计信息更新作业正常运行优化器有最新数据才能避免执行计划异常。我一般会在 DB13 里给表空间使用率设置预警阈值在 85% 时就提前介入而不是等到 95% 的红色警报。坑4ST22 短转储出现但用户无感知现象ST22 里有几条 short dump业务用户没人报障。原因触发错误的是后台作业错误导致该批次数据处理中断但因为作业已经标记为取消没有直接弹给用户。解决查看 dump 完整信息转给开发修复 ABAP 代码。修复前暂时将作业从 SM36 置为不活跃避免每次跑都报错刷屏。同时把 dump 的发生频率记录下来作为判断故障严重程度的依据。坑5SP01 打印状态显示完成但没出纸现象用户拿着任务号说没打印出来SP01 里状态是 completed。原因SAP 只跟踪任务到输出队列不确认打印机实际是否出纸。打印机离线、纸盒缺纸、前端 SAPLPD 被关闭都会导致这种假完成。解决先确认打印机物理状态再让用户检查 SAPLPD。重要打印任务在从 TemSe 删除之前必须人工确认。这个坑在月底报表集中打印时特别容易暴雷我会在和业务开会时反复强调看到completed不代表纸出来了。6. 传输管理与日志验证从 SE09 到日志目录的收尾检查6.1 SE09 与 STMS传输请求的释放与导入验证SE09 是传输请求的管理入口开发顾问在这里创建改变请求、把任务加入请求、最终释放请求。STMS 则是传输管理系统负责把释放的请求从一个系统传到另一个系统同时维护传输队列和集团策略。验证一套 SAP 环境传输链路的健康状态最直接的方法就是走一个端到端的传输在开发系统创建一个测试请求释放然后在 STMS 里将它导入测试系统观察传输队列是否正常清空目标系统里的对象是否生效。6.2 日志目录验证四类日志逐一确认新装或新接手一套环境时日志目录的完整性和可写性是必须验证的基础项。打开终端按以下顺序扫一遍ls -lt /home/SIDadm/ ls -lt /usr/sap/SID/DVEBMGS00/work/ ls -lt /usr/sap/trans/log/ ls -lt /oracle/SID/saptrace/background/说明第一行是 SAP 启动日志确认最近一次系统启动记录正常第二行是应用服务器进程日志检查有没有频繁的警告堆栈第三行是传输日志确认最近的导入操作都成功结束第四行是 Oracle 数据库跟踪日志重点看 alert 日志里有没有 ORA- 错误。这四个目录的时间戳必须都在最近——如果某个目录的最后修改时间是几天前甚至几周前说明对应组件可能已经异常停摆。6.3 一套完整验证动作走查接手任何一套 SAP 系统我都会强制走一遍这套动作先 SM51 确认所有应用服务器在线再 ST06 看一眼操作系统资源水位然后 DB13/DB12 确认备份链路正常SM37 确认没有堆积的取消作业ST22 确认没有未处理的 short dump最后 STMS 里放一个测试传输请求跑通传输链路。全部通过才敢对外说这套环境是健康的。从那以后我每次接手新环境都强制自己从头到尾走一遍这套验证流程不跳跃、不省略。这套动作救过我一次某次新环境表面一切正常但我在走 STMS 测试传输时发现队列卡住请求始终不启动排查后才知道目标系统的传输目录权限配置错了如果不走这一遍第一个正式传输就会在业务高峰期翻车。希望帮到你。本文还有配套的精品资源点击获取
