企业官网建设流程全解析

简介：这份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|disp+work|gwrd|icman" | grep -v grep | wc -l echo "--- 最近 5 条系统错误日志 ---" tail -n 5 /var/log/messages 2>/dev/null || echo "无 /var/log/messages 读取权限" } >> "${OUTFILE}" 2>&1 # 保留最近 7 天日志 find "${LOG_DIR}" -name "sap_os_check_*.log" -mtime +7 -delete

这段脚本的逻辑很直接：先记录时间戳，然后依次抓 CPU 负载、内存、SAP 相关磁盘、关键进程数量和系统日志尾部。参数上，free -m用 MB 为单位方便看交换分区是否被大量占用；df -h过滤/sap和/oracle是因为这两个挂载点满了会直接导致 SAP 宕机；进程数统计里disp+work是对话工作进程，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 里显示“正在运行”但一直不结束；二是导入到一半报 RC=8 或 RC=12；三是目标系统里对象已存在导致导入被拒。排查顺序我固定为：先看 STMS 的传输日志（双击请求 → 日志），确认是哪个步骤失败；再去目标系统的/usr/sap/trans/log目录看SLOG和ALOG文件；最后检查tp参数文件里目标系统的连接配置是否被改动过。

3.2 用 STMS 命令行做批量导入的脚本模板

图形界面点多了容易漏，我一般把常用传输操作写成脚本，用tp命令直接调。下面这个模板用于把指定请求导入到目标系统，适合在维护窗口批量执行。

#!/bin/bash # SAP 传输请求批量导入模板 # 使用前确认：SID、请求号、目标系统 client 已替换 SAP_TRANS_DIR="/usr/sap/trans" SID="PRD" # 目标系统 SID CLIENT="100" # 目标 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文件。如果目标系统是双栈（ABAP+Java），Java 部分的传输要用sapcontrol或 SDM，不能混用这个脚本。

3.3 传输请求的版本冲突怎么提前发现

版本冲突是传输里最隐蔽的坑。两个请求改了同一个对象的不同版本，先导入的会覆盖后导入的，但 STMS 不会主动报错。我的习惯是在导入前用 SE01 或 SE09 看请求里的对象列表，如果同一个对象出现在多个待导入请求里，就先做一次“模拟导入”（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 里的接收人是否配置正确。这个验证步骤很多人跳过，结果真出问题时才发现告警根本没发出去。

我自己的习惯是每季度做一次告警演练，把阈值临时调低，确认整条链路从触发到通知都通畅。这个习惯帮我避免了好几次“以为有监控其实没通知”的尴尬。BASIS 日常运维做久了会发现，最值钱的不是你会修多少故障，而是你能让多少故障在发生前就被看见。希望帮到你。

本文还有配套的精品资源，点击获取