简介面向SAP系统管理员及运维人员的BASIS内训PDF系统梳理日常运维的核心职责与常用操作命令。内容以事务代码为主线完整覆盖用户权限管理SU01、PFCG、SU53、集团管理SCC4、SCCL、SCC3、数据库管理DB13、DB02、DB12、后台作业SM36、SM37、打印管理SPAD、SP01、系统监控ST06、ST03、SM50、SM21及传输管理SE09、STMS等模块。另附启动日志、进程日志等关键日志查看路径并讲解如何学好Basis的方法适合日常巡检和排错参考。压缩包内为单个PDF文件大小约2.02MB。已有962人学习适合刚入门或希望系统化梳理Basis知识体系的运维人员参考。1. SAP日常运维BASIS一份内训清单如何让巡检不再靠直觉凌晨两点被电话叫醒生产系统登不上去了——这种场景做SAP日常运维BASIS的人大概率都经历过。但真正让人头疼的不是半夜的突发故障而是白天的例行巡检没做到位问题拖到半夜才爆出来。我拆过的内部培训笔记不少这份SAP BASIS内训清单属于“能直接上手”的一类它把用户权限、集团管理、数据库备份、后台作业、打印、系统监控、传输管理这些日常运维事务代码串成了一条稳定的巡检路线。适合刚接手SAP系统维护的工程师照着敲一遍也适合干了一阵但还在靠零散记忆做事的BASIS老手查漏补缺。内训原文不厚但每一条事务代码都对应着一个具体的运维动作抄下来当手册用比翻一堆系统文档实在。2. 用户与权限管理SU01、PFCG、SU53的日常操作边界权限管理是最容易“好心办坏事”的一块。你给用户多勾一个对象生产订单可能被改掉你把SU10批量用户的勾选范围放大了一行可能把服务账号一起锁了。所以权限这块要把事务代码和它们之间的责任边界理清楚不能一个界面用到底。2.1 SU01与PFCG账号生命周期与角色权限的参数文件SU01负责用户主数据日常高频操作就三件事解锁、改密码、复制账号。用户连续输错密码被系统锁定用SU01进入用户状态页签把“已锁定”标记清掉再保存密码过期或合规策略调整先在登录数据页签输入临时密码再让用户第一次登录后修改新密码。复制账号常用于新员工入职操作路径是SU01里先输入模板账号选择复制功能再输入新账号名系统会把模板账号的角色分配和授权参数一起带过来。复制完必须立刻重置密码否则安全审计过不了。PFCG管角色权限变更的正确路径是想清楚改哪个角色进PFCG调整授权对象生成新的权限参数文件用户重新登录后生效。最容易犯的错是直接在SU01里手改权限值这种改法一旦角色重新生成或做传输就会丢失而且没有审批轨迹。大型企业通常对PFCG变更做流程管控BASIS只执行角色需求由业务侧负责人提出。内训里提到的“复制账号加相同权限”本质就是让新账号直接沿用角色的权限快照省去逐个勾权限树的时间。SU01场景入口位置必须注意的参数解锁用户状态页签确认不是误锁保存前再看一次状态重置密码登录数据页签临时密码首次登录强制改密复制账号用户-复制为新账号名唯一复制后立即改密码权限账号多了之后手动检查不现实。我一般会把SU01导出的用户列表落地成文本再用脚本做一次晨检确认锁定账号数量和异常账号。下面这个示例脚本按最常见的导出格式处理import re # 文件内容摘自SU01按用户清单导出字段顺序按导出模板调整 # 每条记录包含用户名、状态、最后登录日期 # 用途晨检时统计生产系统中被锁定的账号防止有人被锁一夜没人管 with open(sap_users.txt, r, encodingutf-8) as f: lines f.readlines() locked [] pattern re.compile(r^(\S)\s(\S)\s(\S)) for line in lines: m pattern.match(line.strip()) if not m: continue username, status, last_login m.groups() if status in (锁定, locked, LOCKED): locked.append((username, last_login)) print(f锁定账号数量: {len(locked)}) for user, login in locked: print(f{user} 最后登录: {login})这段脚本的核心是正则匹配三列字段按状态列过滤出锁定账号。导出模板变化时只需要调整pattern里的字段顺序不需要改逻辑。建议把输出结果重定向到固定日志文件让监控平台按天抓取这样连续几天账号被锁的情况就能留下趋势记录。2.2 SU53、SU20、SU21与SU22把“无权限”拆成可定位的对象用户报“无权限”的时候别急着去PFCG里补权限。正确操作顺序是让用户重新执行那个事务保持错误弹窗不关闭再用SU53检查一次。SU53会列出缺失的授权对象、字段名和当前值截图保存后回PFCG找对应角色把缺失值补进去。这个动作很关键因为SU53只能告诉你“缺什么”真正动手改的是PFCG角色两者不在一个界面定位错误就会越改越乱。SU20维护权限字段SU21维护权限类和权限对象SU22维护事务代码对应的授权对象。日常运维中这些事务代码用得不多但有一个场景特别实用业务方问“为什么这个事务码要求这么多权限”用SU22打开事务码的授权对象清单就能直接给他念出来省掉来回扯皮。SU22在排查“某个事务为什么所有人都没权限”时也非常有用因为能看到该事务硬关联了哪些授权对象。SU10批量修改用户权限需要守住边界。最常见的翻车现场是用SU10按用户组批量加权限参数文件结果把管理员账号也套了进去改完自己先登不上了。用SU10前一定先把当前用户清单导出备份改动范围按业务用户组过滤先在一个测试账号上验证再推给批量名单。SU53、SU20、SU21、SU22这组事务代码不是每天都要用但它们构成了权限问题的完整排查链路现象定位到内层对象再回到PFCG去改角色。注意权限变更后部分用户需要重新登录并清缓存否则仍然命中旧权限快照。这是权限问题上最常见的“背锅”环节先确认这个再去找角色问题。3. 数据库与后台作业DB13备份日历与SM36失败作业的三步排障数据库和后台作业是SAP运维的“夜班工人”。业务白天跑业务晚上靠备份和批处理作业把数据固化和归档。这一层如果没人盯第二天早上打开系统看到的数据可能就是残缺的。3.1 DB13、DB02、DB12与BRTOOLS数据库日常监控怎么配合内训资料里点名的三个数据库事务代码对应着三层检查。DB13是数据库日常维护日历定义备份计划、检查数据库状态、优化统计更新都从这里进入DB12查看数据备份日志重点确认夜间备份是否成功、日志目录剩余空间够不够DB02监控数据库表和索引的扩展情况包括碎片率和优化统计提示。BRTOOLS则是操作系统层的数据库管理工具适合做底层备份恢复和日志分析。每天早晨第一件事进DB12或DB13日志看前一夜备份是否正常结束。不要只看任务状态是“完成”还要对比备份文件大小和前一天是否接近。如果文件大小突然小了一半大概率是归档日志写失败或表空间空间不足数据库静默跳过了某些表的备份。日志目录剩余空间也要顺手看一眼Oracle环境下备份文件写满文件系统是备份失败的最高频原因。DB02建议每周固定看一次。表和索引的扩展程度、碎片比例、优化统计的状态都在这里反映。碎片严重时需要先评估是否重建索引再跑优化统计更新。很多性能问题不是SQL写得差而是统计信息过期DB02里优化统计提示亮了红灯就要去安排DB13里的优化统计作业。#!/bin/bash # 检查数据库备份日志目录输出最近三天的备份文件及大小 # 用法./check_backup.sh /oracle/SID/saptrace/background LOG_DIR${1:-/oracle/SID/saptrace/background} if [ ! -d $LOG_DIR ]; then echo 日志目录不存在: $LOG_DIR exit 1 fi echo 最近三天备份日志 find $LOG_DIR -type f -mtime -3 -printf %TY-%Tm-%Td %8s %f\n | sort -r echo 错误关键字扫描 grep -riE error|fail|fatal $LOG_DIR --include*.trc --include*.log 2/dev/null | tail -20脚本第一个参数是日志目录默认指向Oracle标准路径。find命令按修改时间过滤最近三天的文件按日期排序显示大小和文件名grep扫描trc和log文件里的错误关键字只输出最后20条避免刷屏。文件大小出现明显缩水时脚本不会报错但人眼扫一眼就能发现问题这也说明脚本只负责把信息暴露出来判断还得靠运维经验。3.2 SM36与SM37后台作业定义、监控与失败原因分类后台作业是SAP的“自动班”。SM36定义作业SM37监控作业。定义作业时三个参数最关键作业类Job Class决定优先级和资源占用、启动周期、作业步骤。很多新手把作业步骤里的程序变式填错导致每天跑出来的结果都是同一批旧数据而且因为作业状态是“完成”很长时间不会被发现。SM37的日常检查顺序按时间范围拉出作业清单按状态排序把“取消”状态的作业逐一点开看日志定位失败步骤。失败原因归成三类权限不足、资源冲突、程序错误。权限不足看作业日志里的授权检查失败消息处理方式是确认作业执行用户后补权限再释放资源冲突通常表现为锁冲突用SM12查锁确认没有活动用户后删锁程序错误则要转ST22分析短转储把问题和解决过程记录在案。SM37失败类型日志特征处置动作权限不足Authorization check failed检查执行用户角色确认后补权限并释放锁冲突Lock exists on objectSM12查看锁确认无活动用户后删除锁ABAP dumpABAP Runtime Error打开ST22分析短转储交开发确认注意管理员应该检查所有被取消的作业把问题和解决方案记录在案。这条内训原话看起来平淡真正做过运维才懂——作业“取消”状态不会主动通知业务早上发现数据不对才来问排查已经晚了。另外建议给关键作业配置完成通知或者用一个定时器每天固定时间检查SM37里的“取消”作业再把结果推到值班群。凌晨失败一眼就能看到不用等业务反馈。后台作业这块如果不建立记录习惯同一个作业可能每周失败一次每次都要重新定位纯消耗时间。4. 系统监控与排障从ST06到ST22读哪些信号、怎样处置系统监控是BASIS日常工作中最考验“手感”的部分。一堆事务代码并不是每天都要全部过一遍但要清楚每一条负责看什么、出现什么状态该动什么手避免临时抱佛脚。4.1 ST06与ST03OS资源与R/3工作负载的对照阅读ST06看操作系统层面CPU利用率、内存使用率、Page Space使用率这是最直接的体温计。但别只盯当前值重点要看趋势。中午高峰期CPU持续90%以上和早上七点只有30%完全是两回事。ST06里还能看到磁盘使用率配合当前在线用户数一起判断能区分是业务高峰期还是异常访问。ST03记录R/3工作负载包括响应时间、CPU时间、数据库时间。内训里有一句话很关键没有经验的替代品。当系统没有性能问题的时候保留尽可能多的工作负载数据这些历史数据就是以后调优的基线。遇到性能问题把当前数据和基线对比能快速判断是应用代码变慢还是基础设施退化。没有基线就只能对着绝对数字猜猜错方向反而浪费时间。日常动作可以固定成两个每天看一次ST06把CPU、内存、Page Space异常点位记下来每周把ST03的关键指标折线图存档归档到运维目录。突发性能问题发生时优先调ST03的“数据库时间”和“CPU时间”两个页签对比正常时段数据多数情况下能锁定在DB层还是应用层。4.2 SM50、SM12、SM13与ST22进程、锁、更新与短转储的处置优先级SM50看服务器进程能看到当前运行的dialog、update、background进程每个进程的CPU时间和请求时间一目了然。SM51是服务器概览多应用服务器环境先在这里找到对应实例再进SM50。长时间运行的报表或后台作业是最大威胁发现后要和业务确认再终止不要直接从操作系统层删进程那样容易把共享内存搞乱。SM12锁管理要克制。用户断线、程序出错、后台任务重复启动都可能留下锁对象锁一直不清会影响后续操作保存。判断边界用SM12看锁对象和创建时间如果创建时间远早于当前活跃会话的时间再删除。删除前最好确认对应事务已经没有活动用户否则会把正常操作打断。SM13更新记录显示失败的更新动作。在生产系统里失败的更新动作决不允许发生。出现SM13失败第一步截图记录错误第二步立刻通知开发分析第三步评估是否需要恢复流程。很多更新失败是主键冲突或数据不一致简单重跑会掩盖问题要等开发确认原因后再决定是否重跑。ST22是ABAP程序的短转储黑匣子。当一个报表或事务因严重错误停止工作时系统在表SNAP里记录程序终止时的出错信息。每天检查是否有新的short dump重点看报错程序名、错误类型、出错模块。有些短转储是偶发的数据库超时重跑就好有些是代码缺陷必须交开发修复。分析ST22时不要只看错误标题就关掉展开详细信息看触发位置截图附在运维记录里下次再出现同类型报错就能快速关联。监控场景事务代码建议动作OS资源突高ST06抓取CPU/内存/Page Space快照对比ST03在线用户异常SM04/AL08区分服务器相关与无关判断是否有违规访问进程占用过高SM50/SM66确认业务影响后再杀进程记录工单短转储出现ST22分析SNAP表区分偶发还是代码缺陷5. 传输、打印与日志四个避坑记录与两个目录级排查位传输、打印、日志这三块属于“平时没事、出事就急”的模块。传输队列卡住影响测试和发布打印失败影响月度报表日志找不到就是瞎查。这里把高频踩坑点和目录位置一次说清。5.1 STMS与SE09传输队列卡住先查头一个SE09管理改变请求和任务释放后进入STMS传输队列。队列卡住最常见的原因是最前面的传输请求失败了传输控制程序会暂停后续所有请求。处理顺序是打开STMS队列面板看第一个红色或黄色状态项点日志看失败原因。原因一般分三类——基础类型不匹配、目标系统不可达、请求被后续覆盖。修好最前面一个队列通常会自己继续跑。千万别在队列中间动手改状态会产生乱序传输后面接手的开发会一脸茫然。另外SE09里的“释放”不等于“传输完成”。一个请求要经历释放、进入队列、导出、导入、激活多个阶段业务人员问“传输好了吗”时要去STMS看队列状态而不是只看SE09里的请求是否释放。5.2 SPAD与SP01假脱机“已完成”不等于打印成功SPAD定义打印设备SP01管理假脱机请求和输出请求。最常见的打印问题不在SAP服务器上而在用户端PC。用户在电脑上打印SAP把输出任务交到打印队列SP01里显示“已完成”但打印机实际没有出纸原因往往是用户PC上的SAPLPD程序被关闭或异常退出。这里有个内训反复强调的认知SAP系统只跟踪打印任务到目标队列输出控制器里的“已完成”状态并不代表真实打印成功。重要和大量的打印任务在被从TemSe中删除前必须先确认对方真的收到了纸质输出或电子文件。如果不确认月底财务对账时缺一堆单据再回头找假脱机请求已经删了没人说得清责任。5.3 关键日志目录记住这四个路径排错时找日志位置是第一步也是最费时间的一步。内训资料给出了四个最核心的路径日志类型路径启动日志/home/ adm进程日志/usr/sap/ /DVEBMGS00/work传输日志/usr/sap/trans/log/数据库日志/oracle/ /saptrace/background系统启动失败时按这个顺序查先看启动日志停在哪个阶段再看进程日志里DVEBMGS00的工作目录有没有异常然后查传输日志排除传输堵塞影响启动最后看数据库日志有没有ORA错误。这个顺序能覆盖90%的启动故障场景不建议跳步。5.4 避坑记录现象、原因、解决以下是几条实际运维中反复出现的踩坑记录按照“现象、原因、解决”写清楚可以直接抄进自己的运维记录本。现象早晨发现夜间备份日志显示“已完成”但备份文件大小只有平时三分之一。原因Oracle归档日志目录满或数据库静默跳表。解决进DB12和BRTOOLS确认备份文件清单清理归档目录再安排一次全量备份并把归档目录空间纳入日常监控。现象用户反馈权限刚改过但执行事务仍然报无权限。原因PFCG角色修改后没有重新生成权限参数文件或者用户端缓存未刷新。解决PFCG里重新生成参数文件让用户重新登录并清理缓存。这个问题出现频率极高排错时先确认这一步再回头看角色配置。现象SM37中作业状态为“取消”但作业日志里看不到明显错误。原因作业执行用户的账号被锁定或权限等级不够。解决用SU01检查作业执行用户的状态调整用户或作业类手动重跑一次作业确认成功后把解决方案记录到运维台账。现象SP01假脱机请求状态是“已完成”但打印部门说没收到单据。原因用户端SAPLPD进程关闭或打印机名映射错误。解决到用户PC上重启SAPLPD进程确认打印端口映射重要任务在删除TemSe前人工确认。现象STMS传输队列第一个请求长期红色后续请求全部堆积。原因导入时发生语法错误或对象激活失败。解决先处理第一个失败请求必要时在源系统修改后重新释放让后续请求排队继续执行避免跳号乱序。6. 把BASIS巡检固化成脚本sapcontrol与备份日志的晨检组合6.1 一个可落地的晨检脚本如果每天还在用SAP GUI一个个点事务代码建议试试把高频检查项交给脚本。应用服务器进程状态可以用sapcontrol命令获取备份日志和传输队列可以跨操作系统层处理。下面这个基础版晨检脚本适合单应用服务器环境多实例环境加一层循环即可。#!/bin/bash # SAP BASIS 晨检脚本示例 # 检查应用服务器进程、昨日数据库备份日志、传输队列阻塞情况 INSTANCE00 echo 1. 检查应用服务器进程状态 sapcontrol -nr $INSTANCE -function GetProcessList | grep -E GREEN|YELLOW|RED echo 2. 检查昨日数据库备份日志 LOG_DIR/oracle/SID/saptrace/background YESTERDAY$(date -d yesterday %Y%m%d) LOG_FILE$LOG_DIR/*backup_${YESTERDAY}* if ls $LOG_FILE /dev/null 21; then grep -iE error|fail $LOG_FILE | head -10 else echo 未找到昨日备份日志请人工确认DB13状态 fi echo 3. 检查传输队列是否有阻塞标记 su - SIDadm -c tp check 2/dev/null || echo tp check需要以SIDadm用户执行脚本先调sapcontrol的GetProcessList函数获取实例进程列表输出包含GREEN、YELLOW、RED状态行一眼就能看出进程健康情况备份日志检查按日期匹配文件抓取错误关键字传输队列检查通过tp check完成这条命令需要切换到 adm用户执行所以脚本里用su命令包了一层。参数INSTANCE要根据实际实例号修改日志目录也要替换成真实SID路径。输出结果建议重定向到固定文件并追加时间戳方便和SAP GUI里的ST06、ST03趋势对照。6.2 从脚本到习惯每周回看ST03与ST12脚本能抓住显性异常但ST03的工作负载基线和ST22的历史短转储趋势才是支撑预判的底层数据。每周固定时间做两件事把ST03的关键指标存一次档放到运维目录把ST22里的短转储清单过一遍标记哪些是偶发、哪些在重复出现。重复出现的短转储通常指向某个代码缺陷或数据问题提前处理能避免它演变成生产事故。从那以后我每天早晨到工位的第一件事变成先看脚本输出再决定要不要开SAP GUI省下来的时间都花在看趋势和整理记录上了。这套晨检思路希望帮到你。本文还有配套的精品资源点击获取
