简介这份PDF资料面向SAP Basis运维初学者与日常系统管理员系统梳理了SAP Basis岗位的职责定位与常用事务代码帮助读者快速建立日常运维的知识框架。内容涵盖用户权限管理、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理及重要日志查看等模块逐一列出SU01、PFCG、SCC4、DB13、SM36、ST06、STMS等核心事务码的用途与操作要点并补充了启动日志、进程日志、传输日志、数据库日志的存放路径便于按图索骥排查问题。资源包共1个PDF文件大小约2.02MB轻量便携适合随时查阅。目前已有961人学习适合刚接触SAP Basis的运维人员作为日常速查手册也可供实施顾问巩固基础命令、梳理监控与调优思路时参考。1. SAP日常运维BASIS从“救火队员”到“系统管家”的分水岭很多刚接触 SAP 的同行对 BASIS 这个角色的第一印象就是“装软件、重启服务、导请求”。日常运维里最常被问到的也是“系统卡了怎么办”“传输报错怎么修”“用户锁了怎么解”。但真正做过几年 SAP日常运维BASIS 的人会明白这个岗位的核心不是被动响应而是把系统可用性、性能水位和变更风险控制在可预期范围内。它解决的是企业核心 ERP 跑得稳不稳、快不快、能不能安全变更的问题适合已经有一定 Linux 和数据库基础、准备从“点按钮”转向“看指标”的运维人员。这篇文章不讲虚的只拆我日常真正在用的排查路径、参数调整和避坑习惯让你能照着复现一套最小可用的 BASIS 运维框架。2. 日常巡检到底看什么从 SM51 到操作系统层的指标映射2.1 为什么只盯 SM50 会漏掉真正的瓶颈刚入行时我习惯每天打开 SM50 看有没有长时间运行的进程后来发现这个动作只能抓到“已经卡死”的对话进程抓不到“正在变慢”的趋势。SAP 的 workload 分析ST03N里响应时间被拆成数据库时间、CPU 时间、GUI 时间等几块如果数据库时间占比持续上升而对话步骤数没变那问题大概率在数据库层不在应用层。我一般会先看 ST03N 的“工作负载分析”按小时聚合再对照 ST06 的 OS 监控看 CPU、内存、交换空间是否在同一个时间窗口出现拐点。这个映射关系建立起来之后你就能判断是该调 SAP 参数还是该找 DBA。2.2 一套可复现的最小巡检清单下面这个 bash 脚本是我在 Linux 上跑 SAP 时常用的巡检片段它不依赖 SAP 内部事务码直接从 OS 层抓关键指标适合放在 cron 里每 15 分钟跑一次输出到日志文件供事后回溯。#!/bin/bash # SAP BASIS 日常巡检 - OS 层指标采集 # 输出路径按实际环境修改 LOG_DIR/sapbasis/monitor/logs DATE$(date %Y%m%d_%H%M) OUTFILE${LOG_DIR}/sap_os_check_${DATE}.log { echo 时间: $(date) echo --- CPU 负载 (1/5/15分钟) --- uptime echo --- 内存与交换分区 --- free -m echo --- 磁盘使用率 (过滤 /sap 和 /oracle) --- df -h | grep -E /sap|/oracle|/usr/sap echo --- SAP 相关进程数 --- ps -ef | grep -E sapstartsrv|dispwork|gwrd|icman | grep -v grep | wc -l echo --- 最近 5 条系统错误日志 --- tail -n 5 /var/log/messages 2/dev/null || echo 无 /var/log/messages 读取权限 } ${OUTFILE} 21 # 保留最近 7 天日志 find ${LOG_DIR} -name sap_os_check_*.log -mtime 7 -delete这段脚本的逻辑很直接先记录时间戳然后依次抓 CPU 负载、内存、SAP 相关磁盘、关键进程数量和系统日志尾部。参数上free -m用 MB 为单位方便看交换分区是否被大量占用df -h过滤/sap和/oracle是因为这两个挂载点满了会直接导致 SAP 宕机进程数统计里dispwork是对话工作进程gwrd是网关icman是 ICM 进程数量异常减少说明实例可能已经部分挂掉。日志保留 7 天是经验值太短不够回溯太长占空间。2.3 把巡检结果和 SAP 事务码对上号OS 层数据拿到之后要回到 SAP 里验证。比如free -m显示交换分区使用超过 20%我就去 ST06 看 “Physical Memory” 和 “Swap Space” 的曲线再结合 SM04 看当前登录用户数是否突增。如果磁盘使用率超过 85%我会去 DB02 看表空间增长趋势而不是直接删日志。这个“OS 指标 → SAP 事务码 → 具体对象”的链路是 BASIS 日常运维里最值钱的部分因为它把“感觉慢”变成了“哪个资源在哪个时间点被谁吃掉了”。3. 传输请求管理STMS 里那些没人告诉你的操作顺序3.1 传输卡住时先查哪三个地方传输请求Transport Request是 BASIS 日常最高频的变更操作也是最容易翻车的地方。我遇到过最常见的三种卡住场景一是传输进程在 STMS 里显示“正在运行”但一直不结束二是导入到一半报 RC8 或 RC12三是目标系统里对象已存在导致导入被拒。排查顺序我固定为先看 STMS 的传输日志双击请求 → 日志确认是哪个步骤失败再去目标系统的/usr/sap/trans/log目录看SLOG和ALOG文件最后检查tp参数文件里目标系统的连接配置是否被改动过。3.2 用 STMS 命令行做批量导入的脚本模板图形界面点多了容易漏我一般把常用传输操作写成脚本用tp命令直接调。下面这个模板用于把指定请求导入到目标系统适合在维护窗口批量执行。#!/bin/bash # SAP 传输请求批量导入模板 # 使用前确认SID、请求号、目标系统 client 已替换 SAP_TRANS_DIR/usr/sap/trans SIDPRD # 目标系统 SID CLIENT100 # 目标 client REQ_LIST(PRDK900123 PRDK900124 PRDK900125) # 请求号列表 cd ${SAP_TRANS_DIR}/bin || exit 1 for REQ in ${REQ_LIST[]}; do echo 开始导入请求: ${REQ} 到 ${SID} client ${CLIENT} # -D 指定目标系统-c 指定 client-p 表示不等待确认 ./tp import ${REQ} ${SID} client${CLIENT} -D ${SID} -c ${CLIENT} -p RC$? if [ ${RC} -ne 0 ]; then echo 请求 ${REQ} 导入失败返回码: ${RC}请检查 SLOG # 失败时保留现场不继续后续请求 exit ${RC} fi echo 请求 ${REQ} 导入成功 done脚本里tp import是核心命令-D指定目标系统-c指定 client-p表示不交互确认。REQ_LIST数组里放请求号按顺序执行一旦某个请求返回非零就退出避免错误扩散。注意tp必须在/usr/sap/trans/bin目录下执行因为它依赖同目录的TPPARAM文件。如果目标系统是双栈ABAPJavaJava 部分的传输要用sapcontrol或 SDM不能混用这个脚本。3.3 传输请求的版本冲突怎么提前发现版本冲突是传输里最隐蔽的坑。两个请求改了同一个对象的不同版本先导入的会覆盖后导入的但 STMS 不会主动报错。我的习惯是在导入前用 SE01 或 SE09 看请求里的对象列表如果同一个对象出现在多个待导入请求里就先做一次“模拟导入”STMS 里勾选“测试运行”看日志里有没有“对象已存在版本不同”的警告。更稳妥的做法是维护一个简单的表格记录每个请求涉及的核心对象和修改人导入前人工比对。检查项工具/事务码判断标准请求是否已释放SE01 / SE09状态为“已释放”才能导入对象是否重复SE01 对象列表同一对象出现在多个请求需人工确认目标系统是否已有该对象STMS 测试运行日志无“版本冲突”警告传输路径是否可达STMS 概览目标系统状态为绿色4. 性能调优的边界哪些参数能动哪些动了会出事4.1 对话工作进程和内存参数的关系SAP 的性能调优不是“把参数调大就好”。以对话工作进程数rdisp/wp_no_dia为例调大它能提高并发处理能力但每个工作进程都会占用一块内存区域ztta/roll_area等如果物理内存不够反而会触发更多交换系统更慢。我一般先看 ST06 的物理内存使用率和交换分区活动再决定是否调整。如果物理内存使用率长期低于 70% 且交换分区几乎不动可以适当增加对话进程如果交换分区频繁读写优先加内存而不是调进程数。4.2 用 RZ11 动态查看和修改参数的注意事项RZ11 可以动态查看和修改部分参数但“动态生效”不等于“永久生效”。我见过有人用 RZ11 改了rdisp/max_wprun_time之后没写进配置文件重启后参数回退问题复现。正确做法是RZ11 里确认参数当前值和可修改范围修改后立即去 RZ10 或直接编辑实例参数文件把变更持久化。对于ztta/roll_area、abap/heap_area_total这类内存相关参数修改后要重启实例才完全生效不能只看 RZ11 的“已修改”提示。4.3 一个容易忽略的指标锁等待和更新进程性能问题不一定出在 CPU 或内存锁等待Lock Wait也会让用户感觉“系统卡了”。SM12 里看锁条目如果某个表被长时间锁定后续请求会排队。更新进程SM13如果堆积说明数据库更新跟不上可能是索引缺失或磁盘 I/O 瓶颈。我一般把 SM12 和 SM13 的检查频率设为每天两次发现异常锁条目先联系开发确认是否正常业务逻辑再决定是否手动删除锁。提示删除锁之前必须确认没有正在运行的更新任务否则会导致数据不一致。5. 避坑与常见问题那些年我踩过的 BASIS 运维坑5.1 现象用户被锁解锁后立刻又被锁原因不是密码错误而是用户设置了“多次登录失败锁定”但后台有个定时任务或接口在用旧密码反复尝试。解决先查 SM04 看该用户是否有异常会话再查 SM20 安全审计日志确认失败来源 IP最后要么改接口密码要么临时调大锁定阈值。5.2 现象STMS 导入成功但目标系统功能没变化原因请求导入到了错误的 client或者对象在目标系统被手动修改过导致版本不一致。解决核对请求日志里的 client 号用 SE03 检查对象版本必要时用 SCC1 在目标 client 里重新传输。5.3 现象系统突然变慢ST06 显示 CPU 不高但响应时间很长原因可能是数据库层的等待事件比如全表扫描或锁竞争。解决去 DB02 看 SQL 执行计划或者让 DBA 查数据库的等待事件视图。SAP 层的 ST04 也能看到部分数据库性能指标但深度分析要靠 DBA 工具。5.4 现象重启 SAP 后某个实例起不来日志报“共享内存不足”原因操作系统共享内存参数如kernel.shmmax被改动或者上次异常关闭后共享内存段没释放。解决用ipcs -m查看残留共享内存段确认无进程占用后用ipcrm清理再检查/etc/sysctl.conf里的内核参数是否和 SAP 安装文档一致。5.5 现象传输请求释放后无法导入报“请求已被锁定”原因另一个管理员正在修改同一个请求或者请求处于“修改中”状态未释放。解决SE01 里看请求状态如果是“修改中”联系修改人释放如果是锁定用 SM12 查锁条目确认后删除锁。6. 进阶技巧用 CCMS 和自定义告警把被动变主动6.1 CCMS 告警监控的配置路径SAP 自带的 CCMS计算中心管理系统能监控大量指标但默认配置往往只监控了很少一部分。我一般会进 RZ20展开“SAP CCMS Monitor Templates”把“Operating System”和“Database”下的关键监控项激活比如文件系统使用率、对话响应时间、更新进程队列长度。激活后设置阈值比如文件系统超过 90% 触发黄色告警超过 95% 触发红色告警。告警会进入 ALRTCATDEF 定义的接收人邮箱或外部系统。6.2 用 SM36 和 SM37 做自定义后台作业监控除了 CCMS我还会用 SM36 创建自定义后台作业定期检查特定表或接口的状态。比如每天凌晨跑一个作业检查前一天的 IDoc 处理是否有失败条目如果有就发邮件。作业步骤可以用 ABAP 报表也可以用外部脚本通过sapcontrol调用。SM37 里看作业日志如果作业失败日志会记录返回码和错误信息。6.3 一个具体的验证方法模拟故障看告警是否触发配置完告警后我会做一次模拟验证手动把一个非关键文件系统填到 91%看 CCMS 是否在预期时间内发出黄色告警。如果没触发检查 RZ20 的监控属性里“自动告警”是否勾选以及 ALRTCATDEF 里的接收人是否配置正确。这个验证步骤很多人跳过结果真出问题时才发现告警根本没发出去。监控项事务码建议阈值验证方式文件系统使用率RZ2090% 黄色 / 95% 红色手动填充测试文件对话响应时间ST03N超过 2 秒关注对比历史基线更新进程队列SM13超过 100 条关注模拟大批量更新锁条目数量SM12超过 50 条关注检查长事务我自己的习惯是每季度做一次告警演练把阈值临时调低确认整条链路从触发到通知都通畅。这个习惯帮我避免了好几次“以为有监控其实没通知”的尴尬。BASIS 日常运维做久了会发现最值钱的不是你会修多少故障而是你能让多少故障在发生前就被看见。希望帮到你。本文还有配套的精品资源点击获取