简介这份资源面向SAP系统管理员、Basis初学者及需要承担日常运维工作的IT人员系统梳理了SAP Basis岗位的职责边界与高频事务代码可用于岗位入门、日常操作对照和运维排错参考。压缩包内为1个PDF文件大小约2.02MB属于轻量级速查手册便于在电脑或移动端随时翻阅。内容按用户权限管理、集团管理、数据库管理、后台作业、打印管理、系统监控、传输管理等模块组织逐条列出SU01、PFCG、SCCL、DB13、SM36、SPAD、ST03、STMS等常用事务代码及其用途并补充了启动日志、进程日志、数据库日志等日志路径的查看位置同时对实施与运维两类Basis工作方向的区别、数据库备份还原的重要性做了说明。已有962人浏览学习适合希望用较短时间建立Basis运维知识框架、随手查阅事务代码含义的读者。1. SAP BASIS 日常运维到底是什么一份内训命令清单背后的一天凌晨三点数据库备份作业报错早上八点用户说登不上系统九点业务部门催一张报表打印不出来——这就是 SAP BASIS 运维最真实的一天。手头这份内训资料的价值不在概念讲得多全而在于它把散落在九个大类里的几十个事务代码按场景归了位用户权限、集团管理、数据库、后台作业、打印、系统监控、传输管理、参数维护和日志路径。新手拿到它至少知道第一天该点开哪几个码熟手拿它当值班清单也能补上平时容易漏掉的检查项。它适合刚接手 SAP 系统管理的运维人员、从其他模块转 BASIS 的人以及需要给团队新人做带教材料的负责人。要提醒一句事务代码只是入口真正决定你处理得快不快的是每个码背后的判断顺序和边界。2. 用户权限与角色SU01、SU10、PFCG 谁先动、谁后动权限问题在 BASIS 值班里占比最高也最容易背锅。用户说登不上、说看不到某个按钮、说某张报表跑出来是空的八成最后都落到权限上。这一章把 SU01、SU10、PFCG、SU53、SU21、SU20、SU22 这几个码串成一条线讲清它们的先后关系避免新人上来就给个 SAP_ALL 先跑起来。2.1 先把权限模型四层摆清楚用户、角色、权限对象、字段SAP 的权限不是直接挂在人身上的它是四层结构用户主数据SU01→ 角色PFCG→ 权限对象SU21→ 权限字段SU20。用户通过被分配到角色角色在生成时展开成一批授权对象和字段值系统在做权限检查时拿这些字段值去比对。理解了这个层次很多现象就说得通了。为什么给用户加了角色还要点用户比较因为角色改了以后用户主记录里挂的那份参数文件还是旧的。为什么有的角色复制过去权限少了因为复制只复制角色定义授权数据要重新生成。为什么同一个事务码在不同系统表现不一样因为事务代码和授权对象的对应关系SU22 维护的那部分在系统间可能有差异。我一般带新人的顺序是先在 SU21 里随便找一个权限对象看它有哪些字段这些字段就是 SU20 维护的东西再打开一个角色看这些字段被填成什么值最后回到 SU01 看用户挂了哪些角色。这个顺序走一遍比看十页 PPT 都快。2.2 复制账号与解锁改密SU01 的实操顺序和批量替代方案SU01 是最常开的码也是最容易点错的地方。加锁、解锁、改密码、复制账号四个动作都在同一个界面但改错页签的后果不一样。手工操作的顺序我一般按下面来输入目标用户名回车进入用户主数据先看登录数据页签里的用户状态和锁定标记确认是锁定还是密码错误解锁只需要清掉锁定标记并保存不要顺手重置密码否则用户下次登录会被强制改密反而多一轮沟通复制账号时先在 SU01 输入新用户名点复制按钮再把源用户比如已存在的一个同岗位账号填进来源字段勾选要带过去的角色和参数文件保存后立刻用新账号登录一次做验证重点看它能不能进到源账号常去的那个事务码而不是只看登录成功。复制账号有一个高频翻车点源账号里可能挂着一些历史遗留角色或者是通过用户组继承来的权限复制时未必全带过去。稳妥做法是复制完在新账号里跑一次关键事务码让系统把权限检查失败记下来再用 SU53 看。批量场景用 SU10。比如一次入职十几个人、或者一批账号需要统一改用户组、统一锁定SU10 可以输入多个用户名一次性改用户组、锁定状态、删除标记。它不适合做批量加同一个角色那种需求还是走 PFCG 的角色用户页签或者走 HR 集成别硬用 SU10 绕。提示SU10 的批量修改不能撤销执行前把用户名列表导出来存一份出问题至少知道动了哪些账号。2.3 用户说没权限时的定位链SU53 → PFCG → SU22 → SU24用户报没权限最忌讳的是直接凭印象加角色。正确的入口是 SU53——它显示当前用户最近一次权限检查失败的对象和字段值。这里有三个必须知道的边界第一SU53 显示的是最近一次用户如果出错之后又点了几下别的东西记录就被覆盖了。所以我要求用户出错后立刻截 SU53 的图或者干脆让他在同一个会话里先别动。第二SU53 是用户视角的BASIS 自己跑 SU53 看到的是自己的失败记录不是用户的。要么让用户自己跑要么用 SU53 的变式配合用户查询要么直接从 ST22 或者 SM20 里找线索。第三看到失败对象之后不要急着加先判断是角色缺对象还是对象有了但字段值不够。常见情况是角色里有这个权限对象但某个组织级别的字段被填成了某一个工厂或公司代码用户实际要访问的是另一个这种时候改字段值比加角色干净得多。PFCG 里改完角色一定要走用户比较把变更同步到已分配的用户主记录上否则改了等于没改。这一步漏掉是新人最常见的改了没生效。再往后就是 SU22/SU24 这一层事务代码执行时会去查它对应的授权对象默认值这个对应关系如果维护得不全你在 PFCG 里生成角色时就看不到某个对象用户自然拿不到权限。SU22 用来维护事务代码的授权对象日常运维里用得不算多但做权限梳理和新建角色时会碰。我的经验是遇到这个事务码明明有权限却还是报检查失败先怀疑对应关系再去怀疑角色本身。3. 集团拷贝与传输请求SCCL 之前先过 SCC4 这一关集团Client是 SAP 里最容易被误解的概念之一。它不是数据库也不是公司而是一套数据的逻辑隔离。同一个系统里可以有多个集团测试数据和生产数据靠它分开。SCC4 管属性SCCL 做拷贝SCC3 看日志SCC1 按请求导入SCC5 删除SE09 释放请求STMS 管传输队列——这几个码串起来就是 BASIS 最核心的一条操作链。3.1 SCC4 里三个开关决定这次拷贝能不能做打开 SCC4一个集团有几项属性必须先看属性取值对拷贝的影响集团角色定制 / 测试 / 生产 / 演示决定该集团允许做哪类变更生产角色下很多变更被限制集团独立对象的更改自动记录更改 / 无自动记录 / 不允许更改决定变更是否生成传输请求拷贝前必须与目标集团一致或允许跨集团对象的更改允许 / 不允许影响跨集团表的维护权限保护级别无 / 级别 1 / 2 / 3高保护级别下限制登录和访问拷贝之前最常犯的错是源集团或目标集团的更改开关设成了不允许更改SCCL 跑起来直接报错或者跑到一半停住。我的做法是在 SCC4 里把两边都确认一遍特别是新建的集团默认属性往往不是你要的。另一件事是目标集团里如果有用户正在登录拷贝会失败或者被卡住。拷贝前把目标集团锁掉、把在线用户清掉是标准动作。3.2 SCCL 拷贝 SCC3 日志核对卡在哪一步看哪一行SCCL 的界面看起来很朴素源集团、目标集团、要拷贝的配置文件和表。真正决定成败的是后面那几个参数。配置文件决定拷贝范围。常见的几个选择是从仅用户主数据到SAP_ALL级别的全量拷贝。这里有个血泪经验不要在没有确认的情况下选全量。一个中等规模系统的全量集团拷贝可能跑几个小时中途出错重来成本很高而且目标集团原有的数据会被覆盖。拷贝过程中SCCL 自己的界面只能看个大概进度真正的细节在 SCC3 里。SCC3 列出历史上所有集团相关的操作拷贝、传输、删除点进去能看到每一步的执行状态和返回码。我的习惯是拷贝完成后不急着交给业务先在 SCC3 里把最后几条记录的返回码过一遍任何非零返回码都要追。拷贝完成后还有几件收尾的事容易被忘目标集团里被拷贝过来的用户密码是源集团的密码业务方拿到手登录不了通常要用一个有权限的账号进去重置或者用 SAP* 应急账号处理处理完立刻禁用目标集团的逻辑系统、RFC 连接、打印设备指向的可能还是源系统的配置得按目标系统的环境重新核对拷贝会覆盖目标集团原有的后台作业如果那边有定时任务得重新排。SCC1 是同一个系统内按传输请求号把变更从一个集团导到另一个集团适合小范围同步不适合大规模拷贝。用它的时候要注意这个请求必须已经释放没释放的请求导不进去。SCC5 删除集团前面必须先在 SCC4 里把这个集团的状态调整到允许删除而且系统自带的几个集团是删不掉的。删之前做一次完整备份这是底线。3.3 SE09 释放与 STMS 导入队列请求卡住时先看这四处传输是 BASIS 里最需要耐心的活。SE09 管请求和任务的释放STMS 管系统之间的路由和队列。新人最容易卡在我释放了但目标系统没过去。先理清释放顺序一个传输请求下面挂着若干任务任务的释放要先于请求的释放。请求一旦释放内容就冻住了想改只能新建请求。所以释放之前先确认开发那边确实把东西改完了。请求释放后进入 STMS 的导入队列。队列里能看到它处于哪个状态、有没有前置依赖、有没有被标记为可导入。如果一直不动我按四个地方查STMS 里的系统路由是否通目标系统在传输域里是否在线传输目录 /usr/sap/trans 在源和目标两边的共享是否正常磁盘有没有满队列里是否有更早的请求失败了后面的请求会跟着堵导入日志里的具体报错通常在 /usr/sap/trans/log 下。命令行层面我常备这么几条# 以 sidadm 或传输管理员身份执行 export TRANS_DIR/usr/sap/trans # 1. 看日志目录里最近的传输日志文件 ls -lt $TRANS_DIR/log | head -20 # 2. 看传输告警汇总文件最后几行通常是最近的失败 tail -50 $TRANS_DIR/log/ALERT.SID # 3. 看传输缓冲区里挂了哪些请求确认目标系统是否已收到 cd $TRANS_DIR/bin tp showbuffer SID # 4. 手动导入一个请求一般只在脚本化或图形界面不可用时用 tp import SID TRKORR CLIENT Usapadm参数说明SID换成三位系统标识TRKORR是请求号形如 SIDK900123CLIENT是目标集团号。tp import后面的U参数表示以某个系统用户身份执行只在权限受限时加日常手动导入建议还是走 STMS 图形界面因为命令行导入不会在 STMS 队列里留下完整的可追溯记录出事后不好复盘。注意手动tp import之前一定先tp showbuffer确认请求确实在缓冲区里直接从文件系统拷请求目录过去是无效的SAP 认的是缓冲区的登记信息。4. 数据库、后台作业与打印DB13 建、DB12 验、SM37 兜底前面两章管的是人和数据怎么进来这一章管的是系统每天自己该干的活有没有干成。数据库备份、后台作业、打印输出这三块是 BASIS 值班里最有规律可循的部分也是最容易因为昨天好好的而漏检的部分。4.1 DB13 维护日历不是设完就不管DB12 与 DB02 的交叉验证DB13 是数据库日常维护的日历视图把备份、数据库检查、优化统计更新这些周期性动作集中排程。它的价值在于统一入口缺点是设完之后太安静——成功了不出声失败了也不一定有人看。所以每天早上的固定动作是打开 DB12 看备份日志昨天夜里的备份有没有跑、耗时多久、日志目录还剩多少空间。DB12 里能看到备份历史点进去看详细日志重点关注备份大小有没有异常波动突然变小可能是备份提前中断以及日志目录的剩余空间空间不足是老系统最常见的备份失败原因。DB02 是另一层验证表和索引的增长情况、碎片情况、数据库优化统计。备份成功不代表数据库健康如果某张表一夜之间涨了几个 G或者某个索引碎片率高得离谱问题会在几天后以性能的形式爆出来。我的习惯是每周导一次 DB02 里的主要表空间增长率做一条自己看的趋势线比事后救火划算得多。操作系统层面还有 BRTOOLS。它在数据库主机上运行是图形化的菜单工具也能用命令行调用# 以数据库管理员用户执行SID 换成实际系统标识 # 1. 只显示当前配置不做任何实际操作 brbackup -p initSID.sap -c show # 2. 执行一次在线全库备份 brbackup -p initSID.sap -t online -m full -c force参数说明-p指定配置文件通常是initSID.sap里面定义了备份路径、并行度、备份方式-c show只做配置展示用来在动手前确认参数没被改过-t online表示在线备份数据库保持打开-m full是全量-c force表示跳过前置检查强制执行这个参数平时不要用它跳过检查的正是数据库状态是否正常备份目录是否有空间这类关键校验只在排障时临时用用完记得记录原因。4.2 后台作业SM36 定义、SM37 复盘取消作业怎么分析SM36 定义后台作业要填的是作业名、作业类、目标服务器、步骤和开始条件。作业类里 A 是高优先级、B 是中、C 是低别把所有作业都设成 A那等于没有优先级。开始条件可以设立即、指定日期时间、或者跟在某个作业之后后一种在做有依赖关系的批处理时特别有用。SM37 是复盘的地方。选作业名、用户名、时间范围和状态重点看两类已取消的和运行时间异常长的。一个作业被取消作业日志里通常有 ABAP 运行时的报错配合 ST22 能看到更完整的 dump 信息。这里有一个常被忽略的细节作业的 Spool 输出列表。有些作业成功结束了但输出列表里是空白的或者内容是报错文本——业务方看到的就是报表跑出来没数据。所以对关键报表类作业不能只看状态要看输出。后台作业的异常我习惯用一条 SQL 快速过一遍最近一周的情况在生产库上执行前先确认权限和时段别在业务高峰跑全表-- 查最近七天非正常结束的后台作业TBTCO 是作业头表 SELECT jobname, jobcount, sdlstrtdt, -- 计划开始日期 sdlstrttm, -- 计划开始时间 status -- P 已调度 / S 已释放 / R 运行中 / F 已完成 / A 已取消 FROM tbtco WHERE status IN (A) AND sdlstrtdt to_char(sysdate - 7, YYYYMMDD) ORDER BY sdlstrtdt DESC;这条查询只挑已取消的作业。字段含义上jobcount是作业编号同一个作业名每次跑都会生成新的编号定位具体某一次执行时要靠它sdlstrtdt和sdlstrttm是计划时间不是实际时间实际时间在strtdate、strttime里。如果想把完成但耗时异常的也筛出来需要再关联作业运行时的统计信息那是另一个层级的排查了。4.3 打印SP01 的假脱机请求和 TemSe 清理边界打印问题的特点是看起来很简单查起来很绕。SPAD 定义打印设备SP01 管假脱机请求和输出请求两条线要分开看SPAD 里设备配错了所有走这个设备的打印全失败SP01 里某个请求卡住了只影响那一份。用户报打不出来我的顺序是先在 SP01 里按用户和时间找到那条假脱机请求看它处于什么状态。如果是已完成说明系统这边已经把它交给输出控制器了问题在用户端最常见的两个原因是本机的打印服务程序没启动、或者打印机队列里堆着别的任务。如果是处理中卡住看输出控制器的状态和目标设备。这里有一个必须知道的边界SAP 只跟踪打印任务到目标队列这一步输出控制器里显示完成不代表纸真的打出来了。所以重要打印任务尤其是大批量的在从 TemSe 里删掉之前要人工确认。SP01 里删除假脱机请求是不可逆的删完想重打只能重跑业务操作。TemSe 会随打印量增长定期清理是必要的但清理策略要跟业务确认保留多少天的已完成请求、报错请求保留多久。我见过清理太激进导致对账时找不到历史打印记录的情况也见过从来不清理导致 TemSe 目录撑爆磁盘的。折中的做法是按天保留重要单据类打印单独延长。5. 排查与避坑值班时最常见的五类故障怎么定位监控这块资料里列了 ST06、ST03、SM04、AL08、SM21、SM51、SM50、SM12、SM13、ST22、SM20、SM66 一长串。新人容易犯的错是每天早上把这些码挨个点一遍点完什么印象都没有。我的做法是先建立基线再针对异常去查。5.1 监控基线ST06、ST03、SM50、SM66 该记什么数ST06 看操作系统层CPU 使用率、内存、页交换、文件系统。不要只看瞬时值看趋势。页交换持续不为零说明内存已经吃紧ST06 里那个值比 CPU 更能预示麻烦。ST03新版本是 ST03N看工作负载响应时间分布、数据库请求时间、用户分布。这份资料里有一句话说得很到位——要在系统没出问题的时候把数据留下来。我每周固定导一次 ST03 的汇总攒上两个月你就有了判断今天是不是真的慢的依据而不是靠用户说感觉慢。SM50 看当前应用服务器的工作进程重点看有没有长时间占着的对话进程或后台进程。SM66 是跨服务器的全局进程概览排查到底是哪个服务器卡了时比 SM50 方便。看到异常进程先用 SM50 里的结束功能之前先跟用户确认——这一点资料里专门提了但实际值班时最容易被跳过。SM04 和 AL08 的区别是服务器相关和无关SM04 只看当前登录的这台应用服务器AL08 看所有服务器。要查某个用户到底在哪台机器上用 AL08。5.2 五条现象 → 原因 → 解决的踩坑记录第一条ST22 里短存储每天几十条用户说偶尔报错。现象用户操作时偶尔弹出运行时错误点过去之后又能继续ST22 里按日期筛同类 dump 重复出现。原因多数情况下是某个自开发报表在取数时没有做空值判断或者数据量大了之后内存溢出也有可能是标准程序在特定数据条件下的边界问题。解决按 dump 的程序名和发生次数排序先挑重复次数最多的那个看调用栈。如果是自开发程序转给开发同时在 dump 明细里把程序名 行号 触发条件记下来别只说又报错了。如果是标准程序先确认是不是某个增强或出口改坏了。第二条SM12 里积压了大量锁用户说保存不了。现象用户点保存后界面一直转最后报对象被锁定。原因上一个会话异常终止断网、关浏览器、程序崩溃后锁没有被释放。解决先在 SM12 里按用户名筛选确认这个用户当前确实没有活动会话SM04 里查一遍再删除锁。不要在没确认的情况下成批删锁那可能把正在正常处理的业务数据搞坏。删完让用户重试如果同一个对象反复被锁要去查是不是程序逻辑本身有问题。第三条SM13 里出现失败的更新记录业务数据没落库。现象用户说我明明保存了但查不到。原因SAP 的更新分同步更新V1和异步更新V2V1 失败意味着业务数据根本没写进数据库。解决SM13 里按时间筛失败的更新看更新模块和报错。生产系统里失败的更新是必须当天处理的先确认影响的数据范围再决定是重新激活更新还是让业务补录。处理完把这次的错误码和更新模块记进团队的问题库同类问题下次能快很多。第四条系统日志里大量告警但用户没反馈问题。现象SM21 里某段时间集中出现警告甚至有一些错误。原因可能是某个 RFC 连接间歇性断开、某个后台作业反复重试、或者安全审计相关的登录失败。解决SM21 里按严重级别和时间段筛选把错误按消息号聚类看哪个消息号出现最多。常见的登录失败消息号如果集中在同一个来源要确认是不是有应用在拿错误的密码反复重试这类问题不处理会锁账号。第五条集团拷贝成功了但业务方进不去。现象SCCL 显示完成SCC3 里返回码都是零业务方登录报用户或密码错误。原因拷贝把源集团的用户主数据覆盖过来了密码是源的另外目标集团原有的 RFC 连接、逻辑系统可能还指向旧环境。解决先用有权限的账号进去重置关键用户密码再核对逻辑系统和 RFC 连接。下次拷贝前把这三件事写进检查清单密码重置方案、连接核对、后台作业重排。这条教训我吃过不止一次。5.3 日志目录与一个能跑的巡检脚本图形界面之外操作系统层面的日志是排障的另一半。资料里给的路径基本靠谱我按实际用法补一下日志类型典型路径看什么启动与调度器日志/home/sidadm 下的启动脚本输出实例启动阶段的报错工作进程日志/usr/sap/SID/DVEBMGS00/workdev_disp、dev_ms、dev_rfc、dev_w*传输日志/usr/sap/trans/logALERT.SID 和每次导入的日志数据库后台日志Oracle 的 saptrace/background 目录归档、检查点、ORA- 错误把这些检查固化成脚本比每天手动点一遍可靠#!/bin/bash # sap_daily_check.sh —— 以 sidadm 身份运行输出当日巡检快照 SIDSID WORK/usr/sap/$SID/DVEBMGS00/work TRANSLOG/usr/sap/trans/log OUT/tmp/sap_check_$(date %Y%m%d).log echo 巡检时间: $(date) $OUT echo --- 文件系统使用率超过 80% 的分区 --- $OUT df -hP | awk NR1 || $5080 $OUT echo --- 调度器日志中的错误计数 --- $OUT grep -ci error $WORK/dev_disp 2/dev/null $OUT echo --- 传输告警文件最近修改时间 --- $OUT ls -lt $TRANSLOG/ALERT.* 2/dev/null | head -5 $OUT echo --- 最近的数据库备份日志尾部 --- $OUT tail -20 /oracle/$SID/saptrace/background/alert_$SID.log 2/dev/null $OUT脚本逻辑说明整段以$SID作为唯一变量换系统只改一处df -hP的-P保证输出格式固定awk里$50把百分比字符串强制转成数值再比较避免字符串比较出错grep -ci只输出计数不刷屏所有输出追加到按日期命名的文件里方便回溯。参数上要按实际环境改三处DVEBMGS00是集中式安装的实例目录名分布式部署下要换成对应的实例编号Oracle 的 alert 日志路径在不同版本里可能是bdump或saptrace/background先手动ls确认/tmp在部分生产环境会被定期清理正式用的时候换成持久目录。注意脚本里不要加任何自动删日志、自动清 TemSe、自动删锁的动作。巡检脚本只读不写这个边界守住了它才不会在某天变成事故源头。6. 从手工点事务码到值班基线把巡检变成可验证的脚本第六章落到一个具体技巧把上面这些事务码的看一眼变成有基线、能对比的动作。先说参数。RZ11 查参数能看到当前值、默认值、以及这个参数是动态生效还是必须重启。RZ10 改参数改完保存只是写进了参数文件要不要重启取决于参数类型。我见过最常见的翻车是在 RZ10 里改了一个需要重启的参数以为立刻生效结果观察了半小时没变化又改了一遍最后配置文件里堆了三条冲突记录。所以改参数的顺序固定为RZ11 查当前值和生效方式 → 确认业务窗口 → RZ10 修改 → 保存后确认写进了哪个参数文件默认实例参数文件还是 DEFAULT→ 需要重启的排进窗口 → 重启后用 RZ11 复验。RZ10 里改坏参数导致实例起不来的情况不是没有改之前把参数文件备份一份就是后悔药。再说巡检的落地。上面那个脚本放到sidadm的 crontab 里每天固定时间跑# 以 sidadm 身份执行 crontab -e加入下面这行 30 7 * * * /usr/local/bin/sap_daily_check.sh /dev/null 21字段含义第 1 位是分钟第 2 位是小时后面依次是日、月、星期五个*表示每天 7:30 执行。重定向到/dev/null是为了不让 cron 每天发一封空邮件脚本自己会把结果写进日志文件。光有脚本不够还得有对比。我一般维护一张极简的表每天记文件系统最高使用率、ST22 当天 dump 条数、SM13 失败更新条数、SM37 取消作业数、ST06 的页交换情况。五个数填一周就能看出这台机器的正常值在哪超出范围再去看细节。这套东西不高级但它把感觉今天有点慢变成了今天的页交换是平时的三倍。这些做法没有一条是资料里现成写好的都是从看到告警才去查变成每天有数可看的过程。我刚开始做 BASIS 那阵子最常干的事就是等用户报错然后手忙脚乱地翻事务码直到有一次一个备份失败连续三天没人发现等到需要恢复的时候才发现最近一次可用备份是一周前的。从那以后我每次接手一套新系统第一件事都是把巡检脚本和基线表建起来再干活宁可第一天多花两个小时。希望帮到你。本文还有配套的精品资源点击获取