企业官网建设流程全解析

简介：这份SAP日常运维BASIS资源是一份面向SAP系统管理员与运维工程师的内训式实用手册，聚焦BASIS日常工作中最常用的操作命令与监控方法，帮助读者快速上手用户权限、集团、数据库、后台作业、打印、系统传输等核心运维任务。资源为单个PDF文档，大小2.02MB，内容紧凑，适合作为案头速查与入门学习资料。预览中完整覆盖SU01用户管理、PFCG角色配置、SCC4集团维护、DB13数据库备份、SM36/SM37后台作业、SPAD打印管理、ST06/ST03系统监控、SE09/STMS传输管理以及重要日志存放路径等高频知识点，还包含系统启动日志、进程日志、传输日志、数据库日志的查看位置说明，方便日常排障与巡检。目前已有962人浏览学习，适合刚接触SAP BASIS的新人快速建立运维框架，也适合有经验的管理员查漏补缺，作为日常工作参考。

1. SAP BASIS 运维起步：从背事务码到按场景排障

新接手一套 SAP 系统的 BASIS 运维，头几天最容易卡住的不是数据库参数调优，而是事务码太多、不知道该先记哪个。SU01、PFCG、SCC4、SM37、STMS……清单背得滚瓜烂熟，可真遇到用户喊“账号锁了”，或者半夜有人打电话说“后台作业失败”，脑子还是空白的：先点哪个、看完日志往哪查、什么情况必须马上处理，这三件事没想清楚，事务码背得越多越慌。这套系统的日常维护，说白了就是把几十个事务码按场景串成链路：账号权限一套、集团数据库一套、后台作业和打印一套、监控和传输一套，外加一套日志排查方法。

SAP BASIS 从工作内容上可以分成实施和运维两个方向。实施偏规划、安装、配置，上线前还要交付大量文档；运维偏管理、监控、维护，身份更像贴身管家。日常运维的矛盾在于：系统每时每刻都在产生日志和作业，你不可能把所有功能每天都看一遍，所以必须把入口收敛成几条固定的巡检路径。这篇文章把路径拆开讲：用户权限管理从哪里进、集团拷贝和数据库备份的节奏怎么定、后台作业和打印问题怎么判断、监控与传输的坑在哪、日志去哪里看，最后给一份每天早晨能跑完的验证清单。

适合刚接手 SAP 系统的应用管理员、准备从 DBA 或开发岗转做 BASIS 的人，也适合已经做着 BASIS 但一直靠同事口口相传带路、想系统梳理一遍日常动作的熟手。正文里的事务码都以日常值班场景为线索编排，跟着走一遍就能把它变成自己的值班流程。

2. 用户权限管理：SU01 解锁改密到 PFCG 角色生成的完整链路

用户权限是 BASIS 每天接触最多的模块。用户被锁、新员工入职、权限不足、离职禁用，每件事都要在几个固定事务码之间来回切换。这一章按“建用户—批量改—角色授权—权限排查”的顺序把链路走通，顺带把几个高频翻车点标出来。

2.1 SU01：用户维护的第一步，也是翻车最多的一步

SU01 是整个权限管理的地基。用户报“密码错误次数超限，登录被锁”，标准动作是：进 SU01，输入用户名回车，在用户页签确认锁定状态，点工具栏中的“解锁”图标，顺手勾上“下次登录时修改密码”，然后让用户重新登录验证一次。新手容易漏掉一个点：解锁只在当前客户端生效。同一个用户在多个客户端有账号时，每个客户端都要单独解，只解主客户端，用户换个客户端登录照样报错。

创建新用户也走 SU01。输入用户名回车，维护姓、名、初始密码和用户类型，保存后账号就能登录了。用户类型是新手最容易填错的地方，常见的几种可以先对照下面这张表：

复制账号是 SU01 被低估的功能。新员工和老员工做同样的事，不需要从头配角色：SU01 输入新用户名，点“复制”按钮，选择已有的老账号作为模板并确认，系统会把老账号的角色、参数和默认设置一起带过来。保存前一定要改成新人自己的姓名和初始密码，否则新人拿着模板账号的初始密码也能登录。复制完再进 PFCG 检查一遍角色范围，确认没有带上老员工离职后本应回收的特殊角色。

解锁和改密是最高频的两件事，但真正决定安全的是密码策略。生产系统一般配了连续多次登录失败锁定，以及密码有效期。用户侧最常见的情况是：密码过期后不想改，反复试旧密码导致第二次锁定。Basis 在 SU01 里解锁后最好顺口问一句用户是否记得密码，忘了就直接重置并勾选首登改密。密码策略本身管在安全配置里，不在 SU01，别在 SU01 里找不存在的策略开关。

2.2 SU10：批量修改用户，省事但要留清单

SU10 解决的是“一批账号同时要处置”的场景，比如月底给临时用户批量锁定、给一组接口账号批量重置密码、给新入职一批人统一追加某个角色。进入 SU10 后在用户清单里勾选目标账号，右侧选择要执行的动作：解锁、锁定、改密码、分配角色等，执行前系统会列出受影响用户数，确认后批量执行。

批量操作最怕的是改完不知道改了谁。我一般会在执行前先把用户清单导出留存，再操作。改完抽两三个账号验证：能不能登录、权限是否就位、密码策略是否生效。批量改密码也建议先在少数几个账号上试一次，确认没有勾错选项再全量执行，毕竟一次给五十个接口账号重置了密码，SAP 不报错，接口侧的连接池全断。

2.3 PFCG：角色改完不“生成”等于白改

PFCG 维护角色，是权限配置的核心。新建角色时输入角色名回车，维护描述，在“菜单”页签里把事务码挂进去，在“权限”页签维护权限数据。保存之后还必须做一步：点“生成”按钮，把角色生成授权配置档案（Authorization Profile）。很多人改完角色忘了点生成，直接分配用户，结果用户重登几次还是报权限不足。

角色生成之后才谈得上分配用户。PFCG 的“用户”页签里添加用户号，保存。生效时机是用户重新登录之后，因为权限数据有缓冲，不会立即全量刷新。如果赶时间，可以在 SU01 里删除该用户的权限缓冲，让用户立刻拿新权限。权限的粒度由授权对象和字段决定，角色挂的是事务码和权限对象两者：菜单页签管用户能看见什么，权限页签管用户能执行什么。菜单和权限不一致，就会出现“菜单看得到、点开报无权执行”的怪现象。

角色还分单角色和复合角色（Composite Role）。单角色是基础，复合角色把多个单角色打包统一分配，适合按岗位整理。日常改权限我是建议直接改单角色再重新生成，复合角色的生成依赖子角色先完成，顺序反了会出现部分权限没生效。定位这类问题也简单：PFCG 打开角色，看角色状态是否“已生成”，再退到 SU53 看用户实际缺失的是哪个对象。

2.4 SU53、SU22、SU21、SU20：权限不足怎么一步步定位

用户报“事务码 XXXX 无权执行”时，很多 Basis 的第一反应是进 PFCG 改角色，但我建议先让用户别关掉报错界面，在当前会话执行 SU53。SU53 显示的是当前用户当前会话最近一次权限检查失败的授权对象和字段值，这是最直接的证据。

拿到缺失对象后，进 SU22 查这个事务码关联了哪些授权对象，和 SU53 的结果核对。SU21 和 SU20 分别维护权限对象和权限字段的底表，平时不直接动它们，只有权限管理员定义新的授权对象时才用得着。整条排查链路可以归纳成下面的步骤：

1. 用户在报错界面执行 SU53，截图缺失的授权对象和字段值。
2. 用 SU22 查出该事务码所需授权对象，与 SU53 结果核对。
3. 打开 PFCG 对应角色，在权限页签补充缺失对象，保存并点“生成”。
4. 重新分配用户，必要时在 SU01 清用户权限缓冲，让用户重新登录验证。

这一套走完，大多数权限问题都能自己定位。最忌讳的是不看 SU53 就在角色里把全部权限勾上——权限是放开了，安全审计里就留下一个大窟窿，回头 SM20 审计日志查起来全是这条角色变更记录。权限对象、字段、角色、用户的层次关系要心里有数：用户挂角色，角色挂授权配置档案，档案由权限对象和字段构成，每一层都是全局引用，底层字段动一个值，上面所有引用它的角色都会跟着变。

3. 集团与数据库管理：SCC4 建集团到 DB13 备份日历的落地

集团（Client）和数据库是 SAP 系统的两条命脉。集团管的是系统内的逻辑隔离，数据库管的是所有数据的物理落盘。备份还原能力是 BASIS 必须认真掌握的技能，日常的数据库运维主要围绕备份日历和空间监控展开。

3.1 集团管理：SCC4、SCCL、SCC3 的完整操作顺序

SCC4 是集团目录的入口，新建、修改、显示集团都在这。进入后能看到系统里所有集团，标配是 000、001、066 这些系统集团，生产上通常会另建 100 或 800 作为业务集团。新建集团需要维护集团号、描述、逻辑系统名，以及几个控制参数：是否允许 CATT、集团角色是生产还是测试等。需要注意，SCC4 建出来的是一个空壳，只有集团目录记录，没有主数据和业务数据，登录进去基本是空系统。

要让新集团有数据，走 SCCL 拷贝。SCCL 里的源集团填现有的业务集团，目标集团填刚建好的新集团，勾选要复制的范围：用户主数据、定制数据、业务数据等，按需选择。如果目标集团只用来测试，可以只复制定制数据，跳过体积最大的业务数据，拷贝时间能省一半。拷贝过程会产生大量数据库负载，一般放在维护窗口做，拷贝的同时不要开大批量后台作业。

拷贝过程中用 SCC3 查集团操作日志，看当前执行到哪一步、有没有报错。SCC3 在拷贝失败时尤其有用，日志里记录每一步的执行结果，不是靠猜。SCC1 是单个传输请求的系统内拷贝，适用于“某张报表程序只在集团 100 有，集团 800 也要一份”这类单点需求，不需要全量拷贝整个集团。SCC5 删除集团，生产环境基本不要碰；真要删，先确认该集团的备份和归档都做完了，再在维护窗口执行。

集团的逻辑系统名和传输管理配套，STMS 里的集团策略也依赖这些配置。新建集团后如果要做传输，SCC4 里要确认该集团允许传输，否则后面 STMS 队列里会出现请求卡住的情况。

3.2 数据库日常：DB13、DB02、DB12 三件套与 BRTOOLS

数据库层面的日常维护可以收敛成三个事务码加一个 OS 工具。DB13 是数据库维护日历，备份、检查数据库（Check Database）、优化器统计信息更新（Optimizer Statistics Update）等动作都在这里统一调度。进入 DB13 可以看到今天及未来一段时间排了什么维护动作，每天晚上有没有备份、备份成功或失败在日历上有标识。

DB13 里的动作和普通后台作业是两套体系，虽然它本质上也生成后台作业，但优先级更高，因为数据库备份失败会直接影响恢复能力。动作可以按每天或每周调度，关键是定义好“备份类型”和“保留份数”：在线备份（Online Backup）业务不中断，离线备份（Offline Backup）要停机，日常大多数用在线备份；保留份数决定了磁盘占用，保留过大会撑爆归档目录，过小又可能来不及发现坏备份。

DB02 是表和索引的监控入口，重点看“扩长”和“碎片”。表空间增长异常（某张表一周翻几倍）是业务或程序问题的信号，碎片多了会拖慢查询性能。DB02 也能看优化器统计信息的状况，统计信息过期时表的大小和索引分布已经失真，SQL 执行计划就可能跑偏。空间监控这块，我一般让 DB12 和文件系统监控一起配合：DB12 里除了备份结果，还有日志目录剩余空间，目录空间低于一定水位就要提前清理。

BRTOOLS 是操作系统上的数据库管理工具，当 SAP 应用层连不上数据库、DB13 也进不去时，最后的手段往往是落到 OS 层用 BRTOOLS 处理。常见命令是 brbackup：

# 以 <sid>adm 身份执行联机备份，-c 表示校验并更新备份历史 brbackup -t online -c

-t online指在线备份，业务不中断；-c让工具在备份完成后校验备份文件并写入历史记录。备份产物写到哪里、保留几代，由 BRTOOLS 的配置文件决定。手动跑备份通常用于两种场景：夜间备份失败后应急补一份，或者重大变更前做一份手工快照。数据库备份是 BASIS 的工作底线，数据安全的问题不能赌运气，备份还原要定期演练，而不是只在文档里写“已配好”。

4. 后台作业与打印管理：SM36 调度、SM37 监控和 SP01 重打的节奏

后台作业承载了 SAP 里的批处理负担，打印则是每天都会被用户抱怨的“小事”。这一章把后台作业的调度、监控和假脱机处理的节奏讲清楚，同时把两个容易让 Basis 半夜被叫醒的场景一起带出来。

4.1 SM36：定义后台作业，第一步是给作业起个好名字

SM36 定义后台作业，核心输入只有四个：作业名、步骤、开始条件、调度信息。作业名最容易被忽略。默认作业名往往是空白或系统随机生成，从运维角度看最好是“模块_程序_周期”这种结构，比如 FIN_ZPST_DAILY，一个月后回头看 SM37 清单，不用点进去就知道这个作业是干什么的。作业名不规范，排障时全靠猜。

步骤页签里指定要执行的 ABAP 程序，可以带变式（Variant）。变式是程序运行参数的快照，很多作业失败是因为变式被改动后没人同步回作业定义，程序一跑就崩溃。开始条件支持立即、按日期、周期性三种；周期性的设置里有执行日和间隔两个维度，新手最常见的问题是“周一跑一次”配成了“每周跑一次”但没勾周一，作业会在一周后的某个默认日期才跑起来，等于白等一周。

生产环境的作业变更应该走审批留痕，至少要有明确的变更记录：谁在什么时候改了哪个作业的开始条件。SAP 系统里有作业历史可查，但变更原因不会替你记，不写记录等于自己给自己埋雷。后台作业的定义不只是在 SM36 里填一屏，还包括变式的维护和测试，作业定义完最好先手动触发一次，确认程序本身能跑通，再挂到周期调度上，避免第一天就把生产作业跑挂。

4.2 SM37：监控后台作业，重点是“被取消”的那一批

SM37 是后台作业的监控入口。按作业名、用户、日期范围筛选，能看到作业的状态：已计划（Scheduled）、已释放（Released）、运行中（Running）、已完成（Finished）、已取消（Cancelled）。日常运维的动作是：每天早晨打开 SM37，把前一天夜间到现在的已取消作业拉出来，逐个确认原因。

作业取消的原因分几类：程序代码报错、变式参数非法、前置作业未完成导致依赖失败、系统资源不足等。在 SM37 里选中取消的作业，能看到作业日志和返回码，再结合程序日志判断是代码问题还是环境问题。如果是有缺陷的报表程序长时间运行拖垮了系统，管理员可以用 SM50 查看进程，确认后结束该进程，但结束前一定和最终用户协商——直接杀了正在跑的业务操作，用户半小时后发现数据没出来，投诉会到你头上。

检查作业日志这件事，SAP 官方文档不会替你养成习惯，管理者也不一定每天提醒，但这是 BASIS 的基本功。取消的作业不是系统自动重跑就完事了，要有闭环：分析原因、修正、重新调度、记录问题与解决方案。我见过不少项目把这类记录散落在聊天记录里，三个月后同一个作业又报同样的错，又得从头查一遍。作业日志里有时找不到明确原因，要去系统日志 SM21 看同一时间段的错误，还要留意后台进程日志里有没有资源不足的警告。

4.3 SPAD 与 SP01：打印问题的判断节奏

打印管理看起来不复杂，SPAD 定义打印设备，SP01 管理假脱机请求，但真出了问题，用户只说一句“打印机没出纸”，剩下的全靠 Basis 自己判断。SPAD 里配置输出设备：设备名、输出设备类型、后端服务器、打印机型号。设备配错型号会导致乱码或不出纸，这类问题往往不在 SAP 侧，而在操作系统驱动或设备型号匹配上。

SP01 里能看到每个假脱机请求的状态。如果用户报告打印不出来，先看 SP01 里有没有任务、任务是否被假脱机、是否处于输出状态。失败的任务可以重新启动，卡住的可以取消，滞留太多时可以集中清理。但有一个关键认知：SAP 只跟踪打印任务到目标队列为止，SP01 里显示“已完成”并不代表物理打印机真的出纸了。打印任务的真正成败取决于 PC 端 SAPLPD 程序和打印机之间的链路，PC 上 SAPLPD 被安全软件关了、驱动不对、打印机离线，都会导致假脱机状态显示成功但物理上没打印。

TemSe（临时顺序数据）里保存着假脱机数据，大量打印任务在从 TemSe 删除前必须先确认输出完成，否则用户说“那张单子我还没打出来”，你却把数据清掉了，就真的找不回来了。重要和大量的打印任务，我一般保留到业务确认后再清理，不为了省空间提前删。

5. 系统监控、传输与日志排查：ST06 性能指标和 dev 文件里的线索

这一章是每天值班的重心：系统监控负责发现问题，传输管理负责控制变更，日志排查负责给结论。把三部分放在一起是因为它们的依赖关系就在现场——ST06 看到负载异常、ST22 出现转储、STMS 队列卡住，最后都要去日志目录里找证据。

5.1 系统监控：ST06、ST03、ST22 组成每天的基点

ST06 是操作系统性能入口，看 CPU 使用率、内存使用率、页交换空间（Page Space）。页交换空间持续增长说明内存压力大，调优方向是 SAP 内存参数或服务器物理资源，而不是反复重启系统。ST03 看工作负载，重点观察对话响应时间和后台负载趋势。它的价值不在于单点数据，而在基线：系统正常时保留足够多的工作负载分析数据，哪天响应时间翻倍，你和正常时期的曲线一对比，结论立刻清楚，不需要猜。

ST22 是 ABAP 短转储（Short Dump）的入口。当报表或事务因严重错误停止工作时，系统会生成短转储，错误信息记录在表 SNAP 里。每台生产系统上每天出现一两个短转储很常见，关键是看错误类型：有的是 ABAP 代码问题，有的是资源问题，还有的是应用配置问题。ST22 里能看到终止时的调用栈和错误类别，分析后决定是否立即处理。短转储不是系统要崩，但它往往是一个更大问题的预警。

进程和用户监控分散在几个事务码里：SM04 看某台服务器上的当前用户，AL08 和服务器无关，能看到整个系统的当前用户数；SM51 列服务器概览，鼠标点中服务器名再选 Processes 能看该服务器工作进程；SM50 和 SM66 是进程和线程层级的视图，长时间运行、资源占用异常的后台作业往往在这里定位。SM12 锁管理专盯被锁对象：用户断线、程序异常退出都会遗留锁，老锁堆积不去清理，后续操作会一直提示对象被锁。SM13 更新记录的失败项在生产系统上是不能允许的，一旦出现要立刻联系开发处理。SM21 系统日志和 SM20 安全审计每天扫一遍，不是每个条目都要看，但警告和错误级别的条目必须过目。

其他用得没那么高频但不能不知道的入口包括：SM02 系统消息用来发公告，比如系统维护前通知全体用户；SM59 定义远程连接，跨系统 RFC 调用的配置入口；RZ10 和 RZ11 分别对应参数修改和参数查询，调 SAP 内存参数、启用某项系统功能时常用。这些不用每天都碰，但出了相关问题要知道去哪找。

5.2 传输管理：SE09 释放请求，STMS 盯队列

传输管理的日常分两头：开发侧负责在 SE09 里创建改变请求、加任务、最终释放；Basis 侧负责在 STMS 里看传输队列，处理导入状态。SE09 里的请求生命周期一般是：可修改（Modifiable）、释放（Released）、导入队列（Import Queue）。开发把请求释放后，Basis 在 STMS 里看到它进入目标系统队列，系统按队列顺序自动或手动导入。

STMS 是传输管理的核心入口。打开系统概览，能看到 DEV、QAS、PRD 等系统之间的传输路径；点进某个系统，能看到当前队列里等待导入的请求、正在导入的请求、导入失败的请求。导入失败的请求点进去能看到错误日志：很多失败原因是对象依赖缺失、目标系统里对象已经被修改过、或者权限不足。传输队列卡住时，还要回头查目标集团的配置——SCC4 里如果该集团不允许传输，请求会在队列里一直等着或直接报错。

跨系统传输的策略通常和集团策略、传输路由绑定。生产系统的传输应当有审批流程，这是规矩不是小事：没有审批的传输一旦进入生产，轻则覆盖一个程序，重则动到配置表，误传比不传更危险。传输日志的落点在 /usr/sap/trans/log/，队列里看不到原因时去这里翻文件。

5.3 日志排查：四个路径和五个高频坑

日志路径是 BASIS 急救时的地图。启动日志在 /home/<SID>adm，进程日志在 /usr/sap/<SID>/DVEBMGS00/work，传输日志在 /usr/sap/trans/log/，数据库日志在 oracle 目录 /oracle/<SID>/saptrace/background。这些路径在不同 SID 之间只是字母数字不同，结构基本一致。

实际看日志的命令一般这样：

su - <sid>adm # 切换到 SAP 管理员用户 cd /usr/sap/<SID>/DVEBMGS00/work # 进入进程日志目录 ls -lt dev_* | head -20 # 按修改时间列出最近的工作进程日志 tail -100 dev_w0 # 查看编号 w0 工作进程最近的输出

dev 开头的文件是 SAP 各进程的日志，dev_w0、dev_dp 等分别对应工作进程和调度进程。文件内容里含时间戳和错误级别，从时间条目的最后几行往往能看到崩溃前的线索。系统起不来时先翻 dev_dp，数据库起不来时去 /oracle/<SID>/saptrace/background 看后台警告文件，比在 SAP GUI 里绕圈子直接。

五个高频坑按“现象→原因→解决”记录如下：

第一个坑，新账号能登录但打不开事务码，报权限不足。原因是 PFCG 里角色分配了但没点“生成”，授权配置档案根本没更新。解决：进 PFCG 打开角色点生成，再分配用户，让用户重新登录。

第二个坑，ST22 天天有短转储，业务却一口咬定“没感觉”。原因：大量短转储出在变式配置错误或程序自身缺陷上，不是系统资源问题，业务使用不受影响。解决：按错误类分组，区分必须立即处理和可观察两类，把高频的 dump 提交给开发，同时保留正常时期的工作负载数据做基线。

第三个坑，DB12 显示夜间备份失败。原因：最常见是磁盘空间不足或日志归档目录满了，备份在第一步就被中断。解决：先清归档和日志目录释放空间，确认归档策略，重新调度一次备份；如果备份窗口快过了，用 brbackup -t online 手工补一份应急备份。

第四个坑，STMS 队列里的请求一直等待导入，传不下去。原因：目标集团在 SCC4 里的传输属性没放开，或传输路由未配置。解决：检查 SCC4 的传输设置，检查 STMS 里的系统路由和目标系统队列状态，修正后重发。

第五个坑，SM37 里作业取消，作业日志里却什么都没有。原因：作业在启动阶段就被终止，可能是资源不足或依赖的前置作业没完成。解决：去 SM21 系统日志看同一时间段的错误，同时翻 dev_w 工作进程日志，定位启动阶段的异常。

6. 装完怎么验证跑通：每天早晨的 Basis 值班检查单

配置全部就位、账号和权限链路都走通之后，真正重要的是验证这套运维环境每天还活着。我每天早上到工位后的前十分钟，固定按下面的清单过一遍，顺序基本不变：

这六项不是随便点开看一眼就完。ST06 我会先看 CPU 曲线有没有“和昨天同一时段不一样”的尖峰；ST22 有新增 dump 就顺手点开记录错误类别，十分钟内判断要不要拉开发；SM37 看的是取消作业的数量和理由，而不是状态本身；DB12 是六项里优先级最高的一项，夜间备份失败绝不能拖到第二天下午再处理。

STMS 队列这步我一般安排在最后，因为传输请求通常和前一天晚上的导入批次相关，放在备份和作业之后看，上下文更连续。传输失败如果只是单条请求，先在 STMS 里看导入日志，不要贸然重传——重传可能把对象覆盖两遍，产生一致性风险。

这套验证清单跑完，不等于系统万事大吉。数据库恢复演练、表空间增长趋势、用户权限复审这些都还挂在月度计划上。我自己的教训是：有一段时间觉得系统稳定，把 DB12 的检查降级成“想起来才看一眼”，结果有一天归档目录塞满，备份静默失败，好在发现及时没有造成数据缺口。从那以后，不管系统看起来多正常，我每天都会强制自己把这条验证链路完整走一遍，遇到新问题也随手记进自己的排障笔记，避免别人和自己重复踩同一个坑。希望这套清单也能帮到你。

本文还有配套的精品资源，点击获取