简介SAP日常运维BASIS是一份面向SAP Basis运维人员与系统管理员的实用操作手册聚焦系统监控、权限分配、后台作业、传输管理等高频日常事务。资源包内为一个PDF文件共1个文件约2.02MB内容以事务代码清单与操作说明为主便于随时检索查阅。文档按模块梳理了常用事务代码用户权限管理涵盖用户创建、修改、解锁、批量变更以及角色权限配置与检查集团管理覆盖集团创建、拷贝、删除和传输请求复制数据库管理关注备份检查、表空间与索引监控、优化统计更新系统监控、后台作业和打印管理也给出对应事务代码与操作要点。同时补充了启动日志、进程日志、传输日志、数据库日志的查看位置以及SP01假脱机失败处理等常见排错思路此外还涉及RZ10参数修改、RZ11参数查询、SM59远程连接配置等进阶操作并针对如何学好SAP BASIS给出建议强调数据备份与还原的重要性。目前已有962人学习使用内容密度高可作为入门与进阶之间的补充材料。1. 运维的晚上十一点谁在看 SAP 的系统日志真正接触 SAP Basis 运维之后你会发现白天的工作节奏属于业务晚上的节奏才属于系统。业务下线后的备份日志、后台作业、传输队列、数据库增长这些全要有人盯着。所谓 Basis 日常运维就是用户权限、集团管理、数据库、后台作业、打印、系统监控、传输管理这几块轮流转核心是保证 SAP 系统稳定、数据安全、用户能干活。这份资源把上述每一个模块的常用事务代码整理成了一套可直接照做的命令地图。适合两类人一类是刚接手 SAP 系统管理、需要快速建立巡检清单的运维新人另一类是已经在做 Basis 实施、想补充日常维护细节的顾问。我按实际运维顺序拆解这份命令清单把每一条事务代码的使用场景、参数细节和踩过的坑都写出来。手边放一份遇到问题至少知道从哪个事务代码进去查。2. 用户权限与集团管理从 SU01 到 SCC42.1 权限链路用户、角色、权限对象是怎么拼起来的SAP 的权限体系不是直接给用户发一堆事务代码而是通过“用户 → 角色 → 授权对象”这条链路来工作。用户主记录SU01决定这个用户能登录哪个集团、用什么账号类型登录角色PFCG决定这个用户能看到哪些菜单、执行哪些事务代码而权限对象与权限字段SU21、SU20则是角色里真正控制“能不能做某个操作”的底层开关。现实中常见的权限排错顺序是这个先用 SU01 检查账号状态再用 SU53 看权限检查失败时到底缺了哪个授权对象最后去 PFCG 里给角色补齐对应权限并重新生成参数文件。SU22 的作用是查看某个事务代码关联了哪些授权对象当业务说“能用 SU01 但用不了某事务码”时用 SU22 对照角色就知道缺在哪。事务代码作用典型使用场景SU01创建、修改、显示用户信息解锁、改密、复制账号SU10批量修改用户批量锁定、批量重置密码PFCG创建、修改、显示角色角色权限维护与生成参数文件SU53权限检查日志查看失败操作缺失的授权对象SU21 / SU20维护权限类、权限对象、权限字段创建自定义权限对象SU22维护事务代码的授权对象对照分析事务代码所需权限SU24给事务代码分配默认授权对象自定义开发功能时常用做日常运维时SU01、SU10、PFCG、SU53 这四件套用得最多。其余几个更多是权限实施阶段的配置工具但运维人员也要熟悉否则遇到“同一事务代码在不同集团权限表现不一致”的情况会无从下手。2.2 SU01 用户维护里的细节解锁、改密、复制账号在 SU01 里运维最常做的是解锁和更改密码。输入用户名回车进入用户主记录后有两个关键位置一个是“登录数据”页签里的“用户类型”和“有效日期”另一个是重复登录失败会触发自动锁定。很多新手只改了密码没注意“有效日期”已经过期用户依然是登录不上的。账号复制是个实用技巧。比如有一个已存在的账号 MYCW12权限都正常新同事需要相同权限可以直接在 SU01 里用“复制”按钮把 MYCW12 复制成 MYCW14再改密码和姓名。这样比重新配角色省事得多但要注意复制完必须检查“参数”和“个性化”页签因为用户参数如默认打印机、输出设备会跟着一起复制过去。批量操作用 SU10。比如一批实习生账号到期用 SU10 按用户组或按日期批量锁定比一个一个进 SU01 快很多。SU10 的操作界面是先选中用户、再选操作类型锁定、解锁、删密码等提交后会生成批量变更日志建议把“记录变更日志”选项打开方便后面追溯是谁在什么时间改了哪些用户。提示任何时候重置密码都要确认用户主记录里的“有效性”范围以及是否勾选了“密码不过期”。只改密码不查这两项很容易被业务反馈“还是登不进”。2.3 集团拷贝SCCL 与 SCC1 的分工集团Client是 SAP 里独立的数据隔离层。SCC4 负责创建和维护集团设置集团角色如生产、测试、培训以及跨集团对象修改的许可。创建新集团时要注意“集团角色”和“更改与传输”属性错误设置会导致后续传输行为异常。拷贝集团有两个不同工具。SCCL 是整体拷贝通常用于把源集团的全配置复制到一个新集团适合新项目实施时初始化配置。SCC1 是单请求拷贝把指定的传输请求内容从一个集团复制到另一个集团适合把某个修正或配置单独带过去。两者的核心区别是范围SCCL 全量、SCC1 增量。删除集团用 SCC5这是个危险操作删除前系统会要求输入集团名称确认。我一般会先把目标集团用 SCC4 标记为不可用再执行删除同时在删除前用 SCC3 查看该集团的复制和传输日志确认没有未处理的请求。集团拷贝的日志怎么看SCC3 里能查到每个集团复制任务的执行状态、时间点和失败步骤。SCCL 跑大集团拷贝时建议使用后台作业执行把并行进程数控制在合理范围否则数据库 I/O 会瞬间打满影响生产系统。3. 数据库与后台作业备份日历、空间增长和作业追踪3.1 数据库维护三板斧DB13、DB12、DB02数据库层面的日常维护最核心的工具是 DB13、DB12、DB02 三个。DB13 是数据库日常维护日历用来定义备份、检查数据库、更新优化统计信息等数据库后台作业。运维要做的不是偶尔打开看一眼而是把备份和检查任务固定成日历每天定时跑。DB12 是数据备份日志入口每天早上的第一件事建议先看它。确认夜间备份是否成功日志目录剩余空间是否够用。备份失败不一定是备份本身的问题日志目录塞满导致归档写不进去也是常见的备份失败原因。DB02 负责数据库表和索引的监控重点看三件事表/索引空间的增长速度、碎片情况、优化统计信息是否需要更新。生产系统运行几个月后某些大表的空间增长会远超预期。DB02 里能看到每个表空间的已用、未用比例配合数据库层的表空间文件就可以做扩容决策。事务代码监控对象需要重点关注的信号DB13数据库维护日历备份任务是否按时触发输出日志有无错误DB12备份日志夜间备份失败、日志目录空间不足DB02表与索引表空间已用比例过高、索引碎片多、统计信息过期这三件事的检查顺序建议固定成肌肉记忆早上先 DB12 看备份再 DB02 看空间隔几天用 DB13 检查维护任务的执行历史。任何一环出问题数据库都可能在白天业务高峰时掉链子。3.2 BRTOOLS 与备份恢复命令和习惯BRTOOLS 是操作系统上的数据库管理工具也是 Oracle 数据库备份、恢复的核心入口。日常运维中备份脚本一般由 BRBACKUP 生成恢复由 BRRESTORE 执行。完整的备份策略通常包含全备份、增量备份和日志归档备份的组合。对于使用 Oracle 数据库的 SAP 系统常见做法是每周做一次离线全备份每天做在线增量备份日志归档按需备份。备份完成后BRTOOLS 会生成日志文件里面的返回码“0”表示成功非 0 返回码要逐条查原因。以下是一次手工备份的参考命令# 执行数据库全备份离线模式 brbackup -u / -c yes -t online -m all -p /usr/sap/trans/backup # 执行数据库增量备份 brbackup -u / -c yes -t online -m incr -p /usr/sap/trans/backup # 查看最近一次备份日志 brbackup -u / -l -p /usr/sap/trans/backup这段逻辑里-t online表示在线备份业务运行期间可以直接执行-m all表示备份所有数据文件-m incr表示增量备份-p指向备份文件存放路径也就是/usr/sap/trans/backup。备份完成后不要只看返回码还要打开对应日志确认数据文件、控制文件、归档日志三个部分都成功备份到了介质上。备份恢复往往到真正需要时才发现之前备份有问题。建议在测试环境定期做一次恢复演练至少把备份集恢复到一台独立的测试机上验证可用性。这个过程花时间但能避免“备份日志显示成功、恢复时才发现缺归档”的尴尬。3.3 SM36/SM37 后台作业定义、监控、排查后台作业管理是 Basis 运维的高频动作。SM36 用来定义后台作业内容包含作业名、作业步骤、运行频率和启动条件SM37 用来监控作业的运行状态查看输出列表和分析取消原因。定义作业时最容易忽略的是“启动条件”和“变式”。很多报表程序需要传参数变式就是把这组参数固定下来。如果业务反馈作业运行结果不对先检查是不是变式参数填错了再检查作业的打印参数是否指向了有效的输出设备。SM37 的监控节奏建议按两个维度看按时间看每天的执行记录按作业名看周期性作业的历史趋势。管理员重点检查被取消的作业每一条取消都要分析原因并记录解决方案。取消原因不外乎三类作业步骤里的程序报错、权限问题、依赖的前置作业没有完成。发现问题作业后先查作业日志定位错误再修正变式或程序最后重置作业状态。注意长运行作业也是系统资源的隐患。一个设计不良的报表在后台跑八小时会持续占用工作进程。每天晚上用 SM37 扫一遍“正在运行”的作业确认运行时长是否合理。4. 系统监控把 ST06 到 ST22 串成一条巡检链4.1 从操作系统到应用分级监控怎么看系统监控最忌讳零散地看事务代码不看层次。SAP 的监控应该按“操作系统 → 工作负载 → 进程 → 应用日志”四级来组织。第一级是操作系统资源用 ST06 看 CPU 使用率、内存使用率、页面空间使用率。第二级是工作负载用 ST03 看 R/3 工作负载了解系统的整体响应时间和各应用服务器的负载分布。第三级是进程层面用 SM50 看单台应用服务器的进程状态SM66 看整个系统所有服务器的进程情况。第四级是应用日志与历史记录SM21 看系统日志、ST22 看 ABAP 短转储、SM12 看锁管理、SM13 看更新记录、SM20 看安全审计、SM04 和 AL08 看当前在线用户。SM04 和 AL08 都能看用户区别在于范围SM04 只看当前服务器AL08 看整个系统的用户。做全局排查优先用 AL08分析单台服务器负载时切换到 SM04。层次事务代码核心观察点操作系统ST06CPU、内存、页面空间工作负载ST03响应时间、工作进程利用率、历史基线进程SM50 / SM66 / SM51进程状态、服务器列表与分布用户SM04 / AL08在线用户数、占用资源情况锁与更新SM12 / SM13锁对象是否积压、更新失败数量日志与审计SM21 / ST22 / SM20系统错误、短转储、安全审计记录SM51 是服务器概览双击任意服务器可以跳到该服务器的工作进程视图配合 SM50 使用效果最好。SM66 则适合在集群架构中全局看有哪些进程跑在哪些服务器上省去一台台切换。4.2 每日、每周、每月的监控节奏监控要形成固定的巡检节奏只靠出问题再去查是绝对不够的。以下是我在项目上固定执行的节奏。每天必查SM37 看所有后台作业状态DB12 看备份结果SM21 看系统日志中是否有错误和警告ST06 快速扫一眼 CPU 和内存水位ST22 查当天有没有新增 short dump。这五件事加起来不超过十五分钟但能覆盖大部分日常风险。每周深查DB02 看表空间增长趋势ST03 拉一周的工作负载曲线SM50 观察工作进程的峰值使用率。重点是把上周的数据和之前几周对比识别缓慢增长型问题比如某张表每周涨 10%一个月后就可能撑爆表空间。每月整体评估BRTOOLS 日志回顾一个月的备份成功率/usr/sap/trans/log/ 下的传输日志检查是否有传输队列遗留同时核对系统消息 SM02 中是否累积了未关闭的维护公告。这个节奏的关键是“留存数据”。ST03 的历史数据尤其重要系统没有性能问题时的负载画像比出问题后的分析更有价值。不要因为不调优就不收集等到系统变慢时没有基线数据做对比性能分析会非常痛苦。4.3 短转储和锁的处理两个最常见告警ST22 里的 ABAP 短转储是应用层最明显的故障信号。每次报表或事务由于严重错误停止工作系统就会生成一条短转储记录。排查思路是先看短转储的“异常类”和触发程序再对照代码定位。常见的短转储包括运行时错误、数据库访问失败、内存不足、权限问题等。SM12 是锁管理用来分析锁对象。用户断线、程序异常退出都会留下残留锁。锁对象长期不释放后面想操作同一数据的用户就只能干等。清理锁之前一定要先确认持有锁的用户是否真的不在了可以通过 SM04 查该用户是否登录在线。锁删除属于影响业务的敏感操作不要为了清锁而清锁先联系业务确认再决定是否删除。SM50 里杀掉运行异常的进程也是同理。SAP 的对话进程被杀掉会导致用户会话中断执行前必须与最终用户协商。我见过因为误杀长时间运行的报表进程导致用户半小时操作白做的情况。杀进程前先确认进程运行了多久、属于哪个作业或用户、有没有正在写入的关键数据。5. 排障避坑清单五个 Basis 日常运维的典型翻车点5.1 用户重置密码后仍然无法登录现象用户反馈密码被重置后还是登录失败系统提示密码错误或账号锁定。原因重置密码时漏了“有效日期”检查。用户主记录的有效期已过无论密码多正确都无法登录另一种可能是该用户在其他集团已被锁定或登录对象的检查规则限制了访问时间。解决SU01 打开用户记录检查“登录数据”页签的“有效日期”把有效期延长到合理范围再检查“锁定”状态如有锁定先解锁最后用 SU53 检查登录时的授权对象是否有异常确认不是权限检查拦截。5.2 备份日志显示成功恢复时才发现数据文件缺失现象DB12 里备份状态是绿色但真正做恢复演练时发现控制文件和数据文件不完整。原因BRBACKUP 命令里指定的备份类型有问题或者备份完成后未做一致性检查。部分在线备份在数据库高负载时可能遗漏归档文件而备份日志只报了最终返回码中间的警告被忽略。解决备份完成后不要只看最后一行返回码打开 BRBACKUP 日志全文查看有无警告信息每周核对一次备份文件的文件数和大小确认和上一次全备份的增量一致每季度在测试环境执行一次恢复演练把备份集还原到独立服务器上验证。5.3 后台作业凌晨被取消白天才发现现象SM37 里某个重要作业状态是“已取消”输出列表为空业务第二天早上发现数据没生成。原因作业变式参数失效、前置作业超时未完成、输出设备打印机不可用是三个最常见原因。夜间无人值守作业一旦卡住就一路取消后面的依赖作业全部被连坐。解决在 SM37 中查看作业日志确认取消发生在哪一步检查变式是否仍然有效特别是日期类参数是否过期把该作业的启动条件改为依赖前置作业的“事件触发”而不是固定时间点给关键作业配置失败通知让系统在作业取消时主动发消息给运维人员。5.4 新集团拷贝完用户登录报“集团不可用”现象SCCL 拷贝完新集团后业务用新集团账号登录系统提示集团不在可用列表中或无法访问。原因SCC4 里新集团的属性未设置正确或者没有在 SCC4 中激活该集团的登录许可。拷贝过程本身成功了但集团层面的登录控制没放开。解决在 SCC4 中检查新集团的状态和角色设置确认“登录”权限已打开SCC3 里查看拷贝日志有无错误重点看用户主数据的传输结果登录后系统提示“集团角色不允许”时用 SU01 检查该用户主记录中的集团条目是否存在必要时重新复制用户主记录。5.5 打印任务卡在“正在输出”用户重复提交现象用户在 SAP 中打印报表输出控制器 SP01 显示任务一直在“正在输出”状态用户反复重打假脱机请求越积越多。原因SAP 只能跟踪打印任务到目标队列为止。用户电脑上的 SAPLPD 程序被关闭或者网络打印队列堵住任务虽然送出但实际没有打印。SP01 中显示的“已完成”状态并不能证明纸张真的从打印机里出来。解决先在 SP01 中查看假脱机请求的队列状态定位堵住的打印机联系用户检查本机 SAPLPD 是否在运行确认无误后重新输出或删除堆积的请求。重要打印任务在删除前务必先确认物理打印已经完成避免数据丢失。6. 传输管理与日志速查把最后一步走扎实6.1 SE09 到 STMS一次传输请求的完整生命周期传输管理日常主要用到 SE09 和 STMS。SE09 负责传输请求的创建、修改、任务分配和释放STMS 负责传输策略、集团策略和跨系统传输队列的管理。一个变更从开发系统到生产系统路径是SE09 创建变更请求 → 释放请求 → STMS 传输队列 → 目标系统导入 → 传输日志确认。看起来简单实际踩坑都在“导入失败后怎么处理”。传输请求释放后在目标系统导入失败常见原因是目标系统集团策略不允许直接导入或者传输目录权限错误。STMS 的队列里能看到请求卡在哪个系统双击请求可以查看具体导入日志。处理失败的请求时不要简单地把请求从队列里删掉要先把报错原因解决再重新导入。删除一个传输请求很容易但业务对象的一致性破坏很难恢复。提示传输目录在/usr/sap/trans/log/下每次导入都有对应的日志文件排查传输问题先看这里。6.2 五类关键日志的路径速查SAP 系统各层面的日志分布在不同的目录。启动日志位于/home/SIDadm/看实例启动和停止的过程进程日志位于/usr/sap/SID/DVEBMGS00/work/看应用服务器各工作进程的运行状态传输日志位于/usr/sap/trans/log/看传输请求的导入导出记录数据库日志在 Oracle 环境中位于/oracle/SID/saptrace/background/看数据库后台进程的警告和错误。日志类型路径使用场景启动日志/home/ adm/系统启动失败时确认启动过程进程日志/usr/sap/ /DVEBMGS00/work/查看工作进程异常、生成短转储的上下文传输日志/usr/sap/trans/log/检查传输请求导入失败原因数据库日志/oracle/ /saptrace/background/查看数据库告警、归档日志错误这些路径看似零散其实对应着系统启动、进程运行、变更传输、数据库后台四条线。系统启动失败先看启动日志业务响应慢看进程日志传输卡住看传输日志数据库备份或归档异常看数据库日志。养成按路径索引问题的习惯比在系统里盲目翻事务代码高效得多。6.3 用 RZ10/RZ11 管好参数修改的最后一道关参数管理是 Basis 运维里权限最高、风险也最大的操作。RZ11 用来查询参数RZ10 用来修改参数。修改参数前先用 RZ11 查看参数的当前值、默认值、作用范围确认它是动态参数还是静态参数。动态参数修改后立即生效不需要重启系统静态参数必须写入参数文件并重启实例才能生效。每一次参数修改都应该走“查询 → 备份 → 修改 → 验证 → 记录”的流程。修改前把原参数值抄录在变更记录里修改后观察一段时间确认没有引发副作用再把变更内容更新到运维台账。参数文件的修改是全局性的一个参数调整可能会影响所有应用服务器实例务必确认修改范围后再保存。我自己的习惯是凡是涉及 RZ10 的修改操作前先做完三件事RZ11 查参数的动态/静态属性、确认影响版本和实例范围、准备回滚方案。改完后重启实例或等待动态生效用 RZ11 再次确认参数值再更新台账。这个习惯来源于一次真实教训某次为了调优后台作业并行度我没有仔细确认参数作用域就修改了全局参数结果非目标实例也受到了影响业务高峰期部分进程异常排查了大半天才定位到参数关联。从那以后每次参数修改我都强制走一遍查询、备份、修改、验证、记录五步流程。Basis 这个角色稳比快重要。希望你也能从这套命令清单和排障思路里建立一套属于自己的稳定运维节奏。希望帮到你。本文还有配套的精品资源点击获取