简介这份PDF资料面向SAP Basis运维初学者与日常系统管理员系统梳理了Basis岗位的职责定位与常用事务代码帮助读者快速建立日常运维的知识框架。内容涵盖用户权限管理、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理及重要日志查看等模块逐一列出SU01、PFCG、SCC4、DB13、SM36、ST06、STMS等核心事务码的用途与操作要点并补充了启动日志、进程日志、传输日志、数据库日志的存放路径便于按图索骥排查问题。资源包共1个PDF文件约2.02MB轻量便携适合随时查阅。目前已有961人学习说明其在Basis入门与日常参考场景中具有一定认可度。对于刚接触SAP系统管理或需要一份常用命令速查清单的运维人员这份资料可作为案头工具帮助理解各事务码在权限、监控、备份、传输等环节中的实际作用减少摸索成本。1. SAP日常运维BASIS为什么老手总在凌晨三点被叫醒SAP BASIS 日常运维说白了就是让一套 SAP 系统活着、跑得稳、出事能救回来。很多人以为 BASIS 就是装装系统、打打补丁真进了生产环境才发现日常运维里最要命的是那些不起眼的参数、后台作业和传输请求。我见过一个真实场景某公司月末结账前夜财务凭证突然卡死业务全线停摆最后查出来是某个后台作业把表空间撑爆了。这种事不是玄学是日常巡检没做到位。这篇文章面向刚接手 SAP BASIS 的运维人员也面向那些想从“能装系统”进阶到“能扛生产”的工程师。我会把日常运维拆成可执行的巡检、参数调整、传输管理和故障排查四块每一步都给出具体命令和判断标准让你照着做就能把系统稳住。2. SAP BASIS 日常巡检从 SM51 到 ST22 的最小检查清单日常巡检不是把事务码点一遍就完事关键是知道每个检查项背后的阈值和异常信号。我一般把巡检分成系统层、数据库层和应用层三块每块盯三到五个核心指标十分钟内能扫完。2.1 系统层用 SM51 和 SM04 确认实例与用户会话SM51 看的是应用服务器实例状态正常应该是绿色如果出现灰色或黄色先看 dev_w0 日志里有没有 dispatcher 报错。SM04 看当前登录用户重点不是数量而是有没有异常用户占着大量会话不放。比如某个 RFC 用户开了几百个会话大概率是接口程序没做好连接池。# 登录 SAP 系统后在命令框输入事务码 SM51 # 查看应用服务器实例列表检查状态灯 SM04 # 查看当前用户会话按会话数排序逻辑说明SM51 的状态灯直接反映实例是否可用灰色通常意味着实例进程挂了需要去操作系统层用ps -ef | grep dw.sap确认进程。SM04 里如果看到同一个用户有超过 50 个会话就要查这个用户是不是 RFC 通信用户如果是去 SM59 检查对应的 RFC 目标连接池配置。参数说明SM51 里重点看 “状态” 列绿色为正常黄色为警告灰色为停止。SM04 里重点看 “会话数” 和 “登录时间”如果某个会话登录超过 24 小时且没有操作可以考虑用 SM04 结束它但生产环境要谨慎先确认不是后台作业在跑。2.2 数据库层用 DB02 和 ST04 盯住表空间与锁等待DB02 看表空间使用率超过 85% 就要准备扩容超过 95% 就是随时可能翻车。ST04 看数据库性能重点看锁等待和缓冲区命中率。我一般会设置一个阈值锁等待超过 5 秒的会话数大于 3就要去查是哪个程序在锁表。-- 在 ST04 的 SQL 编辑器中执行查看当前锁等待 SELECT TOP 10 LOCKED_OBJECT, LOCK_MODE, WAITING_SESSION, HOLDING_SESSION FROM SYS.M_LOCK_WAITS ORDER BY WAITING_TIME DESC;逻辑说明这条 SQL 查的是当前数据库里正在等待锁的对象和会话。如果 WAITING_SESSION 对应的程序是某个 Z 开头的自定义报表大概率是报表没加索引或者用了 SELECT FOR UPDATE。解决方式要么优化 SQL要么在业务低峰期跑。参数说明LOCK_MODE 常见的有 S共享锁和 X排他锁X 锁等待通常意味着有写操作没提交。WAITING_TIME 超过 5000 毫秒就要关注超过 30000 毫秒基本就是业务卡死的元凶。2.3 应用层用 SM37 和 ST22 检查后台作业与 ABAP DumpSM37 看后台作业重点不是看有多少个在跑而是看有没有作业长时间处于 “运行中” 状态。一个作业跑超过 2 小时还没结束要么是程序逻辑有问题要么是数据库被锁了。ST22 看 ABAP Dump每天上班第一件事就是看昨天有没有新的 Dump特别是 “DBIF_RSQL_SQL_ERROR” 和 “TIME_OUT” 这两类。# 在 SM37 中筛选后台作业 作业名称* 用户名* 状态运行中 时间范围昨天到当前 # 在 ST22 中筛选 Dump 日期昨天 类型全部 排序按时间倒序逻辑说明SM37 里如果发现某个作业运行时间远超平时先双击进去看 “作业日志”里面会显示当前执行到哪一步。如果是 “正在执行 SQL”就去 ST04 看有没有对应的锁等待。ST22 里的 Dump 要重点看 “错误分析” 部分里面会直接告诉你哪个程序、哪一行代码出了问题。参数说明SM37 的 “运行中” 作业如果超过 2 小时建议先不要杀去操作系统层用ps -ef | grep sap看对应的工作进程 CPU 占用如果 CPU 占用高说明还在跑如果 CPU 占用低说明卡在数据库或锁上。3. SAP BASIS 参数调整RZ10 和 RZ11 里哪些参数不能乱动参数调整是 BASIS 日常运维里最容易翻车的地方。我见过有人为了 “优化性能” 把ztta/roll_area调大结果导致用户会话内存溢出系统直接宕机。参数调整的原则是先看默认值再看实际瓶颈最后小步调整并观察。3.1 RZ11 动态参数哪些可以热改哪些必须重启RZ11 可以动态修改参数但不是所有参数都支持热改。支持动态修改的参数改完立即生效不需要重启实例不支持动态修改的改了也会提示 “需要重启”。我一般会先用 RZ11 查参数说明看 “动态” 那一栏是不是 “是”。# 在 RZ11 中输入参数名例如 ztta/roll_area 参数名ztta/roll_area # 查看 “动态” 列如果是 “是”可以直接修改 # 修改后点击 “保存”然后点击 “激活”逻辑说明RZ11 修改的是当前实例的内存参数不会写入配置文件。如果实例重启参数会恢复成 RZ10 里的配置。所以动态修改适合临时调整比如某个时段用户量突增临时调大ztta/roll_area等高峰过去再改回来。参数说明ztta/roll_area控制的是 ABAP 程序的内存滚动区域默认值通常是 2000000 字节。调大可以支持更复杂的程序但会占用更多内存。如果系统物理内存不足调大这个参数反而会导致换页性能更差。3.2 RZ10 静态参数修改后必须重启实例RZ10 修改的是配置文件改完必须重启实例才生效。我一般会在业务低峰期做这件事并且提前通知业务方。修改前先备份配置文件用 “实用程序” 里的 “导出配置文件” 功能。# 在 RZ10 中选择配置文件例如 DEFAULT # 点击 “修改”找到参数修改值 # 点击 “保存”然后点击 “激活” # 最后重启实例在操作系统层执行 sapcontrol -nr 00 -function RestartInstance逻辑说明RZ10 修改的是实例的启动参数重启后生效。如果修改后实例起不来可以用sapcontrol -nr 00 -function GetProcessList看进程状态或者直接看dev_w0日志里的报错。参数说明常见的静态参数有rdisp/wp_no_dia对话工作进程数和rdisp/wp_no_btc后台工作进程数。调整这两个参数要考虑 CPU 核数一般对话进程数不超过 CPU 核数的 2 倍后台进程数不超过 CPU 核数的 1.5 倍。3.3 内存参数ztta/roll_area 和 abap/heap_area_total 的搭配逻辑内存参数是调优的重灾区。ztta/roll_area是单个对话进程的内存滚动区域abap/heap_area_total是所有工作进程能用的堆内存总和。这两个参数要搭配调整不能只调一个。# 查看当前内存使用情况 ST02 # 看缓冲区命中率和内存使用 SM50 # 看工作进程的内存占用 SM04 # 看用户会话的内存占用 # 调整参数 RZ11 # 动态调整 ztta/roll_area RZ10 # 静态调整 abap/heap_area_total逻辑说明如果 ST02 里 “Heap Memory” 使用率超过 80%说明堆内存不够需要调大abap/heap_area_total。如果 SM50 里某个工作进程的 “Memory” 列特别高说明这个进程在跑大程序需要调大ztta/roll_area。参数说明abap/heap_area_total的默认值通常是物理内存的 60% 到 70%。调大这个参数会占用更多操作系统内存如果物理内存不足会导致操作系统换页性能反而下降。建议先看操作系统的free -m输出确保有足够的空闲内存。4. SAP BASIS 传输管理STMS 里那些让你后悔药都没得吃的事传输管理是 BASIS 日常运维里最需要细心的地方。一个传输请求搞错轻则覆盖别人的代码重则导致生产系统宕机。我见过有人把开发机的传输直接放到生产机结果把生产机的配置覆盖了花了整整一天才恢复。4.1 STMS 传输队列如何避免传输请求互相覆盖STMS 的传输队列是按顺序执行的如果两个传输请求改了同一个对象后执行的会覆盖先执行的。我一般会在传输前用 “传输请求” 里的 “对象列表” 功能看两个请求有没有冲突对象。# 在 STMS 中查看传输队列 STMS # 选择 “传输队列” # 双击传输请求查看 “对象列表” # 如果有冲突对象先调整传输顺序逻辑说明传输队列里的请求是按顺序执行的如果请求 A 改了程序 Z_TEST请求 B 也改了 Z_TEST那么 B 会覆盖 A 的修改。解决方式要么调整顺序要么把两个请求合并。参数说明STMS 里的 “传输请求” 状态有 “可传输”、“已传输”、“已导入” 等。如果状态是 “已导入”说明已经进生产了不能再改。如果状态是 “可传输”说明还在队列里可以调整顺序。4.2 传输请求的依赖关系如何用 STMS 的 “传输组” 功能传输组可以把多个传输请求打包成一个组按组传输。这样即使组内有依赖关系也能保证顺序执行。我一般会把同一个功能的多个请求放在一个传输组里。# 在 STMS 中创建传输组 STMS # 选择 “传输组” # 点击 “创建”输入组名例如 ZGROUP_001 # 把相关的传输请求加入组 # 传输时选择 “传输组”而不是单个请求逻辑说明传输组里的请求会按加入顺序执行不会互相覆盖。如果组内某个请求失败整个组会停止不会继续执行后面的请求。参数说明传输组的 “组名” 建议用有意义的命名比如 “ZFI_202401” 表示财务模块 2024 年 1 月的传输。组内的请求顺序可以调整用 “向上” 和 “向下” 按钮。4.3 传输失败后的回滚STMS 的 “回滚” 功能怎么用传输失败后STMS 提供了 “回滚” 功能可以把已经导入的请求撤销。但回滚不是万能的如果传输已经改了数据库表结构回滚可能不彻底。# 在 STMS 中选择失败的传输请求 STMS # 选择 “传输请求” # 双击请求点击 “回滚” # 确认回滚系统会执行反向操作逻辑说明回滚功能会执行传输请求的反向操作比如删掉新增的程序、恢复被修改的程序。但如果传输改了数据库表结构回滚可能无法恢复数据。参数说明回滚前一定要确认传输请求的状态是 “已导入”如果是 “已传输” 但没导入不需要回滚。回滚后要检查 ST22 有没有新的 Dump确保系统正常。5. SAP BASIS 避坑指南那些年我踩过的五个坑5.1 坑一后台作业把表空间撑爆现象系统突然变慢DB02 显示表空间使用率 99%业务无法保存凭证。原因某个自定义报表程序没有分页一次性从数据库取了几百万条数据把临时表空间撑爆了。解决先去 ST04 找到正在跑的 SQL用 SM37 杀掉对应的后台作业然后去 DB02 扩容表空间。长期方案是优化报表程序加分页和索引。5.2 坑二传输请求覆盖了生产机的配置现象生产机某个程序突然报错查代码发现是开发机的旧版本。原因开发机有个传输请求改了同一个程序但传输顺序搞错了旧版本覆盖了新版本。解决从 STMS 里找到正确的传输请求重新导入。长期方案是用传输组管理有依赖关系的请求。5.3 坑三参数调整导致实例起不来现象修改 RZ10 参数后重启实例实例一直起不来dev_w0 日志报 “内存分配失败”。原因把abap/heap_area_total调得太大超过了物理内存操作系统无法分配。解决用sapcontrol把实例停掉手动编辑配置文件把参数改回默认值再启动实例。长期方案是调整参数前先看操作系统内存。5.4 坑四用户会话占满工作进程现象用户无法登录SM04 显示大量会话SM50 显示所有对话进程都在忙。原因某个 RFC 接口程序没有正确关闭连接导致会话一直挂着。解决用 SM04 结束异常会话然后去 SM59 检查 RFC 目标连接池配置。长期方案是给 RFC 用户设置会话超时。5.5 坑五ST22 Dump 被忽略导致业务中断现象系统每天都有少量 Dump没在意直到某天 Dump 数量暴增业务中断。原因某个程序在特定数据下会触发 Dump平时数据量小没暴露数据量大了就频繁触发。解决每天上班先看 ST22发现重复 Dump 立即查程序。长期方案是设置 ST22 的告警Dump 数量超过阈值就发邮件。6. SAP BASIS 进阶技巧用 SM50 和 ST12 做性能瓶颈定位性能问题是最难排查的因为涉及操作系统、数据库、SAP 应用三层。我一般会用 SM50 看工作进程状态用 ST12 做单步跟踪定位到具体是哪一行代码慢。6.1 SM50 工作进程状态解读哪些状态是正常的SM50 里工作进程的状态有 “等待”、“运行”、“暂停”、“停止” 等。正常情况大部分进程应该是 “等待”如果有多个进程长时间 “运行”说明系统负载高。# 在 SM50 中查看工作进程 SM50 # 选择 “进程列表” # 重点看 “状态” 和 “CPU” 列 # 状态为 “运行” 且 CPU 高的进程双击查看 “当前程序”逻辑说明SM50 的 “运行” 状态表示进程正在执行 ABAP 程序如果 CPU 占用高说明程序在计算如果 CPU 占用低说明程序在等数据库或锁。参数说明SM50 里的 “CPU” 列是进程占用的 CPU 时间单位是秒。如果某个进程的 CPU 时间持续增长说明程序在跑循环或复杂计算。6.2 ST12 单步跟踪如何定位到具体哪一行代码慢ST12 可以跟踪一个程序的执行过程显示每一步的耗时。我一般会用 ST12 跟踪一个慢的报表看是哪一步在等数据库。# 在 ST12 中创建跟踪 ST12 # 选择 “创建跟踪” # 输入要跟踪的程序名和用户 # 执行程序然后回到 ST12 查看跟踪结果 # 重点看 “数据库” 和 “CPU” 的耗时逻辑说明ST12 的跟踪结果会显示每个 ABAP 语句的耗时如果某个 SELECT 语句耗时特别长说明数据库索引有问题。参数说明ST12 的 “数据库” 耗时包括 SQL 执行时间和数据传输时间。如果 SQL 执行时间长去 ST04 看执行计划如果数据传输时间长说明取的数据太多需要加 WHERE 条件。6.3 用 ST04 看 SQL 执行计划如何判断索引是否生效ST04 可以看 SQL 的执行计划判断有没有走索引。如果执行计划里出现 “TABLE SCAN”说明没走索引需要加索引。-- 在 ST04 中查看 SQL 执行计划 SELECT * FROM ZTABLE WHERE FIELD1 VALUE; -- 查看执行计划 EXPLAIN PLAN FOR SELECT * FROM ZTABLE WHERE FIELD1 VALUE; SELECT * FROM TABLE(DBMS_XPLAN.DISPLAY);逻辑说明执行计划里的 “TABLE ACCESS FULL” 表示全表扫描“INDEX RANGE SCAN” 表示走索引。如果全表扫描的数据量大就要考虑加索引。参数说明加索引要用 SE11 在表上创建索引字段选择 WHERE 条件里常用的字段。加完索引后用 ST04 重新看执行计划确认走索引。我一般会在每天下班前花十分钟看一遍 SM37、ST22 和 DB02这三个事务码能覆盖 80% 的日常问题。希望帮到你。本文还有配套的精品资源点击获取