简介面向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更新、HTTPWeb 请求等。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按实际系统修改 NR00 # sapcontrol 完整路径不同版本安装路径可能不同 SC/usr/sap/hostctrl/exe/sapcontrol # 获取当前主机上该实例的所有进程状态并写入临时文件 $SC -nr $NR -function GetProcessList /tmp/sap_proc_$NR.log # 过滤输出跳过表头提取进程名和状态列 awk NR1 $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 配置里的权限规范传输管理不只是技术问题更是协作规范问题。很多系统出乱子不是因为技术不会操作而是因为谁都能释放请求、谁都能在生产系统上直接改东西。CTSChange 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_outputTrue, textTrue, timeout30) 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, encodingutf-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_outputTrue用来捕获命令的标准输出timeout30防止 sapcontrol 本身卡死导致脚本挂起。脚本可以先在本地手工跑一次确认输出内容符合预期再挂到 crontab0 7 * * * /usr/bin/python3 /home/sapadm/check.py。实际项目中很多团队还会把输出解析后接入消息平台异常时推送到值班群。6.2 把作业监控挂到系统消息里不靠人工盯屏SM37 的作业状态可以通过 CCMS 监控树挂到系统消息里配置好后作业失败自动触发告警消息。这一步配置一次长期受益。在 RZ20 中建立监控树把关键作业节点挂上去设置告警阈值作业失败时消息会推送到配置的运维组邮箱。如果企业内部有统一告警入口也可以通过外部脚本读取作业日志后转发。回看这些做法早期做 SAP 系统管理时我总以为多盯屏幕就能少出事结果是人累、事多、漏看。后来把会话数、内存水位、作业状态全部脚本化每天早晨看一份自动生成的巡检报告有问题早上一起来就能看到值班电话真的少了大半。系统管理不是拼谁盯得久而是拼谁把重复劳动尽早自动化。希望这些经验和坑能帮你在 SAP 日常运维这条路上少绕一些弯。本文还有配套的精品资源点击获取