简介面向SAP Basis日常运维岗位的事务代码与操作要点速查资料适合需要快速定位用户权限、集团管理、数据库维护、后台作业和系统监控入口的初、中级运维人员。整包为1个PDF文件约2.02MB便于随时查阅也可作为内训后的命令索引。内容覆盖SU01、SU10、PFCG、SU53等用户权限管理SCC4、SCCL、SCC1等集团操作DB13、DB02、DB12数据库维护SM36、SM37后台作业及SPAD、SP01打印管理系统监控部分涉及ST06、ST03、SM04、SM21、SM50、SM12、ST22等常用入口并延伸至SE09、STMS传输管理和RZ10、RZ11参数维护同时提示启动、进程、传输与数据库日志路径。已有965人学习适合按模块查命令、整理日常巡检清单或结合日志位置建立基础排错思路。1. 接手一套 SAP 生产系统BASIS 日常运维到底在管什么凌晨两点被告警叫醒登录系统先敲 ST22 看有没有 short dump再开 SM37 确认夜间批处理有没有被取消接着 DB12 核对备份是否真的跑完——这是很多 SAP BASIS 运维岗的真实开场。这套内训资料把日常运维涉及的事务代码按九大类整理成一张可执行的清单用户权限、集团管理、数据库维护、后台作业、打印、系统监控、传输管理、参数与远程连接、日志目录。它要解决的核心问题是新人接手系统时不知道该看什么、按什么顺序看、看到异常怎么定位。适合刚转岗做 SAP 运维的工程师、需要接管生产系统的开发人员以及想把日常巡检从“凭记忆”变成“照单执行”的团队。2. 用户与权限从 SU01 到 PFCG 的最小闭环权限问题是 SAP 运维中最高频的工单来源日常大约有一半的求助都集中在“我进不去某个事务码”“密码锁了”“新同事要开通账号”。这一章的路径是从单账号维护走到角色设计再走到权限失败时的排查三件事分别对应 SU01、PFCG、SU53。2.1 SU01 的三个高频动作解锁、改密、复制账号SU01 是用户主数据维护入口日常真正用到的只有三个动作。第一个是解锁用户连续输错密码后状态变为锁定在 SU01 的“登录数据”页签把“用户锁定”标记清掉再点保存。第二个是重置密码同一页签下的“初始密码”按钮会生成一个新密码并强制用户下次登录修改注意这一步会同时把用户的锁定状态解开如果只是要解锁不想动密码别点它。第三个动作是复制账号这是新建用户最快的方式。做法是在 SU01 输入已存在账号菜单里走“复制”目标用户名填新账号系统会把源账号的角色、参数文件、用户组一并带过来。SU01 复制账号的字段级注意事项 源用户 mycw12 已存在权限配置完整 目标用户 MYCW14 计划新建 复制内容 地址数据 / 登录数据 / 角色 / 参数文件 / 用户组 不复制 初始密码需单独设置、用户有效期默认沿用源值复制完成后必须做两件事一是立刻给新账号设初始密码并要求首次登录修改二是核对用户有效期源账号如果设过某天到期复制出来的新账号会继承这个日期新人用几天就登不上了。这类问题排查起来很浪费时间因为报错只说“用户无效”不会提示是有效期到了。提示SU01 里删除用户并不是物理删除只是打上删除标记用户仍会占用账号名。真要清理得走 SU10 批量处理或者后续的归档流程。2.2 PFCG 设计角色SU10 批量变更单个用户改权限用 SU01 就够但只要涉及一批人就必须走角色。PFCG 是角色维护入口标准做法是先在“菜单”页签里把事务码、报表、权限对象挂进角色再在“权限”页签点“生成”系统据此推导出需要的权限对象清单最后在“用户”页签把账号挂上去。这里的顺序不能反先改菜单再生成权限只改用户不重新生成权限不会生效。角色改完之后的批量分发用 SU10。它的价值在于一次选中多个用户把角色或参数文件统一增删避免一个个进 SU01 点。SU10 批量操作步骤 1. 输入用户名单或用通配符匹配如 MYCW* 2. 选择“角色”页签添加或删除目标角色 3. 勾选“比较”执行 4. 到结果列表里确认每个用户的状态为成功参数上唯一需要注意的是“比较”开关。勾选它系统会把用户当前的角色和目标角色做差集只处理差异部分不勾选则直接覆盖。覆盖模式在批量收回权限时更直接但如果用户身上有临时加的额外角色会被一并清掉恢复起来很麻烦。我的习惯是默认勾选比较只在明确要“重置为某个标准角色集”时才用覆盖。2.3 SU53 权限检查定位失败的真正原因用户说“我进不去”直接给权限是错的先看 SU53。这个事务码显示当前用户最近一次权限检查失败的完整链路失败的是哪个权限对象、哪个权限字段、需要什么值、用户实际有什么值。它只保留最近一次结果所以有两个操作要点一是让用户在报错后立刻打开 SU53不要继续点别的操作否则记录被覆盖二是 SU53 显示的是用户自己的检查结果管理员要诊断别人的问题得让对应用户配合或者用 SU53 的“为其他用户评估”功能传入用户名。拿到对象和字段之后回到 PFCG 的角色里补对应的权限值重新生成角色再让用户重新登录。这里有个常见误区改完角色就以为生效了实际上用户的权限缓冲区要重新登录才会刷新不重新登录的话 SU53 还是老结果会让人误以为没改对。权限对象本身如果要新增或调整才会动到 SU21权限类与对象、SU20权限字段、SU22事务码对应的授权对象这三个底层事务码。日常运维基本不碰它们因为改动权限对象属于跨系统的设计变更必须走传输。3. 集团与数据库SCCL 拷贝和 DB13 巡检的落地细节集团Client是 SAP 里隔离数据的逻辑单位开发、测试、生产通常各占一个。日常会遇到两类需求把生产数据刷到测试集团做验证或者新建一个集团给外部团队用。数据库侧则是每天必须确认的事——备份跑没跑、表空间涨没涨。3.1 SCCL 拷贝集团先看清楚要覆盖什么SCCL 是集团拷贝的入口配置项不多但每一个都会影响结果。参数作用常用取值与说明源集团数据来源生产或质量集团需确认该集团允许作为源目标集团被覆盖的集团目标集团的全部业务数据会被清空重写拷贝配置文件决定拷贝哪些表SAP_ALL 全量SAP_APPL 仅应用数据SAP_USER 仅用户主数据并行进程数加快拷贝速度按数据库服务器 CPU 核数取一般 48源集团是否可覆盖控制开关目标集团的 SCC4 里必须允许“集团无关对象”被覆盖选择配置文件是这一步最关键的决定。SAP_ALL 把所有表都拷过来包括用户主数据代价是目标集团的本地账号全部丢失SAP_USER 只拷用户和权限适合“数据已经是新的、只想同步权限”的场景SAP_APPL 跳过用户和权限是刷数据时最常用的选择因为能保住目标集团自己的测试账号。跑之前务必确认目标集团没有人在用拷贝开始后目标集团会被锁定中途取消会留下半成品。拷贝完成后有两件收尾工作常被漏掉。一是检查 SCC3 里的拷贝日志确认每个阶段的返回码二是核对目标集团里的逻辑系统名如果目标集团要做跨系统接口逻辑系统名不匹配会导致后续所有 RFC 调用失败而这个问题往往在几天后才暴露。3.2 SCC4 与 SCC1集团属性控制和单请求传输SCC4 管的是集团本身的属性最重要的开关是“集团角色”和“更改是否允许”。生产集团设成“不允许更改”可以挡住大部分误操作但也会挡住紧急修复所以通常还要配合一个“允许更改但记录”的中间态具体取哪个值取决于团队的变更规范。SCC1 用来在系统内把单个传输请求从一个集团导入另一个集团和 STMS 的跨系统传输是两回事。典型场景在开发集团改了一个配置想马上验证到测试集团又不想走完整的发布流程就用 SCC1 指定请求号加目标集团。它同样要求目标集团的 SCC4 允许覆盖且请求必须是已释放状态未释放的请求 SCC1 读不到。3.3 DB13 与 DB02日常巡检的两块表DB13 是数据库维护日历本质是一个集中管理数据库相关后台作业的调度面板。日常最常看的是三件事昨晚的备份作业是否成功、数据库检查CHECK DATABASE的执行结果、优化统计信息是否按时更新。每一项点进去都能看到作业日志失败时日志里会有具体的错误码。DB02 是容量视角的监控。它给出表空间的当前大小、使用量、增长趋势以及索引的碎片情况。日常巡检只需要盯两条表空间使用率是否超过阈值、是否有表的增长速度异常。碎片问题一般不做实时处理攒到维护窗口再重建因为在线重建大表索引对系统负载的影响不容忽视。日常数据库巡检顺序建议固化成检查表 1. DB13 看夜间备份作业状态失败则立刻查日志 2. DB12 核对备份日志与日志目录剩余空间 3. DB02 看表空间使用率与增长趋势 4. DB13 看优化统计作业是否按时完成 5. 异常项记入值班记录附作业名和错误码DB12 和 DB13 的关系容易搞混DB12 是备份日志的查看入口展示的是备份动作本身的成功与否DB13 是调度和总览。查问题时从 DB12 拿到备份文件路径和时间戳再对照操作系统的日志目录才能确认备份文件真的落了盘。4. 监控与排障ST22、SM37、SM50 的联动读法监控类事务码有十几个一个个看会淹没在信息里。实践中真正需要形成联动的只有几组应用层报错看 ST22 和 SM21作业层看 SM37 和 SM50资源层看 ST06 和 ST03。4.1 ST22 短存储每天必看的第一屏ST22 记录 ABAP 程序运行时的 dump。判断一个 dump 是否需要处理看三个字段发生时间、程序名、错误类型。如果是标准程序在有规律的时间点报同一个错通常是数据或参数问题如果是自开发程序高频报错基本可以确定是代码缺陷需要转给开发。日常操作上有个技巧不要只看当天的列表用 ST22 的筛选条件按“用户”或“程序”聚合能快速识别出反复出错的源头。一个程序一天报几十次 dump对系统性能的影响是实打实的它会拖慢对话进程的响应。排查顺序上先看 dump 详情里的“错误分析”段落那里会直接点出是哪一行、哪个变量为空或者越界再看“调用栈”确认是从哪个事务码进来的。如果 dump 集中在某个时间段配合 SM21 的系统日志看那个时间点有没有异常事件。4.2 SM37 后台作业取消的作业才是重点SM37 的界面里真正需要关注的是状态为“已取消”的作业而不是“已完成”。已完成说明正常结束已取消意味着作业中途异常终止通常伴随 spool 里的错误信息。SM37 的处理路径 1. 选择作业名可用 * 通配和时间范围勾选“已取消”状态 2. 选中作业 → 作业日志看具体在哪一步失败 3. 若是程序错误日志里会有 ABAP 运行时错误转 ST22 看详情 4. 若是资源不足如内存溢出需要调整作业的服务器组或拆分数据量 5. 修正后不要直接复制旧的作业先确认作业的变式和参数是否仍然正确这里有个血泪经验作业被取消后很多人第一反应是“重跑一次”但如果失败原因是数据量超出预期重跑只会再失败一次还可能把系统资源占满。正确做法是先看作业的 spool 输出和运行时长判断是偶发还是趋势性增长。SM36 是作业定义的入口日常用得比对 SM37 少但有一个场景必须熟悉新建周期性作业时开始条件要选“立即”还是“计划”取决于它是否需要依赖前置作业完成。默认选“立即”的作业不会等待前置作业链式依赖会断表现出来就是凌晨的报表跑出来是空的。4.3 SM50、SM66 与 SM12进程和锁SM50 显示当前应用服务器的进程状态最直观的用法是找长时间处于“运行”状态的对话进程。一个对话进程跑了几十分钟基本可以断定是用户执行了没有优化的大报表或者程序进入了死循环。处理方式是先确认是哪个用户、哪个事务码、哪张表再和用户沟通后终止。SM66 是全局视角一次看所有应用服务器的进程适合系统有多台应用服务器时快速定位是哪个节点在忙。SM12 是锁管理用户断线或程序异常退出后会留下锁条目表现为“别人改不了这条数据”。处理锁之前必须确认持有锁的会话已经不存在否则删了锁会让两个会话同时改一条数据后果比锁着更严重。4.4 ST06 与 ST03先有基线才谈得上判断ST06 是操作系统层面的资源视图CPU 使用率、内存、交换空间、文件系统占用。日常巡检看的是趋势单次快照没有意义。ST03 是 SAP 自身的负载分析包含响应时间、数据库时间、用户分布。这两者的使用有个前提必须在系统正常的时候采集基线数据。平时记录下工作日的典型 CPU 曲线、典型对话响应时间等到某天用户抱怨“系统变慢了”把当期数据和基线一对比立刻能判断是整体变慢还是某个时段尖峰。没有基线的话看到 CPU 70% 也不知道算不算高只能凭感觉这正是运维里最不该出现的情况。5. 避坑与常见问题这五个坑几乎每个人都踩过5.1 权限改完不生效SU53 还是旧的失败记录现象PFCG 里补了权限角色也生成了用户反馈还是进不去SU53 显示同样的失败对象。原因用户的权限缓冲区在登录时加载改角色不会主动刷新已有会话同时 SU53 只记录最近一次检查结果用户没有重新触发操作看到的仍是旧记录。解决让用户完全退出系统再登录重新执行一次报错的操作再看 SU53。批量场景下可以用 SM04 确认该用户会话已断开避免以为退了实际还在。5.2 SCCL 拷完目标集团里所有人的账号都没了现象集团拷贝成功日志全绿但测试团队登录不上提示用户不存在。原因拷贝配置文件选了 SAP_ALL用户主数据被源集团覆盖目标集团原有的本地账号全部被替换。解决刷数据场景改用 SAP_APPL 配置文件跳过用户和权限表。如果已经覆盖只能从备份恢复用户主数据或者重新按清单建账号代价很大所以选配置文件这一步必须在执行前确认。5.3 SM37 里作业显示已完成业务数据却没出来现象夜间作业状态是已完成但下游报表数据缺失。原因作业本身执行成功但它调用的程序逻辑里捕获了异常并正常返回实际没有写入数据或者作业的变式参数被改动过取数范围变成了空集。解决不能只看状态必须打开 spool 输出核对实际处理条数。对关键作业设一个校验步骤比如在作业链末尾加一个统计行数的程序行数为零就发告警。5.4 ST22 里 dump 一堆修完一个又冒一个现象每天都有 dump逐个分析耗时巨大修完一个另一个又出现。原因没有做聚合分析把互不相关的偶发 dump 当成独立问题处理或者某个公共函数被多个程序调用根因只有一个但表现分散。解决先按程序名和时间段聚合找出高频项再看调用栈里是否有共同的底层函数。优先处理高频和集中在业务高峰期的 dump低频偶发项记录下来观察。5.5 参数用 RZ10 改了重启后回退现象用 RZ10 修改了系统参数当前生效系统重启后变回原值。原因RZ10 修改的是实例参数文件如果没有保存并激活或者改的是默认参数文件而实例参数文件里有同名覆盖项重启就会以实例文件为准。解决改完用 RZ11 在线确认当前生效值同时检查实例参数文件是否有同名条目。跨系统的参数变更要走传输不要在各环境手工各改一遍否则三个环境的参数迟早不一致。6. 把巡检固化成习惯一份可复用的每日检查顺序事务码记住了不等于会用。我见过不少同行能把 SM50、ST22、DB13 说得头头是道真到值班时还是手忙脚乱因为脑子里没有固定顺序看到告警才去翻永远在救火。这一章给一个可以直接照着走的顺序以及两个提升效率的具体技巧。每日巡检我一般分三段早上上班后二十分钟内跑完前两段时段检查项事务码判定标准上班后夜间作业是否有取消SM37取消数为零或有已知原因的记录上班后备份是否成功DB13 / DB12状态成功日志目录空间充足上班后当日 dump 概况ST22无新增高频程序上午表空间与增长DB02使用率低于阈值上午系统日志告警SM21无未处理的错误条目随时进程与锁SM50 / SM66 / SM12无长时间运行进程、无残留锁下班前传输队列STMS无卡住的请求两个具体技巧。第一个是把关键检查项做成一个自定义的报表或事务码集合用 SE93 包一个入口点一次就能依次跳到 SM37、ST22、DB13。这件事花不了多少时间但把“记得去看”变成了“点一下就看了”坚持率会明显不一样。第二个技巧是日志目录的核对要落到操作系统层面。SAP 自己的事务码只能看到系统认为的状态文件到底有没有落盘必须去操作系统确认# 传输日志目录确认最近的传输是否有报错 ls -lt /usr/sap/trans/log/ | head -20 # 进程日志目录dev_disp 里记录实例启动和进程异常 tail -200 /usr/sap/SID/DVEBMGS00/work/dev_disp # 数据库后台日志目录备份与归档的原始记录 ls -lt /oracle/SID/saptrace/background/ | head -20三段命令的用途不同传输日志看导入是否完整dev_disp 看实例层面的启动、重启和进程崩溃数据库后台日志看备份与归档的真实执行情况。路径里的SID要替换成实际系统标识别直接抄。STMS 里显示传输成功但操作系统日志里如果有报错行说明部分对象被跳过这种情况在生产系统上必须追到底。还有一个容易被忽略的点ST03 的负载数据要定期导出归档。系统默认只保留有限天数的统计数据等到出了性能问题再回头找“上个月正常时是什么样”数据往往已经被清理了。我一般每月导出一次按月份命名存到共享目录这个习惯在两次性能排查里救过场因为没有基线数据性能问题基本只能靠猜。从那以后我每次接手一套新系统第一件事不是看配置而是先跑一遍完整巡检、把结果存成基线再开始改任何东西。有了这份基线后面所有“系统变慢了”“作业变久了”的判断才有参照。希望帮到你。本文还有配套的精品资源点击获取 
长河君 · 2026/11/4 2:59:35 · 阅读 1.2k SAP BASIS日常运维与巡检：权限、集团、数据库、监控排障清单
简介面向SAP Basis日常运维岗位的事务代码与操作要点速查资料适合需要快速定位用户权限、集团管理、数据库维护、后台作业和系统监控入口的初、中级运维人员。整包为1个PDF文件约2.02MB便于随时查阅也可作为内训后的命令索引。内容覆盖SU01、SU10、PFCG、SU53等用户权限管理SCC4、SCCL、SCC1等集团操作DB13、DB02、DB12数据库维护SM36、SM37后台作业及SPAD、SP01打印管理系统监控部分涉及ST06、ST03、SM04、SM21、SM50、SM12、ST22等常用入口并延伸至SE09、STMS传输管理和RZ10、RZ11参数维护同时提示启动、进程、传输与数据库日志路径。已有965人学习适合按模块查命令、整理日常巡检清单或结合日志位置建立基础排错思路。1. 接手一套 SAP 生产系统BASIS 日常运维到底在管什么凌晨两点被告警叫醒登录系统先敲 ST22 看有没有 short dump再开 SM37 确认夜间批处理有没有被取消接着 DB12 核对备份是否真的跑完——这是很多 SAP BASIS 运维岗的真实开场。这套内训资料把日常运维涉及的事务代码按九大类整理成一张可执行的清单用户权限、集团管理、数据库维护、后台作业、打印、系统监控、传输管理、参数与远程连接、日志目录。它要解决的核心问题是新人接手系统时不知道该看什么、按什么顺序看、看到异常怎么定位。适合刚转岗做 SAP 运维的工程师、需要接管生产系统的开发人员以及想把日常巡检从“凭记忆”变成“照单执行”的团队。2. 用户与权限从 SU01 到 PFCG 的最小闭环权限问题是 SAP 运维中最高频的工单来源日常大约有一半的求助都集中在“我进不去某个事务码”“密码锁了”“新同事要开通账号”。这一章的路径是从单账号维护走到角色设计再走到权限失败时的排查三件事分别对应 SU01、PFCG、SU53。2.1 SU01 的三个高频动作解锁、改密、复制账号SU01 是用户主数据维护入口日常真正用到的只有三个动作。第一个是解锁用户连续输错密码后状态变为锁定在 SU01 的“登录数据”页签把“用户锁定”标记清掉再点保存。第二个是重置密码同一页签下的“初始密码”按钮会生成一个新密码并强制用户下次登录修改注意这一步会同时把用户的锁定状态解开如果只是要解锁不想动密码别点它。第三个动作是复制账号这是新建用户最快的方式。做法是在 SU01 输入已存在账号菜单里走“复制”目标用户名填新账号系统会把源账号的角色、参数文件、用户组一并带过来。SU01 复制账号的字段级注意事项 源用户 mycw12 已存在权限配置完整 目标用户 MYCW14 计划新建 复制内容 地址数据 / 登录数据 / 角色 / 参数文件 / 用户组 不复制 初始密码需单独设置、用户有效期默认沿用源值复制完成后必须做两件事一是立刻给新账号设初始密码并要求首次登录修改二是核对用户有效期源账号如果设过某天到期复制出来的新账号会继承这个日期新人用几天就登不上了。这类问题排查起来很浪费时间因为报错只说“用户无效”不会提示是有效期到了。提示SU01 里删除用户并不是物理删除只是打上删除标记用户仍会占用账号名。真要清理得走 SU10 批量处理或者后续的归档流程。2.2 PFCG 设计角色SU10 批量变更单个用户改权限用 SU01 就够但只要涉及一批人就必须走角色。PFCG 是角色维护入口标准做法是先在“菜单”页签里把事务码、报表、权限对象挂进角色再在“权限”页签点“生成”系统据此推导出需要的权限对象清单最后在“用户”页签把账号挂上去。这里的顺序不能反先改菜单再生成权限只改用户不重新生成权限不会生效。角色改完之后的批量分发用 SU10。它的价值在于一次选中多个用户把角色或参数文件统一增删避免一个个进 SU01 点。SU10 批量操作步骤 1. 输入用户名单或用通配符匹配如 MYCW* 2. 选择“角色”页签添加或删除目标角色 3. 勾选“比较”执行 4. 到结果列表里确认每个用户的状态为成功参数上唯一需要注意的是“比较”开关。勾选它系统会把用户当前的角色和目标角色做差集只处理差异部分不勾选则直接覆盖。覆盖模式在批量收回权限时更直接但如果用户身上有临时加的额外角色会被一并清掉恢复起来很麻烦。我的习惯是默认勾选比较只在明确要“重置为某个标准角色集”时才用覆盖。2.3 SU53 权限检查定位失败的真正原因用户说“我进不去”直接给权限是错的先看 SU53。这个事务码显示当前用户最近一次权限检查失败的完整链路失败的是哪个权限对象、哪个权限字段、需要什么值、用户实际有什么值。它只保留最近一次结果所以有两个操作要点一是让用户在报错后立刻打开 SU53不要继续点别的操作否则记录被覆盖二是 SU53 显示的是用户自己的检查结果管理员要诊断别人的问题得让对应用户配合或者用 SU53 的“为其他用户评估”功能传入用户名。拿到对象和字段之后回到 PFCG 的角色里补对应的权限值重新生成角色再让用户重新登录。这里有个常见误区改完角色就以为生效了实际上用户的权限缓冲区要重新登录才会刷新不重新登录的话 SU53 还是老结果会让人误以为没改对。权限对象本身如果要新增或调整才会动到 SU21权限类与对象、SU20权限字段、SU22事务码对应的授权对象这三个底层事务码。日常运维基本不碰它们因为改动权限对象属于跨系统的设计变更必须走传输。3. 集团与数据库SCCL 拷贝和 DB13 巡检的落地细节集团Client是 SAP 里隔离数据的逻辑单位开发、测试、生产通常各占一个。日常会遇到两类需求把生产数据刷到测试集团做验证或者新建一个集团给外部团队用。数据库侧则是每天必须确认的事——备份跑没跑、表空间涨没涨。3.1 SCCL 拷贝集团先看清楚要覆盖什么SCCL 是集团拷贝的入口配置项不多但每一个都会影响结果。参数作用常用取值与说明源集团数据来源生产或质量集团需确认该集团允许作为源目标集团被覆盖的集团目标集团的全部业务数据会被清空重写拷贝配置文件决定拷贝哪些表SAP_ALL 全量SAP_APPL 仅应用数据SAP_USER 仅用户主数据并行进程数加快拷贝速度按数据库服务器 CPU 核数取一般 48源集团是否可覆盖控制开关目标集团的 SCC4 里必须允许“集团无关对象”被覆盖选择配置文件是这一步最关键的决定。SAP_ALL 把所有表都拷过来包括用户主数据代价是目标集团的本地账号全部丢失SAP_USER 只拷用户和权限适合“数据已经是新的、只想同步权限”的场景SAP_APPL 跳过用户和权限是刷数据时最常用的选择因为能保住目标集团自己的测试账号。跑之前务必确认目标集团没有人在用拷贝开始后目标集团会被锁定中途取消会留下半成品。拷贝完成后有两件收尾工作常被漏掉。一是检查 SCC3 里的拷贝日志确认每个阶段的返回码二是核对目标集团里的逻辑系统名如果目标集团要做跨系统接口逻辑系统名不匹配会导致后续所有 RFC 调用失败而这个问题往往在几天后才暴露。3.2 SCC4 与 SCC1集团属性控制和单请求传输SCC4 管的是集团本身的属性最重要的开关是“集团角色”和“更改是否允许”。生产集团设成“不允许更改”可以挡住大部分误操作但也会挡住紧急修复所以通常还要配合一个“允许更改但记录”的中间态具体取哪个值取决于团队的变更规范。SCC1 用来在系统内把单个传输请求从一个集团导入另一个集团和 STMS 的跨系统传输是两回事。典型场景在开发集团改了一个配置想马上验证到测试集团又不想走完整的发布流程就用 SCC1 指定请求号加目标集团。它同样要求目标集团的 SCC4 允许覆盖且请求必须是已释放状态未释放的请求 SCC1 读不到。3.3 DB13 与 DB02日常巡检的两块表DB13 是数据库维护日历本质是一个集中管理数据库相关后台作业的调度面板。日常最常看的是三件事昨晚的备份作业是否成功、数据库检查CHECK DATABASE的执行结果、优化统计信息是否按时更新。每一项点进去都能看到作业日志失败时日志里会有具体的错误码。DB02 是容量视角的监控。它给出表空间的当前大小、使用量、增长趋势以及索引的碎片情况。日常巡检只需要盯两条表空间使用率是否超过阈值、是否有表的增长速度异常。碎片问题一般不做实时处理攒到维护窗口再重建因为在线重建大表索引对系统负载的影响不容忽视。日常数据库巡检顺序建议固化成检查表 1. DB13 看夜间备份作业状态失败则立刻查日志 2. DB12 核对备份日志与日志目录剩余空间 3. DB02 看表空间使用率与增长趋势 4. DB13 看优化统计作业是否按时完成 5. 异常项记入值班记录附作业名和错误码DB12 和 DB13 的关系容易搞混DB12 是备份日志的查看入口展示的是备份动作本身的成功与否DB13 是调度和总览。查问题时从 DB12 拿到备份文件路径和时间戳再对照操作系统的日志目录才能确认备份文件真的落了盘。4. 监控与排障ST22、SM37、SM50 的联动读法监控类事务码有十几个一个个看会淹没在信息里。实践中真正需要形成联动的只有几组应用层报错看 ST22 和 SM21作业层看 SM37 和 SM50资源层看 ST06 和 ST03。4.1 ST22 短存储每天必看的第一屏ST22 记录 ABAP 程序运行时的 dump。判断一个 dump 是否需要处理看三个字段发生时间、程序名、错误类型。如果是标准程序在有规律的时间点报同一个错通常是数据或参数问题如果是自开发程序高频报错基本可以确定是代码缺陷需要转给开发。日常操作上有个技巧不要只看当天的列表用 ST22 的筛选条件按“用户”或“程序”聚合能快速识别出反复出错的源头。一个程序一天报几十次 dump对系统性能的影响是实打实的它会拖慢对话进程的响应。排查顺序上先看 dump 详情里的“错误分析”段落那里会直接点出是哪一行、哪个变量为空或者越界再看“调用栈”确认是从哪个事务码进来的。如果 dump 集中在某个时间段配合 SM21 的系统日志看那个时间点有没有异常事件。4.2 SM37 后台作业取消的作业才是重点SM37 的界面里真正需要关注的是状态为“已取消”的作业而不是“已完成”。已完成说明正常结束已取消意味着作业中途异常终止通常伴随 spool 里的错误信息。SM37 的处理路径 1. 选择作业名可用 * 通配和时间范围勾选“已取消”状态 2. 选中作业 → 作业日志看具体在哪一步失败 3. 若是程序错误日志里会有 ABAP 运行时错误转 ST22 看详情 4. 若是资源不足如内存溢出需要调整作业的服务器组或拆分数据量 5. 修正后不要直接复制旧的作业先确认作业的变式和参数是否仍然正确这里有个血泪经验作业被取消后很多人第一反应是“重跑一次”但如果失败原因是数据量超出预期重跑只会再失败一次还可能把系统资源占满。正确做法是先看作业的 spool 输出和运行时长判断是偶发还是趋势性增长。SM36 是作业定义的入口日常用得比对 SM37 少但有一个场景必须熟悉新建周期性作业时开始条件要选“立即”还是“计划”取决于它是否需要依赖前置作业完成。默认选“立即”的作业不会等待前置作业链式依赖会断表现出来就是凌晨的报表跑出来是空的。4.3 SM50、SM66 与 SM12进程和锁SM50 显示当前应用服务器的进程状态最直观的用法是找长时间处于“运行”状态的对话进程。一个对话进程跑了几十分钟基本可以断定是用户执行了没有优化的大报表或者程序进入了死循环。处理方式是先确认是哪个用户、哪个事务码、哪张表再和用户沟通后终止。SM66 是全局视角一次看所有应用服务器的进程适合系统有多台应用服务器时快速定位是哪个节点在忙。SM12 是锁管理用户断线或程序异常退出后会留下锁条目表现为“别人改不了这条数据”。处理锁之前必须确认持有锁的会话已经不存在否则删了锁会让两个会话同时改一条数据后果比锁着更严重。4.4 ST06 与 ST03先有基线才谈得上判断ST06 是操作系统层面的资源视图CPU 使用率、内存、交换空间、文件系统占用。日常巡检看的是趋势单次快照没有意义。ST03 是 SAP 自身的负载分析包含响应时间、数据库时间、用户分布。这两者的使用有个前提必须在系统正常的时候采集基线数据。平时记录下工作日的典型 CPU 曲线、典型对话响应时间等到某天用户抱怨“系统变慢了”把当期数据和基线一对比立刻能判断是整体变慢还是某个时段尖峰。没有基线的话看到 CPU 70% 也不知道算不算高只能凭感觉这正是运维里最不该出现的情况。5. 避坑与常见问题这五个坑几乎每个人都踩过5.1 权限改完不生效SU53 还是旧的失败记录现象PFCG 里补了权限角色也生成了用户反馈还是进不去SU53 显示同样的失败对象。原因用户的权限缓冲区在登录时加载改角色不会主动刷新已有会话同时 SU53 只记录最近一次检查结果用户没有重新触发操作看到的仍是旧记录。解决让用户完全退出系统再登录重新执行一次报错的操作再看 SU53。批量场景下可以用 SM04 确认该用户会话已断开避免以为退了实际还在。5.2 SCCL 拷完目标集团里所有人的账号都没了现象集团拷贝成功日志全绿但测试团队登录不上提示用户不存在。原因拷贝配置文件选了 SAP_ALL用户主数据被源集团覆盖目标集团原有的本地账号全部被替换。解决刷数据场景改用 SAP_APPL 配置文件跳过用户和权限表。如果已经覆盖只能从备份恢复用户主数据或者重新按清单建账号代价很大所以选配置文件这一步必须在执行前确认。5.3 SM37 里作业显示已完成业务数据却没出来现象夜间作业状态是已完成但下游报表数据缺失。原因作业本身执行成功但它调用的程序逻辑里捕获了异常并正常返回实际没有写入数据或者作业的变式参数被改动过取数范围变成了空集。解决不能只看状态必须打开 spool 输出核对实际处理条数。对关键作业设一个校验步骤比如在作业链末尾加一个统计行数的程序行数为零就发告警。5.4 ST22 里 dump 一堆修完一个又冒一个现象每天都有 dump逐个分析耗时巨大修完一个另一个又出现。原因没有做聚合分析把互不相关的偶发 dump 当成独立问题处理或者某个公共函数被多个程序调用根因只有一个但表现分散。解决先按程序名和时间段聚合找出高频项再看调用栈里是否有共同的底层函数。优先处理高频和集中在业务高峰期的 dump低频偶发项记录下来观察。5.5 参数用 RZ10 改了重启后回退现象用 RZ10 修改了系统参数当前生效系统重启后变回原值。原因RZ10 修改的是实例参数文件如果没有保存并激活或者改的是默认参数文件而实例参数文件里有同名覆盖项重启就会以实例文件为准。解决改完用 RZ11 在线确认当前生效值同时检查实例参数文件是否有同名条目。跨系统的参数变更要走传输不要在各环境手工各改一遍否则三个环境的参数迟早不一致。6. 把巡检固化成习惯一份可复用的每日检查顺序事务码记住了不等于会用。我见过不少同行能把 SM50、ST22、DB13 说得头头是道真到值班时还是手忙脚乱因为脑子里没有固定顺序看到告警才去翻永远在救火。这一章给一个可以直接照着走的顺序以及两个提升效率的具体技巧。每日巡检我一般分三段早上上班后二十分钟内跑完前两段时段检查项事务码判定标准上班后夜间作业是否有取消SM37取消数为零或有已知原因的记录上班后备份是否成功DB13 / DB12状态成功日志目录空间充足上班后当日 dump 概况ST22无新增高频程序上午表空间与增长DB02使用率低于阈值上午系统日志告警SM21无未处理的错误条目随时进程与锁SM50 / SM66 / SM12无长时间运行进程、无残留锁下班前传输队列STMS无卡住的请求两个具体技巧。第一个是把关键检查项做成一个自定义的报表或事务码集合用 SE93 包一个入口点一次就能依次跳到 SM37、ST22、DB13。这件事花不了多少时间但把“记得去看”变成了“点一下就看了”坚持率会明显不一样。第二个技巧是日志目录的核对要落到操作系统层面。SAP 自己的事务码只能看到系统认为的状态文件到底有没有落盘必须去操作系统确认# 传输日志目录确认最近的传输是否有报错 ls -lt /usr/sap/trans/log/ | head -20 # 进程日志目录dev_disp 里记录实例启动和进程异常 tail -200 /usr/sap/SID/DVEBMGS00/work/dev_disp # 数据库后台日志目录备份与归档的原始记录 ls -lt /oracle/SID/saptrace/background/ | head -20三段命令的用途不同传输日志看导入是否完整dev_disp 看实例层面的启动、重启和进程崩溃数据库后台日志看备份与归档的真实执行情况。路径里的SID要替换成实际系统标识别直接抄。STMS 里显示传输成功但操作系统日志里如果有报错行说明部分对象被跳过这种情况在生产系统上必须追到底。还有一个容易被忽略的点ST03 的负载数据要定期导出归档。系统默认只保留有限天数的统计数据等到出了性能问题再回头找“上个月正常时是什么样”数据往往已经被清理了。我一般每月导出一次按月份命名存到共享目录这个习惯在两次性能排查里救过场因为没有基线数据性能问题基本只能靠猜。从那以后我每次接手一套新系统第一件事不是看配置而是先跑一遍完整巡检、把结果存成基线再开始改任何东西。有了这份基线后面所有“系统变慢了”“作业变久了”的判断才有参照。希望帮到你。本文还有配套的精品资源点击获取