企业官网建设流程全解析

简介：一份面向SAP Basis日常运维场景的PDF文档，服务刚接触系统管理或需要查漏补缺的运维人员与Basis顾问，聚焦用户权限、集团管理、数据库维护、后台作业、打印管理、系统监控和传输管理等高频工作。压缩包内共1个PDF文件，约2.02MB，内容集中、便于按模块检索，可作为值班与交接时的速查手册。文档以SU01、PFCG、SCCL、DB13、SM36、SPAD、STMS等常用事务代码为线索，覆盖权限检查、集团拷贝、数据库备份日历、作业监控、假脱机请求处理、系统日志与进程查看等典型场景，并补充启动日志、进程日志、传输日志及数据库日志的查看路径。已有962人学习，适合希望快速建立Basis日常运维框架、对照命令定位问题并积累排错思路的读者参考。

1. 知识地图：BASIS 一天到底要盯哪几条线

SAP BASIS 的日常运维，落到手上是一张由事务码拼起来的地图：用户、权限、集团、传输、数据库、后台作业、打印、监控，八条线各自独立又互相衔接。不少人一上来就去钻研系统安装，其实安装属于“实施”那一端；真正每天在运转的是“运维”这一端——系统早已上线，整体架构已经确定，剩下的是把每天的巡检做扎实。这张地图的好处是，你不必记住几百个事务码，只要记住每条线对应哪三五个入口，其余的现场再查也不迟。实施和运维的分工大致是：实施定大局、出文档；运维守日常、做监控和调优。但有一件事两边都绕不开——数据库备份和还原必须真正练过，这是唯一没有后悔药的环节。这篇笔记按八条线拆开，最后收在一张能贴在工位上的复习清单上。

2. 用户与权限：SU01、PFCG、SU53 谁管谁

权限这条线是 BASIS 日常出现频率最高的：新员工入职、转岗、离职、跨部门借调，每一件事最后都落到 SU01 和 PFCG 上。很多人把它当成“点几下就完事”的活，真出问题才发现，一条权限从权限字段到用户身上要经过四道环节，任何一道没做全，用户看到的都是那句“你没有授权”。下面按“账号 → 角色 → 对象 → 排错”的顺序拆开；顺序反过来，很容易白忙一场。

2.1 SU01 与 SU10：账号从建到废的一条线

SU01 是用户维护的总入口，创建、修改、显示、锁定、解锁、改密码、复制账号全在这里。常用页签就那么几个：地址、登录数据、角色、参数文件、组、公司。日常最高频的动作其实是三个——解锁、重置密码、复制账号。

复制账号的流程是：输入已存在的源账号（比如 mycw12）→ 复制 → 填新账号名（比如 MYCW14）→ 保存。这里有个容易忽略的地方：复制会连同源账号的角色、参数文件和登录参数一起复制过去，如果源账号当年被临时加过一些不该长期保留的权限，新账号会原封不动继承。所以复制完必须做三件事：改密码、核对角色清单、确认没带上锁定状态。

SU10 是批量维护，按用户组、地址、锁定状态之类的条件筛出一批人，然后统一分配角色、统一锁定、统一改登录参数。它的价值在离职季和年度权限清理时体现得最明显——几十上百个账号，用 SU01 一个个点会出事。

提示：离职账号先锁后删，不要上来就删。删掉的用户在主数据里会变成空值，历史单据的经手人一栏事后很难还原。

2.2 PFCG 与 SU21/SU20/SU22：角色、对象、字段的四层结构

这一块是整个权限体系里最需要“理解”而不是“背”的部分。四条线的关系是：权限字段（SU20）组成权限对象（SU21），权限对象被角色引用（PFCG），角色最终分配给用户（SU01）。SU22 稍微特殊一点，它维护的是事务码与授权对象之间的对应关系——某个事务执行时到底会去检查哪些对象，看的就是这里。

PFCG 的标准动作顺序基本固定：

1. 建角色，分清单一角色和复合角色（复合角色只是把若干单一角色打包，本身不带权限数据）。
2. 在菜单页签里插入事务码、文件夹或报表，角色能干什么由菜单决定。
3. 切到授权页签，做“变更/生成”，让系统把菜单对应的权限对象自动带出来。
4. 手工补字段值，尤其是活动（01 创建、02 修改、03 显示）和组织级别（公司代码、工厂、采购组织这些）。
5. 生成参数文件（Generate），这一步不做，前面全白搭。
6. 在用户页签做用户比较（User Comparison）。
7. 分配用户。

第 5 步和第 6 步是最经典的出错点：改了菜单或权限值，只保存不生成，用户端毫无变化；生成了但没做用户比较，已经分配的用户也拿不到新参数文件。所以别人跟你说“我明明改了”，第一反应是去问他生成和比较做了没有。

2.3 SU53：权限报错的第一现场

SU53 显示的是当前登录用户最近一次权限检查失败的对象、字段和需要的值。注意“最近一次”这四个字——它只保留最后一次，所以时机比什么都重要。正确做法是让用户先复现报错，然后马上看；隔了半天再看，早就被后续操作覆盖了。

三个高频误用：一是管理员拿自己的账号跑一遍，看到的是管理员自己的检查结果，跟用户毫无关系；二是拖到第二天才查，证据已经没了；三是只看到对象名就去补对象，没注意字段值，补了对象没补值，用户照样报错。

需要彻底追踪就用 ST01 开系统跟踪，指定用户和授权检查这一项，让用户重跑一次事务，再分析跟踪结果。SU53 是急诊，ST01 是病理切片，两者配合才看得清。

-- 查某个用户当前分配到的角色，重点看有效期 SELECT AGR_NAME, UNAME, FROM_DAT, TO_DAT FROM AGR_USERS WHERE UNAME = 'MYCW14';

这段查询对应的是 AGR_USERS 表：AGR_NAME 是角色名，FROM_DAT 和 TO_DAT 是分配的有效期。很多“昨天还好好的今天就没权限了”的工单，根因就是有效期到期，而不是谁动了角色。改完角色记得重新生成参数文件，必要时让用户重新登录，等权限缓冲刷新。

3. 集团、传输与数据库：SCCL、SE09、DB13 的动手顺序

这三块经常被打包成“系统层面的操作”，实际上它们的节奏完全不同：集团是整块的复制和删除，影响面最大；传输是逐个请求的搬运，频率最高；数据库是每天固定要看的，容错率最低。共同点是都不能“试一下看看”，一旦点错，回退成本极高。

3.1 集团管理：SCC4 到 SCC3 的五步

SCC4 是集团维护，创建、修改、显示都在这里。真正需要盯的是几项设置：集团角色（生产、测试、定制、演示）、跨集团对象的修改策略（不允许修改 / 自动记录更改 / 无限制）、集团特定对象的修改是否记录、以及集团拷贝保护。生产集团的正确姿势是“不允许修改 + 记录”，测试集团才放开。

SCCL 是集团拷贝，参数要看清楚：源集团、目标集团、本地拷贝还是远程拷贝、拷贝的配置（SAP_ALL 全量、SAP_USER 用户主数据、SAP_CUST 定制、SAP_PROF 权限参数文件、SAP_UCUS 用户主数据加定制）、并行进程数。正式跑之前一定先做一次模拟运行（Test Run），看预估的时间和空间。正式拷贝会清空目标集团的原有数据，选错目标集团是事故级别的错误。

SCC1 是把单个传输请求导入当前集团，属于系统内传输。集团拷贝完之后经常用它把某些配置请求补进来。

SCC5 是删除集团数据，不能在当前登录的集团上执行，通常换一个集团登录过去，删完再回 SSC4 把集团状态改掉。

SCC3 是集团操作日志，拷贝成没成、跑了多久、卡在哪一步，全看这里。剪不断理还乱的拷贝问题，第一现场永远是 SCC3。

标准顺序：SCC4 建集团并设好角色 → 登录目标集团 → SCCL 模拟运行 → 正式拷贝 → SCC3 看日志 → 必要时 SCC1 补请求 → 回 SCC4 把生产集团锁成“不允许修改”。

注意：拷贝前确认源集团没有未释放的传输请求。带着未释放请求去拷，拷过去的东西和系统里实际在跑的东西对不上，后面排查会让你怀疑人生。

3.2 传输管理：SE09 释放与 STMS 导入

传输的层级是“请求（Request）→ 任务（Task）”。一个请求下面挂若干任务，任务按开发人或对象类型拆分。SE09 和 SE10 是请求管理，创建、查看、释放都在这里；SE01 是更全的视图。释放的顺序记牢：先释放任务，再释放请求。请求一旦释放就冻结，想改只能新建一个请求把改动带上，这就是没有后悔药的地方。

STMS 管的是传输的另一半：传输域、系统列表、传输路由、导入队列、导入历史、TMS 告警。导入的完整动作是：

1. STMS 里选中目标系统，进入导入队列。
2. 勾选要导入的请求，注意依赖关系和子请求。
3. 执行导入，等它跑完。
4. 看返回码：0 成功、4 带警告成功、8 需要手工处理、12 失败。
5. 失败就去看日志，定位到具体对象和行号。

日志位置固定：/usr/sap/trans/log 下，SLOG 是传输控制日志，ALOG 是按天记录的动作日志。请求的数据文件和 cofile 分别在 /usr/sap/trans/data 和 /usr/sap/trans/cofiles。这几条路径值得单独记在本子上，出问题时能省十几分钟。

3.3 数据库管理：DB13、DB02、DB12 与 BRTOOLS

DB13 是数据库日常维护日历，里面配的基本都是后台作业：完整备份、增量备份、数据库一致性检查、优化器统计信息更新、数据库校验。它同时是查看这些作业日志的入口。日常动作其实就一件事——确认昨晚那些作业都绿了，有红的点进去看日志。

DB02 做的是空间监控：表空间用了多少、涨得快不快、索引有没有碎片、优化统计是不是过期了。它回答的是“还有多久会满”这种问题，比“现在满没满”重要得多。

DB12 是备份日志汇总，用途很直接：检查夜间备份是否成功，顺带看日志目录剩余空间。归档目录写满导致数据库挂起，是最典型也最冤枉的一类事故。

BRTOOLS 是操作系统层面的数据库管理工具，用 adm 身份执行，做备份、还原、表空间操作。命令行界面不友好，但关键时刻只有它靠得住。

# 每天扫一眼归档日志目录的剩余空间，别等它写满 df -h <归档日志目录> # 备份日志目录按时间排序，看最近几次备份的产出 ls -lt <备份日志目录> | head -10

第一条命令看的是容量水位，第二条看的是备份产物是否按时生成。参数替换成各自环境的实际路径即可。这两条命令加起来不到十秒，但能挡掉一大半“早上来发现数据库不动了”的事故。

提示：备份成功不等于能还原。恢复演练要单独排期做，别把第一次还原留到真出事的那天。

4. 作业、打印与监控：SM36、SP01、ST22 串起的巡检闭环

前面几块偏“改”，这一块全是“看”。看的东西多了容易漏，所以要有一个固定顺序：先看有没有报错（转储、系统日志），再看有没有卡住（锁、更新、进程），最后看资源够不够（操作系统、工作负载）。顺序反过来，你会先被一堆正常波动的曲线带偏。

4.1 后台作业：SM36 定义、SM37 监控

SM36 定义作业，要素有四个：作业名、作业类（A 高、B 中、C 低）、执行的目标服务器、步骤。步骤可以是 ABAP 程序、外部命令或用户出口。开始条件有立即、指定日期时间、事件触发、前序作业结束后这几种。

这里有个新手必踩的坑：定义完只点了保存，没点释放。作业在 SM37 里显示“已计划”，状态永远停在那儿，因为没释放的作业根本不会进入调度。定义和释放是两步，缺一不可。

SM37 是监控端，按作业名、用户名、状态、时间范围筛。状态有这么几种：已计划、已释放、就绪、运行中、已结束、已取消。管理员的日常动作是——把所有“已取消”的作业捞出来逐个看日志，能修就修，不能修就记录原因和结论。作业日志和假脱机列表都要看，很多人只看状态不看输出。

4.2 打印管理：SPAD 与 SP01

SPAD 定义打印设备，要配的东西包括设备类型、输出设备名、主机假脱机服务器、访问方式、逻辑设备。访问方式那几种（本机、本地、远程、存储、前端）决定了打印请求走哪条路，选错了就是打不出来。

SP01 管假脱机请求和输出请求。打印不出来的时候先来这里看有没有对应的假脱机请求：有就说明 SAP 这边认了，问题多半在输出链路上；没有就说明请求根本没生成，要往前查事务本身。失败的请求可以在这里重启，也可以删掉重来。

有一个认知必须纠正：系统只跟踪到“输出到目标队列”这一步，输出控制器里显示的“已完成”并不代表纸真的打出来了。所以重要的大批量打印任务，在从 TemSe 里删除之前必须人工确认，否则事后想补打都没数据。

最常见的失败原因其实很朴素：用户电脑上的本地打印服务没起来，或者网络断了。所以先在 SP01 看请求状态，再回头查用户端，比一上来就怀疑系统要快得多。

4.3 系统监控：ST06、ST03、SM50、ST22 的排查顺序

ST06 看操作系统层：CPU 使用率、内存、页面空间、文件系统、磁盘 IO。每天第一眼看它，能快速判断“是系统整体吃紧，还是某个事务的问题”。

ST03 是工作负载分析，把响应时间拆成数据库时间、CPU 时间、前端时间，还能按事务码、按用户看。这块的价值不在出事的时候，而在没出事的时候——系统正常运行时的那份数据才是资产。手里有一张“健康状态长什么样”的图，异常一出现你立刻能感觉到，很多问题在爆发前就被摁住了。

SM04 看当前登录用户（本服务器），可以结束会话；AL08 看的是全系统的用户，跨服务器。SM51 列出所有应用服务器，点进去看进程就是 SM50；SM66 是全局进程列表，找长时间运行的作业和卡死的事务用它最快。

SM50 里的进程类型要认识：对话、更新、更新2、后台、假脱机、锁管理、RFC。状态有运行中、等待中、已停止。看到某个对话进程跑了几千秒，先别急着动手，去 SM04/SM66 确认是哪个用户、在跑什么，跟对方沟通完再处理。直接杀掉正在做更新的进程，会把更新打成失败记录，问题从“慢”升级成“数据不一致”。

SM12 是锁管理。用户断线、程序报错都会留下锁，老锁不清理，别人就一直改不了这条数据。处理前要判断是活锁还是死锁。SM13 是更新记录，显示失败的更新动作。生产系统里失败的更新是不允许过夜的，必须当天找到原因交给开发处理。

ST22 是 ABAP 转储分析。每天必须看有没有新的短转储，看转储类型、程序名、行号、调用栈。SM21 是系统日志，按时间、用户、消息类型筛，所有的警告和错误都要分析和记录。SM20 是安全审计日志，查的是登录失败、权限被拒这类安全事件。

一套可以照抄的排查顺序：用户报慢或卡 → ST22 看有没有转储 → SM21 看有没有告警 → SM12 看老锁、SM13 看失败更新 → SM50/SM66 看进程 → ST06/ST03 看资源。按这个顺序走，八成的工单在前三步就能定位。

4.4 日志路径与参数：/usr/sap 下的四类日志

系统出问题时，事务码看不到的东西都在文件系统里。四类日志的位置需要记牢：

# 1. 启动日志：实例启停、进程崩溃的第一现场 ls -lt /home/<SID>adm | head # 2. 进程日志：dev_disp 调度、dev_w0 对话进程、dev_rfc RFC cd /usr/sap/<SID>/DVEBMGS00/work ls -lt dev_* | head -20 # 3. 传输日志：SLOG 传输控制，ALOG 按天动作日志 cd /usr/sap/trans/log ls -lt | head # 4. 数据库日志：数据库软件目录下的 trace/background 一类的转储目录

第一段看的是实例级的启动记录；第二段里 dev_disp 记录调度器的启停和进程异常，dev_w0 是第一个对话进程的日志，进程崩溃时先看这两个；第三段的 SLOG 里 grep 一个 “rc=12” 就能捞出所有导入失败的记录；第四段各数据库厂商路径不同，一般都在数据库软件目录下的 trace 或 background 子目录里，按实际环境替换。

参数这块，RZ11 用来查，RZ10 用来改。RZ11 显示参数的当前值、默认值、是否动态可改；RZ10 维护参数文件，改完大多数参数要重启实例才生效，少数动态参数可以在线改。改生产参数前先 RZ11 确认这个参数是不是动态的，别为了省一次重启把系统改出问题。

还有几个零散但常用的：SSAA 是系统管理助手，把常用管理入口集中在一页，新手期把它当目录用；SM02 发系统消息，停机维护前先发一条，比挨个通知省事；SM59 维护 RFC 连接，系统间通不通先在这里测。

5. 易错点：五个最容易翻车的 BASIS 操作

这一章单独拎出来，是因为下面五件事都不是“不会”，而是“会但图省事”。每一条都按“错在哪 → 为什么会漏 → 怎么补”写。

5.1 用大权限

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