Python机器学习滑坡易发性制图：从样本构建到成果分级的全流程实践
2026/10/14 6:12:55
简介：面向SAP系统管理员与运维人员的Basis知识整理，围绕用户权限、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理及重要日志查看等核心模块展开。资源共1个PDF文件，大小2.02MB，内容源自科莱特SAP内训，系统梳理了日常运维常用事务代码，例如SU01/SU10/PFCG管理用户与角色，SCC4/SCCL维护集团，DB13/DB02/DB12负责数据库备份与监控，SM36/SM37管理后台作业，ST06/ST03/SM50监控系统状态，SPAD/SP01处理打印问题，以及SE09/STMS管理传输请求。同时包含SAP BASIS学习路径与方法、权限与数据安全意识、日志路径等实践经验，并附录数据库备份还原要点，便于运维人员快速查阅、对照操作。已有962人学习，适合刚接触SAP BASIS的新手及需要日常运维查漏补缺的顾问。
1. 为什么说 BASIS 日常运维是 SAP 系统的“守门员”
清晨的第一通电话往往最刺耳：用户说登录卡在“正在连接数据库”，开发说批处理跑着跑着就停了，业务说昨晚的报表没出数。回头看控制台，AL08 里的空闲会话堆成山，ST02 的缓冲区命中率连续三天飘红，SM37 里躺着两个 Canceled 的作业——这些问题不是同一天发生的，却往往在同一天集体爆发。SAP 日常运维 BASIS，通俗讲就是给 SAP 系统当守门员：监控实例状态、打理后台作业、管理补丁升级、处理 Client 和传输请求，确保业务人员睁眼时系统是正常的。这篇文章写给刚接手 SAP 系统管理的运维，写给从 ABAP 开发转 BASIS 的人，也写给甲方信息部门里被“系统慢”三个字反复折磨的人。我会按日常运维的真实顺序，先把要看的事务代码讲透，再讲补丁和传输这两个高危动作，最后把最常见的五个坑逐个拆开。
2. 系统监控的常规动作：用事务代码盯住五个关键指标
日常巡检不是每天登录系统里东点一下西点一下，而是有一套固定的“读数顺序”。我习惯把监控分成三块：用户与会话、工作进程与内存、后台作业。这三块出问题，用户感知最快，也最容易在早晨集中爆发。下面按这三块讲清楚每个事务代码看什么、什么数据要警觉。
2.1 用户与会话监控：AL08 与 SM04 怎么配合读
AL08 显示的是整个 SAP 系统中所有应用服务器上的用户会话列表，SM04 只显示当前登录的这台应用服务器。很多刚转 BASIS 的人分不清这两个代码的区别，其实它们的关系就是“全区”和“本地”的关系。
日常看 AL08 时，我重点关注三列：会话类型、会话状态、空闲时间。会话类型分为 Dialog（对话框）、Background（后台）、Update（更新）、HTTP（Web 请求）等。Dialog 会话太多，说明在线用户活跃；Background 会话过多，说明后台作业堆积。再看会话状态，如果大量会话停在 Running 但不产生系统负载，多半是界面锁死或者程序在等待数据库锁。
空闲会话是另一个隐蔽问题。用户在客户端开了多个窗口不关，或者前端连接异常断开但会话没释放，日积月累会占用许可证和工作进程。我们曾有一个系统每到月底就报“用户许可证不足”，查了半个月，最后发现是两百多个空闲会话挂在每晚跑批的终端机上。
SM04 的价值在于踢会话前先看细节。双击一个会话，能看到用户当前执行的事务代码、登录时间、更新时间。如果确认是僵尸会话，在 SM04 里选中右键“结束会话”即可。需要注意：踢会话前看更新模式，踢掉处于 Update 状态的会话可能造成数据库回滚，生产系统谨慎操作。
2.2 工作进程与内存水位：ST02、ST06 的参数边界
工作进程是 SAP 处理请求的“工人”，内存是工人干活的地方。ST02 看 SAP 缓冲区质量，ST06 看操作系统层面的 CPU 和内存水位，两个代码配合起来才能判断系统是“假慢”还是“真忙”。
打开 ST02 后，看各缓冲区的命中率。命中率长期低于 85%，说明缓冲区太小，频繁从数据库重新读数据。特别是 Program Buffer（程序缓冲区）和 Table Buffer（表缓冲区），这两个区域命中率低，直接表现为用户操作卡顿。
ST02 里还要看交换区（Swap）和私有内存请求。如果“Private Memory”相关数值频繁增长，往往是 ABAP 程序申请内存后不释放。这时候光加内存是没用的，要找到是哪个程序在“吃”内存。常见做法是通过 ST05 做 SQL 跟踪，或者让开发用 ABAP 内存表检查工具定位大内存消耗点。
ST06 则直接看主机层。CPU 使用率超过 80% 持续 10 分钟以上，要考虑是否有异常批处理或者报表在跑全表扫描。内存使用率接近上限时，最先受影响的是对话进程，表现为用户登录变慢、新建会话失败。这里需要关注几个核心参数：
| 参数 | 所在参数文件 | 作用 | 日常关注点 |
|---|---|---|---|
| rdisp/wp_no_dia | 实例参数 | 对话进程数 | 太少会排队，太多会占内存 |
| rdisp/wp_no_btc | 实例参数 | 后台进程数 | 作业高峰时段是否被打满 |
| rdisp/max_priv_reqs | 实例参数 | 私有内存请求上限 | 频繁超限需要调大或用内存管理优化 |
| abap/heap_area_dia | 默认参数 | 对话进程堆内存上限 | 大报表处理时是否出现内存崩溃 |
用sapcontrol命令行也能快速检查实例进程状态，适合写进巡检脚本：
#!/bin/bash # 实例号，通常为 00 或 01，按实际系统修改 NR=00 # sapcontrol 完整路径，不同版本安装路径可能不同 SC="/usr/sap/hostctrl/exe/sapcontrol" # 获取当前主机上该实例的所有进程状态并写入临时文件 $SC -nr $NR -function GetProcessList > /tmp/sap_proc_$NR.log # 过滤输出：跳过表头，提取进程名和状态列 awk 'NR>1 && $1!="Hostname" {print $2, $4}' /tmp/sap_proc_$NR.log # 如果存在非 Running 状态的进程，输出提示 grep -E "Stopped|Error" /tmp/sap_proc_$NR.log && echo "实例 $NR 存在异常进程"GetProcessList 是 sapcontrol 的标准函数，返回该实例下所有工作进程和关键服务的状态。第一次执行时建议先原样输出日志，确认字段分隔位置再套 awk，因为不同 SAP 版本的输出列序有差异。-nr后面的数字就是实例号，多实例服务器上每个实例要单独跑一次。
2.3 后台作业健康检查：SM37 里哪些状态要当天处理
后台作业是 SAP 系统里最容易“默默死掉”的部分。SM37 按作业名、用户、状态筛选作业列表，日常巡检我只看三个状态：Canceled、Running、Released。
Canceled 的作业必须当天处理。常见原因有程序异常、数据库锁、授权变更导致作业用户失效。查看作业日志用事务代码 SP01，里面有具体的错误行。如果错误指向权限问题，先确认执行作业的用户是否被改过角色；如果是程序 dump，把 ABAP 短文本转给开发。
Running 状态的作业要看“是否超时”。一个每晚跑两小时的报表，白天突然跑了六个小时还没结束，就是异常。找到该作业的进程号，在 SM50 里看它占用的工作进程，必要时用 SM50 结束该进程。注意结束进程不等于杀掉作业，作业可能再次自动重启；正确做法是先在 SM37 里把作业置为“已释放”状态，再结束进程。
Released 状态表明作业已经调度但还没被后台进程拾取。如果业务说“作业提交了但没跑”，多半卡在这一环。查看 SAP 后台进程是否被大作业占满，用 SM37 按开始时间排序，看看前面是否堆了十几个等待中的作业。
习惯上我会每天早、中、晚各看一次 SM37，每次重点筛选“昨天 18:00 到今天 08:00 之间失败”的作业。夜里跑批失败的作业，早上如果不处理，白天用户的报表就是缺失数据。这个巡检动作不难，但坚持做下来能躲掉大部分“早上被电话叫醒”的尴尬。
3. 支持栈升级与补丁管理：SPAM/SAINT 的最小操作闭环
给 SAP 系统打补丁是 BASIS 日常运维里风险最高的动作之一。很多运维对补丁又爱又怕：不打，系统长期处于已知问题未修复的状态；打，又怕升级过程中哪一步错了导致整个系统不可用。其实补丁管理有一套固定流程，按闭环走，风险可控。
3.1 升级前的三件事：读说明、做备份、留回退路
第一件事是读支持包说明。SAP 的补丁包在发布时会附带说明文档，里面写清楚这个补丁解决了哪些问题、是否依赖其他组件、是否会引入数据字典变更。跳过这一步直接打补丁，等于把黑匣子直接塞进系统。
第二件事是完整备份。数据库备份必须做到可与恢复验证，文件系统备份要覆盖 SAP 执行目录和全局目录。常见做法是：数据库用备份工具做一致性备份，同时用系统命令拷贝关键配置目录。备份完成后，建议在测试机上做个快速恢复演练，确认备份文件不是“看着大其实读不出来”的摆设。
第三件事是留回退路。补丁导入一半失败时，最稳妥的回退方式是恢复上一次完整备份。所以备份的保留时间不能只留一天，至少保留到补丁导入后稳定运行一周。我们曾因为旧备份被清理得太快，补丁出问题时只能硬着头皮继续往前冲，那种感觉非常不好受。
3.2 SPAM 更新与 SAINT 队列：按顺序执行支撑包导入
SAP 补丁导入依赖两个事务代码：SPAM 管理支持包本身，SAINT 管理 Add-On 和组件补丁。导入前先确认 SPAM 自身的版本够新，SPAM 太旧会拒绝导入新的支持包。
操作顺序通常如下：
| 阶段 | 操作 | 关键注意点 |
|---|---|---|
| 导入前 | SPAM 事务中加载新的 SPAM 包 | 这一步不能用 SAINT，必须先更新 SPAM 自身 |
| 准备补丁 | SAINT 中进入 Support Package 菜单，加载补丁文件 | 确认补丁存放路径的读取权限，路径里有中文或空格容易读失败 |
| 生成队列 | 系统自动按组件依赖关系生成导入队列 | 不要手工调整队列顺序，依赖关系错了后面必出问题 |
| 执行导入 | 按队列顺序逐个导入 | 系统提示重启时先等一下，确认所有队列走完再重启 |
| 激活 | 导入完成后执行激活步骤 | 激活期间通常停机，安排好业务窗口 |
SAINT 执行过程中最常见的翻车点是补丁文件不完整。下载中断、解压不完整都会导致导入时报文件缺失。遇到这种情况，先删除已加载的补丁列表，重新上传完整的补丁包再试。不要抱着侥幸心理只导入提示缺失的那一个文件，组件之间的依赖经常比想象中复杂。
3.3 补丁后的验证清单：从系统版本到关键事务代码
补丁导入完成不代表事情结束，验证才是收尾。我习惯按下面的清单逐项走：
| 验证项 | 操作方法 | 通过标准 |
|---|---|---|
| 组件版本 | 在 SAINT 中查看已导入补丁队列 | 所有目标补丁显示“已导入”状态 |
| 系统可登录 | 用对话框用户登录系统 | 登录过程无报错、无卡顿 |
| 关键事务代码 | 打开日常业务最常用的几个事务代码 | 能正常进入主界面 |
| 后台作业调度 | SM37 中释放一个测试作业并观察运行 | 作业状态变为 Finished |
| 授权检查 | 用业务用户的角色执行代表性操作 | 无新的权限报错 |
补丁后最容易漏掉的是权限验证。某些补丁会调整授权对象，角色没重新生成，用户就会突然报“无权执行”。这时用事务代码 SU25 或 PFCG 批量比对角色授权数据，按系统建议重新生成。
验证过程中如果发现异常，优先查看补丁导入日志和系统短文本，不要立刻重启系统。短文本里通常写明了是程序问题、数据库问题还是数据问题，直接重启只会把问题掩盖，等到下次更高峰时加倍爆发。
4. Client 管理与传输管理：两个最容易“翻车”的领域
Client 是 SAP 系统里的隔离单位，传输请求是代码和数据从一个系统搬到另一个系统的通道。这两个领域看似功能不同，日常运维中踩的坑却有共性：操作前没想清楚影响范围，操作中缺少验证，操作后没有回退方案。
4.1 Client Copy 的选型：本地复制还是远程导入
Client Copy 用于在系统内部复制或跨系统复制一个 Client 的数据。常见需求包括：为测试准备一套干净的配置数据、把生产配置同步到测试系统、新建一个培训 Client。
先看本系统复制，事务代码是 SCCL。它支持逻辑复制和物理复制两种模式。物理复制速度快但会覆盖目标 Client 的所有数据，逻辑复制可以按表类选数据，更精细。日常运维建议优先用逻辑复制，特别是目标 Client 里还有其他团队在用的数据时，物理复制会把别人一起“清空”。
跨系统复制用 SCC9 远程导入，操作比本地复制多一步：要在源系统和目标系统之间配置 RFC 连接，确保网络权限开放。跨系统复制前，确认源系统与目标系统的 SAP 版本兼容；版本差异过大，表结构不一致，复制过程会出现字段截断或转换错误。
| 复制方式 | 事务代码 | 适用场景 | 注意事项 |
|---|---|---|---|
| 本地物理复制 | SCCL | 新建空白 Client | 会覆盖目标 Client 全部数据 |
| 本地逻辑复制 | SCCL | 按表类选择复制、保留目标数据 | 速度较慢，适合数据量不大 |
| 远程复制 | SCC9 | 跨系统同步 | 需要先配好 RFC 目标 |
| Client 导出/导入 | SCC1/SCC3 | 离线迁移 | 文件传输，务必核对表选择范围 |
复制完成后别急着交付。用 SCC3 看复制日志，确认没有大量失败记录；再用几个关键事务代码登录测试，验证权限和配置。特别提醒：Client Copy 不会自动处理密码策略和用户锁定状态，这部分在下一章避坑里展开。
4.2 传输请求的释放与导入：STMS 队列怎么排查
传输请求的完整链路是：开发在 SE09/SE10 中创建请求，保存对象；释放请求后，文件传入传输目录；STMS 负责把请求从开发系统传到测试系统、生产系统。
日常运维中，传输请求最常见的故障是导入队列卡住。打开 STMS，如果某个请求状态显示红色，先看它的依赖请求是否已经成功导入。SAP 的请求之间经常存在逻辑依赖，前一个没导完，后一个无论怎么处理都会失败。
另一种常见情况：传输请求释放后找不到文件。查看操作系统传输目录中是否生成对应的 CO 文件和 DATA 文件，如果只有 CO 文件没有 DATA 文件，通常是请求释放不完整，或者文件被外部程序清理。此时需要开发人员检查请求内容，必要时重新释放。
处理卡住的队列时，不要一上来就删除请求。正确顺序是：先用 SE03 查看请求对象是否存在“不可修改标志”，比如对象被锁或处于修复状态；再检查目标系统的时间戳是否比开发系统新，时间戳冲突会导致“对象较新”的报错。逐个排除后，再决定是重复导入还是调整请求状态。
4.3 开发与生产的边界：CTS 配置里的权限规范
传输管理不只是技术问题，更是协作规范问题。很多系统出乱子，不是因为技术不会操作，而是因为谁都能释放请求、谁都能在生产系统上直接改东西。
CTS（Change and Transport System）的正确配置是：开发系统作为源，配置好传输域，目标是测试和生产系统。STMS 中要走标准的开发→测试→生产路径，不要从开发直接跳过测试导入生产。跳过测试意味着生产收到的代码完全没经过验证，等于把风险直接暴露给业务。
权限上，建议只给 BASIS 人员开放生产系统的 STMS 导入权限，开发人员只能释放请求，不能直接在生产系统上修改对象。生产系统的 SAP 默认不开放对象编辑器，但有些系统为了应急开了调试权限，这种临时口子应该在维护窗口关闭后立刻收回。
我见过一个团队，因为某个顾问急着上线 demo，绕过 STMS 直接在测试系统上用 SE03 修改了请求状态，把开发系统中的对象标记为“已传输”。结果后续真正的代码传输全部告警，只能逐个对象比对还原，前后折腾了一周。传输这条路，规范就是后悔药；省掉的几步，后面全部加倍还回去。
5. SAP 日常运维避坑指南：五个让系统“沉默崩溃”的问题
系统出大故障之前，往往有漫长的前兆期，只是没人留意。以下五个问题是日常运维中反复出现的高频坑，每一条都是“看着小、炸起来狠”的典型。每个坑按现象、原因、解决三步说清。
5.1 现象：用户登录被卡在“正在连接数据库”
某天上午，陆续有用户反映登录时一直停在“正在连接数据库”，等了很久才能进系统，有的直接被系统退出。检查 AL08，发现大量会话堆积；打开数据库监控，数据库连接池已经满了，新的连接请求全部排队。
原因：数据库连接池参数设置过小，加上某个后台报表在全表扫描，长时间占用连接不释放。连接池满了之后，所有正常业务连接都被挡住。
解决：先在数据库监控中定位长时间运行的 SQL 语句，与开发确认是否是异常报表，必要时杀掉这个会话。同时调整连接池上限，并设置连接使用率告警。这类问题事后一定要复盘：为什么报表会跑全表扫描？是不是索引失效或者统计信息过期？只调大连接池参数，问题会在数据量再涨时卷土重来。
5.2 现象：后台作业显示 Finished 但业务数据没动
早晨业务人员反馈：昨晚的结算批处理显示成功，但今天所有销售订单都没结算。SM37 里看到作业状态是 Finished，再看作业日志，返回码也是 0。
原因：作业执行了，但程序内部按条件判断找到了空数据集，直接走完逻辑就结束了。程序返回码是 0，因为它本身没有报错，只是没有处理任何数据。这是最典型的“假成功”。
解决：让开发人员在作业里加入处理条数日志，并落写入应用日志；如果处理行数为 0，返回非 0 状态码或者发警告消息。运维侧在 SM37 巡检时，不能只看作业状态，要定期抽看几个关键作业的日志输出，确认“数量不为空”才是真成功。
5.3 现象：生产打补丁后程序报错，开发环境正常
生产系统导入某个支持包后，业务反馈报销审批单打不开，报错信息显示某个函数模块组件版本不对。在开发环境测试同样程序完全正常，问题只出现在生产。
原因：补丁导入队列没有完整执行。开发环境的补丁队列是按依赖顺序完整导入的，生产环境导入时被人为跳过了一个前置补丁，导致程序调用的新函数模块在开发环境存在、生产环境却缺失。
解决：在 SAINT 中对比两个系统的组件支持包版本，找出生产环境缺失的补丁，按依赖顺序重新生成队列并导入。这告诉我们一个血的教训：补丁队列不要手工“挑着打”，系统生成的依赖顺序是最低安全线。省掉的补丁不会省事，只会在下一个环节变成故障。
5.4 现象：Client Copy 完成后密码策略失效
新建了一个培训用 Client，用 SCCL 复制完生产数据后，用户登录时发现密码复杂度校验失效，连续输错多次也不会锁，有效期也被跳过。
原因：密码策略相关的参数和 USR40 表规则没有随 Client 复制完整迁移。Client Copy 复制的是业务数据和部分配置，但像 USR40 这类安全配置，在不同 Client 中可能独立存放，复制操作不会自动同步到新 Client。
解决：复制完成后，立即检查新 Client 的密码策略。用事务代码 USR40 查看非法密码表，用 SLCB 或参数文件检查密码有效期设置。如果是频繁新建 Client，建议把密码策略配置做成一键初始化脚本，每次复制后自动执行一遍。
5.5 现象：传输请求导入失败并卡死整个队列
STMS 队列里，某条传输请求状态变红，后面的请求全部进入“等待”状态。开发人员说这个请求其实已经修复过，希望直接跳过。
原因：前一条请求中存在被修改后回滚的对象，目标系统时间戳比源系统新，系统判定为“覆盖会丢失内容”，因此拒绝导入。如果强行把后一条请求标为已导入，后面所有依赖这个对象的程序都会在运行时报版本冲突。
解决：先用 SE03 检查队列中请求对象的状态，确认冲突对象；必要时请开发打开源系统目标对象，比对版本差异。跟踪到底，找到冲突根源后，重新释放请求、一起导入。跳过队列解决不了冲突，只会把冲突更深地埋进系统。
6. 进阶：把每日巡检脚本化的三个抓手
监控动作如果只靠人肉登录系统，每天花 40 分钟是常态，还容易漏。把巡检脚本化之后，我每天只需要打开一封邮件，就能看到所有实例的状态汇总。这里分享三个投入产出比最高的抓手。
6.1 用 sapcontrol 把实例状态落成日志
sapcontrol是 SAP 实例自带的命令行管理工具，不需要额外安装。用 Python 封装它，可以把实例进程状态、启动状态收集到本地日志，再交给定时任务执行：
import subprocess from datetime import datetime def check_instance(nr: str) -> str: cmd = ["/usr/sap/hostctrl/exe/sapcontrol", "-nr", nr, "-function", "GetProcessList"] result = subprocess.run(cmd, capture_output=True, text=True, timeout=30) return result.stdout if result.returncode == 0 else f"调用失败: {result.stderr}" def main(): log_path = "/tmp/sap_daily_check.log" with open(log_path, "a", encoding="utf-8") as f: f.write(f"\n[{datetime.now()}] 实例 00 检查开始\n") f.write(check_instance("00")) f.write("[实例 00] 检查结束\n") if __name__ == "__main__": main()capture_output=True用来捕获命令的标准输出，timeout=30防止 sapcontrol 本身卡死导致脚本挂起。脚本可以先在本地手工跑一次，确认输出内容符合预期，再挂到 crontab：0 7 * * * /usr/bin/python3 /home/sapadm/check.py。实际项目中很多团队还会把输出解析后接入消息平台，异常时推送到值班群。
6.2 把作业监控挂到系统消息里，不靠人工盯屏
SM37 的作业状态可以通过 CCMS 监控树挂到系统消息里，配置好后，作业失败自动触发告警消息。这一步配置一次，长期受益。
在 RZ20 中建立监控树，把关键作业节点挂上去，设置告警阈值；作业失败时，消息会推送到配置的运维组邮箱。如果企业内部有统一告警入口，也可以通过外部脚本读取作业日志后转发。
回看这些做法，早期做 SAP 系统管理时，我总以为多盯屏幕就能少出事，结果是人累、事多、漏看。后来把会话数、内存水位、作业状态全部脚本化，每天早晨看一份自动生成的巡检报告，有问题早上一起来就能看到，值班电话真的少了大半。系统管理不是拼谁盯得久，而是拼谁把重复劳动尽早自动化。希望这些经验和坑能帮你在 SAP 日常运维这条路上少绕一些弯。
本文还有配套的精品资源，点击获取