★ FEATURED ARTICLE 简介这份资料是面向SAP系统管理员、Basis顾问及企业IT运维人员的日常操作速查手册聚焦用户权限、集团管理、数据库维护、后台作业、打印管理、系统监控与传输管理七大核心模块。内容出自科莱特内训材料逐一梳理了SU01用户维护、SU10批量改密、PFCG角色管理、SCC4集团配置、SCCL集团拷贝、DB13数据库维护日历、SM36/SM37后台作业定义与监控、SPAD/SP01打印设备与假脱机管理、ST06系统性能、SM50/SM51进程与服务器概览、SE09/STMS传输管理等高频事务代码的操作要点并补充了启动日志、进程日志、传输日志、数据库日志的常用排查路径帮助读者快速定位命令并规范日常巡检节奏。资源包仅包含1个PDF文档整体大小2.02MB内容精炼、便于移动端随时查阅。目前已有960人学习适合刚接触Basis的新手快速建立知识框架也适合资深运维人员作为案头速查清单避免遗漏关键监控项。1. SAP日常运维BASIS到底管什么从“救火”到“每日巡检”的转变如果你在生产系统SAP日常运维BASIS这个岗位上干过三个月一定明白我的意思业务顾问一打开窗口就催“传输请求怎么还没导进去”财务部门晚上跑余额结转的时候后台作业卡住数据库莫名其妙打不了备份。BASIS就是那个“所有麻烦都归你管”的角色它不直接处理业务数据而是维护SAP系统运行所需要的操作系统、数据库、应用服务器和传输链路。对新人而言BASIS常被误解为“修电脑”但真正决定你日常幸福感的是能不能把救火变成日常巡检每天早上用一套固定指标判断系统状态在业务用户还没察觉前就把风险按下去。这篇文章我会从巡检、传输、避坑、自动化四个维度把“做BASIS”这件事讲成可复现的步骤和参数而不是纯理论。2. 每日例行巡检从ST04到SM37的四个关键监控点与基线建议SAP系统报警往往滞后于业务体感。业务用户说“MD04/MD07慢得像蜗牛”的时候监控器大概率已经黄色几个小时了。我一般会把日常巡检分成四块系统级负载、数据库缓冲、后台作业、传输队列。下面每个小节先说明为什么看再给操作和参数这样你能直接套用到自己的环境里。2.1 系统级负载与数据库缓冲ST04、ST06和三条Linux命令ST06负责操作系统监控重点看CPU使用率、物理内存和文件系统使用率。如果CPU连续15分钟超过85%通常是应用层的SQL执行效率出了问题如果物理内存使用率持续95%且交换分区活跃要怀疑SAP共享内存参数不合理而不是急着加服务器内存。ST04负责数据库效率最值得每天看的是“Buffer Hit Ratio”也就是在数据库缓冲池里直接命中而非读取磁盘的百分比。低于85%说明数据库层的大量会话确实在排队这时候调应用服务器参数意义不大。我一般会用三条Linux命令快速确认系统层面状态操作比在SAP GUI里点更快uptime free -g df -huptime输出三个负载平均值最后十五分钟负载如果除以CPU核数大于1说明CPU已经有排队风险free -g里要同时看物理内存和Swap两行Swap长期有数值说明内存分配已经开始顶到操作系统边界df -h则是绕不开的常规动作尤其是/usr/sap/trans目录如果这个文件系统满了STMS传输队列会异常失败业务顾问还以为是传输请求本身的问题。如果不用GUI可以用SAP标准命令检查实例进程和文件系统sapcontrol -nr 00 -function GetProcessList sapcontrol -nr 00 -function GetFileSystem第一条命令查看实例内各进程是否都在PING状态第二条直接展示应用服务器所有挂载文件系统的使用率。输出里出现GRAY或DOWN时要小心但不要条件反射式地重启实例先确认是进程暂时无响应还是真的死了。盲目重启应用实例会把正在排队的事务一起打断这是很多BASIS新人踩过最疼的坑。日常巡检的基线可以参考这个表按你自己的系统容量上下调整监控项事务/命令基线参考行动建议CPU平均负载ST06 / uptime十五分钟负载 核数×1.2查慢SQL与后台任务物理内存ST06 / free -g使用率 90%检查EM参数与扩展内存传输目录空间AL11 / df -h使用率 85%清理日志和旧请求文件数据库缓冲命中率ST04长期 92%适当加大DB缓存上面四条里最容易出问题的不是CPU而是内存和文件系统。内存问题不是一天形成的你只需要每天记录一次看到趋势上扬就该提前调参文件系统问题则是“平时没事满了就翻车”尤其在每月末大批量传输时传输日志会瞬间吃掉大量空间。2.2 SM37后台作业看状态位而不是看业务时间后台作业是SAP日常运维里最容易被当成黑匣子的地方。业务顾问说的“作业没跑”多数不是没跑而是没按计划跑或者跑完后返回码不是0。打开SM37按服务器和状态搜索作业常见状态有S已计划、R运行中、F已完成、A已取消。我要你重点看两个维度计划开始时间与实际开始时间差多少以及结束后的返回码。如果计划时间与实际时间相差很远说明作业在等待后台工作进程。到SM61查看当前后台监视器经常看到Dialog和Background工作进程分配不均一个超长报表占满所有后台线程后面的批量任务全部排队。解决方式不是写ABAP而是调整实例进程配置。rdisp/wp_no_btc控制后台进程数rdisp/wp_no_dia控制会话进程数这两个参数在事务RZ10中调整调整后需要重启实例才能生效。注意盲目把后台进程加大会挤占对话进程资源业务用户操作会立刻变卡按CPU核数和内存预估一次只加一两个进程最稳妥。也可以用一条标准命令快速确认当前实例的工作进程分布sapcontrol -nr 00 -function GetWorkProcesses输出里“ProcessType BT”是后台任务“ProcessType DIA”是对话任务。如果BT一列全是“Waiting”说明后台进程过剩如果全是“Running”但队列还在堆积说明当前这类作业优先级低需要到SM69或SM36调整作业优先级。其实很多“慢”不是系统慢而是作业在后边排队只是没人看状态位而已。2.3 传输队列监控不用等业务来催SAP请求sap请求的导入队列也是每日巡检的一部分但很多团队只在导入报错时才打开STMS。我习惯每天花三分钟看一次导入队列状态。请求如果挂在“Packing”状态多半是控制文件没完整写入传输目录如果停在“Import in Progress”但日志很久没有新输出优先怀疑锁冲突而不是传输程序崩溃。实际操作上我经常登录应用服务器看一眼传输目录命令如下ls -l /usr/sap/trans/data | tail -20标准传输目录在/usr/sap/transdata存请求文件cofiles存控制文件。如果data里出现了新文件但STMS队列里看不到对应请求通常说明文件系统和STMS缓存不一致。这种状况下在STMS菜单里执行“Refresh Import Queue”或检查不一致的传输文件功能让系统自己找回队列。不要手动把文件拖进另一个目录那会把请求顺序搞乱恢复起来比当初导入失败更麻烦。2.4 备份恢复巡检没有恢复演练的备份等于没有备份备份是在SAP运维里最容易被“打钩”应付的一项。日常用事务DB13跑数据库备份看到日志最后一行为“Backup OK”就以为万事大吉。但真正考验备份的是恢复而不是写入所以我每季度都安排一次恢复到测试实例或临时目录确认数据库能通过一致性检查同时保留一个跨月时间点的全量备份以备业务部门提出数据追溯需求时能找得到对应恢复点。业务方说要“sap数据追溯”第一反应不是去导原始表而是先确认哪份备份覆盖了那个时间窗口。在我的巡检清单里备份这一项必须写清楚两件事昨天凌晨的备份文件是否成功写入磁盘以及上周是否做过一次恢复演练。测试恢复时要注意有些数据库实例恢复之后SAP应用层和数据库结构之间的用户授权会丢失需要在恢复脚本里额外处理。不要等到生产数据损坏再研究恢复那时候每一分钟都是钱。3. 传输请求管理STMS配置、导入顺序与缓存冲突排查传输请求管理是SAP日常运维BASIS里跟业务顾问打交道最多的工作因为所有开发成果都要靠它流转到测试和生产。它的本质是把开发环境内修改的对象通过SAP传输系统搬运到目标系统。这套机制看起来简单但配置不合理、导入顺序颠倒、请求缓存不同步的时候能消耗你一整天。下面按配置路由、导入顺序、缓存问题三个部分展开。3.1 配置传输路由STMS的首次绑定和系统组配置STMS之前先要理解传输域的概念。一个传输域就是一组共享配置的SAP系统通常由开发系统DEV作为域控制器测试QAS和生产PRD陆续加入。在DEV上运行事务STMS第一次会弹出“配置传输域”对话框选择“配置新的传输域”输入域名后确认。系统会在所有关联服务器上创建/usr/sap/trans目录结构这个目录就是传输文件的仓库。把QAS和PRD加进同一个域时登录目标系统继续运行STMS选择“加入现有传输域”输入DEV主机名和系统编号。加入失败常有三个原因主机名解析不通、端口被防火墙拦了、传输域密码不一致。这时候先别急着在SAP里重试用基本的网络命令验证ping dev_hostname telnet dev_hostname 22STMS的域通信依赖TP程序和RFC应用服务器之间的端口必须互通。常见翻车点是防火墙只放行了数据库端口忘了放行应用层传输端口。等域配置成功再进入传输域在“传输路由”页签里拖动图标建立DEV到QAS、QAS到PRD的路径。生产环境通常不设置从PRD再往下传所以路由方向是单向的。配置步骤归总如下步骤操作注意点建域DEV上STMS-配置新的传输域确认/usr/sap/trans创建成功加系统QAS/PRD上STMS-加入现有域先测试网络连通性配路由传输域-传输路由按DEV-QAS-PRD连线传输域配置完成后传输请求从SE10释放后会自动进入DEV的输出队列接着按照路由推送到下一系统。你不需要每天手工操作但路由配置错了请求就会发到错误的系统导致“改错了环境”的尴尬。3.2 导入顺序与依赖先导哪个才不会把队列搞乱一个传输请求Request通常包含多个任务Task任务之间可能存在依赖关系。系统导入请求时按内部顺序处理任务你不能只挑其中一个任务导入。如果请求A是准备工作请求B依赖A的结果那么必须等A完全导入成功才能触发B。STMS队列中会用箭头表示请求之间的依赖但这个依赖信息不一定百分之百准确遇到复杂需求时还是需要跟开发顾问确认。日常操作中我一般先看传输日志而不是凭感觉点导入。每台SAP系统的传输目录下都有日志文件命令如下ls -lt /usr/sap/trans/log | head -20 tail -f /usr/sap/trans/log/TRACE第一条命令按时间列出最近的传输日志第二条实时追踪当前导入活动。如果看到请求B在请求A之前被导入了但后续请求报错说明顺序已经被破坏。这时要不要立刻回滚B我的经验是别急着回滚先确认A的对象是否已经存在于目标系统。如果A只是建了一张空表B导入时依赖的是表结构那B照样能成功。真正的风险是A里的后续内容还会被导入导致B引用到旧数据这种情况需要跟业务顾问一起核对。传输到一半卡住时先通过sapcontrol -nr 00 -function GetProcessList确认工作进程是否停在“Rollback”状态再去STMS看该请求的日志。如果日志里出现“Object locked”优先怀疑有人锁定对象。事务SM12可以查看锁表情况联系持有锁的用户释放即可不要自作主张把锁删掉否则目标系统里会出现对象版本错乱的遗留问题。3.3 请求缓存不同步导入成功的对象在目标系统看不到新功能这是最让新人摸不着头脑的问题。STMS里请求状态明明是“Done”但业务顾问在目标系统测试时看到的还是旧界面、旧功能。第一种可能是传输根本没有覆盖对象第二种可能是应用服务器的对象缓存没有刷新。第一种先通过SE03查看对象目录表确认该对象在目标系统里的“对象目录条目”和“请求版本”已经改变。如果没变说明导入逻辑失败了需要回到STMS日志找原因。如果版本确实变了但系统运行时还是旧代码那就是缓存问题。SAP ABAP对象在应用服务器上会被缓存导入后系统应当自动使旧缓存失效。但某些场景下尤其是跨版本或使用外部传输工具时缓存不会自动刷新。标准做法之一是在目标系统执行事务SE14激活相关表缓冲器影响面较大时要谨慎。另一个最直接的办法是重启应用实例让缓存彻底清空。这个方法虽然看起来粗暴但在生产环境深夜做一次实例滚动重启往往比纠结十多个缓存参数更省心。另外传输请求的cofiles控制文件是否正常也很关键wc -l /usr/sap/trans/cofiles/请求号.*如果控制文件是空的或缺失系统即使导入了数据文件也无法正确识别对象列表。出现这种情况时需要回源系统重新释放请求生成新的cofiles而不是手工补文件。传输请求的“缓存不同步”问题说到底就是开发环境、目标环境和应用服务器三方状态不一致排查优先级应该是先对象目录再传输日志最后才轮到缓存和重启。4. BASIS运维避坑指南我踩过的5个典型问题以下这些坑不是从手册抄的是过去几年在多个生产环境里踩出来的。每一条按现象、原因、解决三步写方便你直接对照。4.1 SM21日志疯狂刷消息错把警告当错误现象凌晨收到SM21报警日志里大量“Unable to allocate memory”类似文字看起来像系统崩溃的前兆。登入ST06一看物理内存明明还剩十几GB。原因ABAP应用服务器的扩展内存或Java VM在回收内存时会有瞬时提示日志级别可能是“警告”但并不代表真的发生OOM。真正的OOM通常会伴随系统响应异常或进程退出。解决把这类消息在RZ20监控集中降级或调整告警阈值只在内存使用率连续超过阈值时通知你。不要一看到内存消息就重启实例那样反而把正常服务的会话中断。我见过有人半夜被日志吓得反复重启第二天发现业务高峰时段系统反而更不稳定这就是不区分日志级别的后果。4.2 STMS请求导入失败提示对象被锁定现象在STMS导入队列点执行几分钟后请求标红日志显示“Object locked by user”。原因一位开发者在SE80中打开了同一个类或程序且没有释放锁定或者SE03中残留了对象锁条目。传输请求导入时需要短暂锁住目标对象锁被业务端的开发会话占用就会失败。解决先到SM12查看对象锁确认锁的请求、用户和时间。如果是正在开发的正常锁让该开发顾问在SE80中释放或直接关闭编辑窗口如果已经无人在线可以通过SM12的删除功能清理残留锁。不要直接到数据库表删除锁条目否则开发端对象版本会变得不可控等下次激活时可能把一个未完成状态的开发对象写进传输请求。4.3 内存不足还是交换区不足看AL12的内存分配现象ST06显示内存使用率到99%但业务用户反馈系统并没有明显变慢ST04缓冲命中率也正常。原因SAP实例在操作系统上的共享内存分配参数设置不合理。比如em/initial_size_MB配置过小导致实例虚拟地址空间受限看起来“内存不足”实际只是地址空间紧张。解决在RZ10中调整em/initial_size_MB常见做法是先从当前值增加一倍试运行。修改后需要重启实例才能生效。注意不要一次调到物理内存上限SAP扩展内存和数据库共享缓存之间存在互补调得太大反而挤压其他进程。这个调参过程需要保留运行记录调完观察两天再决定是否继续加大。4.4 SAP GUI连接慢或掉线不是网络问题而是服务超时现象用户反映SAP GUI间歇性掉线重连很快但一天发生多次。网络团队测试后表示没有丢包延迟也很低。原因SAP Router或负载均衡器对空闲连接设置了较短的超时时间SAP GUI在空闲状态下没有持续心跳连接被网络层强制断开。也可能应用服务器对话进程已经占满新连接连不上。解决先把负载均衡器和任意中间设备的心跳超时调到30分钟以上再把GUI客户端“保持连接”的选项打开。如果掉线频繁发生在特定时间点用ST03N看该时段的对话响应对比确认是否并发高导致进程耗尽。这个坑往往同时有网络和应用两层因素不要只听网络团队说“没问题”。4.5 系统时间与数据库时间不一致后台作业提前或延迟现象后台作业计划在凌晨00:00执行但日志显示的系统时间与业务时间差了十几分钟。有时候事务代码或数据库导入还会出现时间格式相关报错。原因应用服务器与数据库服务器没有配置统一的时间同步时区设置不一致时间漂移后在关键时刻影响作业启动和日志对账。解决所有SAP服务器统一启用NTP同步。Linux下常见命令如下systemctl enable chronyd chronyc makestep配置后重启SAP实例然后每周巡检时检查一次各服务器时间偏差。时间不一致是很多“灵异事件”的源头小到作业乱序大到数据备份文件时间戳混乱解决了它你会发现半夜电话少一半。5. 把每日巡检变成自动脚本一条告警少烦我两小时5.1 用Python脚本替代第一道巡检上面章节里的手工巡检完全可以被“每小时自动执行一次”的轻量脚本替代。我不会用一套重型监控平台而是先写一个能直接抓取实例状态的脚本。以下脚本用Python调用sapcontrol读取进程列表并判断异常#!/usr/bin/env python3 import subprocess, sys, datetime inst sys.argv[1] if len(sys.argv) 1 else 00 def run_cmd(cmd): result subprocess.run(cmd, shellTrue, capture_outputTrue, textTrue) return result.stdout proc_list run_cmd(fsapcontrol -nr {inst} -function GetProcessList) if GRAY in proc_list or DOWN in proc_list: print(datetime.datetime.now(), PROC_DOWN) # 在这里接入公司告警平台的 webhook例如钉钉/企业微信机器人 else: print(datetime.datetime.now(), OK, inst)脚本逻辑很直白执行sapcontrol的单实例命令如果输出中出现了GRAY或DOWN就打印异常并触发后续告警动作。这个脚本的好处是不依赖SAP GUI纯操作系统环境就能运行。你可以把脚本分发到所有应用服务器用Ansible之类的自动化运维工具统一管理会比手工登录服务器效率高很多。5.2 验证脚本与告警去重脚本写完后第一件要做的事不是直接接告警而是验证它真的能识别异常。先在一台不影响业务的沙箱实例上执行确认输出OK再手动停掉一个应用实例确认脚本输出PROC_DOWN。如果第一步就误报别急着调先搞清sapcontrol命令本身返回格式是否被脚本正确读取。把脚本写入crontab每5分钟跑一次*/5 * * * * /home/sapadm/check_proc.py 00 /tmp/check_proc.log 21注意加日志重定向否则脚本出错时你查不到原因。告警侧要做去重同一个实例连续三次检测DOWN才触发电话通知避免网络抖动造成误呼。以前我用商业监控软件配置了一大堆SAP监控项后来发现真正拿到半夜两三点打开笔记本的还是这种10行脚本打出来的准确日志。这不一定适合所有公司但如果你刚接管一套SAP系统建议从这个小脚本开始逐步建立自己的运维基线。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
