企业官网建设流程全解析

简介：这份资源是一份面向SAP Basis初学者与运维人员的Client Copy（集团拷贝）操作文档，聚焦在SAP ECC 6.0 32位系统中从000集团拷贝到测试集团790的完整流程，帮助读者在不影响生产环境的前提下搭建定制、开发与测试用的新客户端。压缩包内共1个doc文件，约776KB，内容以图文步骤形式记录了逻辑系统定义、逻辑系统分配至客户端、SAP*登录配置及SCCL后台排程等关键环节，并附有作者对网络资料常见错误的验证与修正说明。目前已有626人学习下载，适合需要动手实践集团拷贝、排查权限与数据一致性问题的技术人员参考，也可作为后续MM流程定制与程序开发的入门铺垫。

1. SAP集团拷贝 client copy：从 SCCL 到跨 Client 传输的完整落地路径

接到“把生产集团拷一份到测试机”这个需求时，很多 Basis 的第一反应是打开 SCCL 直接点执行。但真正做过几次的人都知道，SAP 集团拷贝（client copy）远不是点一个按钮的事——它牵扯到源 Client 的冻结策略、目标 Client 的清理方式、Profile 参数选择、表空间预估、后台作业调度，以及拷贝完成后的 SU01 用户比对和权限修复。标题里的 SCCL 是事务码，SU01 是用户维护，ECC6.0 是大量企业仍在跑的版本底座，这几个词串起来就是一条完整的落地链路。这篇文章面向的是需要独立完成集团拷贝的 SAP Basis 从业者，也会覆盖刚接触 Basis 但已经能操作 SAP GUI 810 的运维人员。我会从 Profile 选型讲到后台作业监控，从表空间预估讲到拷贝后的权限修复，把每一步的参数含义和踩坑点都摊开说。

2. 拷贝之前先把账算清楚：Profile 选型与资源预估

2.1 五种 Profile 的适用边界与选择逻辑

SCCL 里可选 Profile 有 SAP_ALL、SAP_APPL、SAP_UAPP、SAP_CUST、SAP_USER 等，但实际项目中最常纠结的是 SAP_ALL 和 SAP_APPL 之间的取舍。SAP_ALL 包含应用数据、定制数据、用户主数据、权限数据，基本等于把源 Client 整个搬过来；SAP_APPL 只含应用数据和定制数据，不含用户和权限。如果你的目标是搭一个和源系统业务逻辑一致的测试环境，SAP_ALL 是最省事的；但如果目标 Client 已经有自己的用户体系，或者你只想刷新配置而不动用户，SAP_APPL 更合适。

SAP_CUST 只拷定制，适合配置对比场景；SAP_USER 只拷用户主数据，适合用户同步。选 Profile 的核心判断依据是：目标 Client 里哪些数据是你想保留的。一旦选了 SAP_ALL，目标 Client 的所有数据都会被覆盖，没有后悔药。

选 Profile 时还有一个容易被忽略的点：SAP_ALL 在 ECC6.0 上的执行时间可能是 SAP_APPL 的 1.5 到 2 倍，因为用户和权限数据的拷贝涉及大量小表的逐行操作。如果目标只是刷新业务数据做测试，SAP_APPL 能省下不少窗口时间。

2.2 表空间与日志空间的预估方法

集团拷贝翻车最常见的原因不是操作失误，而是表空间满了。拷贝过程中，目标 Client 的数据写入会产生大量归档日志和表空间增长。预估方法如下：

先用 DB02 查看源 Client 各表空间的使用量，重点关注 PSAPSR3（应用数据）和 PSAPSR3701（如果有独立索引空间）。然后估算目标 Client 的增长量——如果目标 Client 是空的，增长量约等于源 Client 的数据量乘以 0.8 到 1.2 的系数；如果目标 Client 已有数据，需要先算清理后的剩余量。

-- 在源系统上估算 Client 级数据量（以 Oracle 为例） SELECT tablespace_name, ROUND(SUM(bytes)/1024/1024/1024, 2) AS size_gb FROM dba_segments WHERE owner = 'SAPSR3' GROUP BY tablespace_name ORDER BY size_gb DESC;

这段 SQL 给出的是整个 SAPSR3 用户下的空间分布，不是单个 Client 的精确数据量。要精确到 Client 级别，需要用 SAP 提供的报表或 SE16 查 TSTC 等表的条目数来估算。实际操作中，我一般会在源系统用 DB02 的“历史数据”功能看过去三个月的增长趋势，再结合目标 Client 的当前使用量，预留至少 30% 的余量。

归档日志空间同样关键。拷贝期间数据库处于归档模式，日志切换频率会显著上升。如果归档目录满了，数据库会挂起，拷贝作业直接卡死。建议在拷贝前把归档目录扩容到源 Client 数据量的 2 倍以上，或者确认归档备份作业在拷贝窗口内正常运行。

提示：在 ECC6.0 上，如果 PSAPSR3 剩余空间不足 20%，不要启动 SAP_ALL 拷贝。先扩容，再操作。

3. 用 SCCL 跑通一次完整拷贝：从建用户到后台作业监控

3.1 目标 Client 的创建与 SU01 用户准备

在跑 SCCL 之前，目标 Client 必须已经存在。如果目标 Client 还没建，需要用 SCC4 创建 Client，指定城市、货币、角色等基础信息。创建完成后，用 SU01 登录目标 Client，确保至少有一个拥有 SAP_ALL 权限的用户可以执行后续操作。这个用户通常是 SAP* 或者你手动创建的 Basis 管理员账号。

SU01 里需要检查的关键点：用户的“登录”页签下，用户类型是“对话”还是“系统”；“角色”页签下是否分配了 SAP_ALL 或 SAP_BC_* 相关角色。如果目标 Client 是全新创建的，SAP* 默认密码是 06071992 或 PASS，但很多系统在安装后已经改了。如果 SAP* 登录不了，需要通过数据库层面重置或者用 DDIC 用户操作。

-- 这不是 SQL，是在 SAP GUI 里的事务码操作序列 -- 1. 登录目标 Client，事务码 SU01 -- 2. 输入用户名 SAP*，点击“显示” -- 3. 检查用户类型是否为“对话” -- 4. 检查角色页签是否包含 SAP_ALL -- 5. 如果 SAP* 被锁定，用 SE30 或直接数据库更新 USR02 解锁

上面这段是操作序列的说明，不是可执行代码。SU01 的操作在 SAP GUI 810 里是标准界面，没有命令行替代方案。如果 SAP* 不可用，常见做法是用 DDIC 登录后通过 SU01 创建新的 Basis 管理员，或者用 SE37 执行 BAPI_USER_UNLOCK 解锁。

目标 Client 准备好之后，还需要确认 SCC4 里的“Client 角色”设置。如果目标 Client 的角色是“生产”，SCCL 会拒绝执行拷贝。需要先把角色改成“测试”或“定制”，拷贝完成后再改回去。这个细节在 ECC6.0 上尤其容易忽略，因为 SCC4 的界面在不同版本里位置略有差异。

3.2 SCCL 的执行步骤与后台作业调度

SCCL 的执行流程分三步：选择 Profile、选择源 Client、调度后台作业。具体操作如下：

第一步，登录目标 Client，事务码 SCCL。在“选择配置文件”区域，根据前面的分析选择 SAP_ALL 或 SAP_APPL。如果只需要特定表，可以选“选择性拷贝”并指定表名，但这种方式容易漏表，一般不建议新手使用。

第二步，在“源 Client”字段输入源 Client 编号。如果源 Client 和目标 Client 在同一个系统里，直接输入编号即可；如果是跨系统拷贝，需要用 SCC9 或者 RFC 连接，配置逻辑系统。跨系统拷贝的复杂度更高，涉及 RFC 目标配置和逻辑系统映射，这里先聚焦同系统拷贝。

第三步，点击“调度”按钮，系统会弹出后台作业调度界面。这里需要设置执行时间——立即执行还是指定时间窗口。对于 SAP_ALL 拷贝，建议设置在业务低峰期，因为拷贝过程会占用大量数据库资源。

-- SCCL 后台作业的监控事务码 -- SM37：查看作业日志，确认作业状态是“已释放”还是“已激活” -- SM50：查看工作进程占用情况，确认是否有长时间运行的进程 -- ST22：查看 ABAP Dump，如果拷贝过程中出现异常终止 -- SM21：查看系统日志，确认是否有数据库层面的错误

这几个事务码是拷贝期间必须盯的。SM37 里作业状态从“已调度”变成“已释放”再变成“已激活”，最后变成“已完成”。如果卡在“已激活”超过预期时间，需要去 SM50 看工作进程是否被阻塞，或者去 ST22 看是否有 Dump。常见的情况是表空间满了导致数据库写入失败，作业会直接终止并在 SM21 里留下记录。

拷贝过程中还有一个关键参数：并行度。SCCL 默认使用单进程拷贝，在大型系统上可能跑十几个小时。可以通过 RSCLXCOP 或者调整 Profile 参数来增加并行进程数，但并行度太高会导致数据库锁竞争加剧。我一般会在 ECC6.0 上设置 3 到 5 个并行进程，具体取决于数据库服务器的 CPU 核数和 I/O 能力。

注意：并行度不是越高越好。超过 8 个并行进程后，数据库层面的锁等待会显著增加，整体耗时反而可能上升。

4. 拷贝完成后必做的三件事：用户比对、权限修复与一致性检查

4.1 SU01 用户比对与权限修复

拷贝完成后，目标 Client 的用户数据取决于你选的 Profile。如果选了 SAP_ALL，用户和权限会被源 Client 覆盖，目标 Client 原有的用户可能丢失。如果选了 SAP_APPL，用户数据保持不变，但权限可能需要手动调整。

SU01 的比对方法是：在源 Client 和目标 Client 分别用 SUIM 报表导出用户清单，然后逐项对比。SUIM 里常用的报表包括“用户清单”“角色清单”“权限值清单”。重点检查以下几类用户：Basis 管理员、接口用户、后台作业用户、RFC 用户。这些用户的权限如果不对，后续的系统运维会直接受影响。

-- 用 SUIM 导出用户清单的报表路径 -- SUIM -> 用户 -> 用户清单 -> 按用户组或按角色 -- 导出格式选“电子表格”或“本地文件” -- 然后在 Excel 里做 VLOOKUP 比对

SUIM 的导出功能在 ECC6.0 上支持 Excel 格式，可以直接用 VLOOKUP 做差异比对。如果用户量很大，可以用 SE16 查 USR01 和 USR02 表，但这两张表只含用户主数据，不含权限分配。权限分配在 AGR_USERS 和 USR04 等表里，查询复杂度更高。

权限修复的常见场景是：目标 Client 的某个用户拷贝后无法执行某个事务码。原因可能是角色没拷过来，或者权限对象的值不对。修复方法是用 SU01 重新分配角色，或者用 PFCG 检查角色的权限对象是否完整。PFCG 在 ECC6.0 上是角色维护的标准事务码，拷贝后建议对关键角色跑一次“用户比较”和“权限比较”。

4.2 一致性检查与常见异常处理

拷贝完成后，需要用几个标准检查点确认数据一致性。第一个检查点是 SCC3——在目标 Client 执行 SCC3，查看拷贝日志和统计信息。SCC3 会列出拷贝的表数量、记录数、耗时、错误信息。如果表数量明显少于预期，说明拷贝不完整。

第二个检查点是 SE14——检查关键表的数据库状态。拷贝过程中如果出现数据库层面的错误，某些表可能处于“不一致”状态。SE14 可以查看表的激活状态和数据库状态，必要时执行“数据库实用程序”进行修复。

第三个检查点是 SM28——执行安装检查。SM28 会检查系统的整体一致性，包括数据库、ABAP 字典、权限等。拷贝后跑一次 SM28，可以快速发现明显的配置问题。

-- 拷贝后必跑的检查事务码 -- SCC3：拷贝日志和统计 -- SE14：表的一致性检查 -- SM28：安装检查 -- ST22：Dump 分析 -- SM21：系统日志

如果 SCC3 里出现大量“表未拷贝”的记录，常见原因是源 Client 的表在目标 Client 里不存在，或者表的交付类不允许拷贝。这种情况需要用 SE11 检查表结构，确认表的交付类是否为“C”（定制）或“A”（应用）。如果是“S”（系统表），SCCL 默认不拷贝，需要手动处理。

另一个常见异常是拷贝后目标 Client 的编号范围丢失。编号范围在表 NRIV 里，SCCL 对 NRIV 的处理取决于 Profile 和表的交付类。如果拷贝后发现某个事务码的编号范围不对，需要用 SNRO 或 SNUM 手动调整。这个坑在 ECC6.0 上尤其常见，因为很多自定义事务码的编号范围没有正确配置。

5. 避坑与排查：集团拷贝中最容易翻车的五个场景

5.1 表空间满导致作业中断

现象：SCCL 作业在 SM37 里显示“已激活”，但长时间没有进展，SM50 里工作进程状态为“等待”或“PRIV”。SM21 里出现数据库写入错误。

原因：目标 Client 的表空间在拷贝过程中被写满，数据库无法继续写入，ABAP 工作进程进入等待状态。

解决：立即用 DB02 检查表空间使用率，扩容 PSAPSR3 或 PSAPSR3701。扩容后作业可能自动恢复，也可能需要重新调度。如果作业已经终止，需要先清理目标 Client 的部分数据再重新拷贝。预防措施是在拷贝前预留至少 30% 的表空间余量。

5.2 归档目录满导致数据库挂起

现象：拷贝作业突然停止，SM21 里出现“归档日志目录已满”或“数据库挂起”的消息。所有数据库操作都无法执行。

原因：拷贝期间归档日志切换频率大幅上升，归档目录空间不足，数据库进入挂起状态。

解决：清理归档目录或扩容，然后联系 DBA 恢复数据库。预防措施是在拷贝前确认归档备份作业正常运行，归档目录有足够空间。在 ECC6.0 上，如果归档目录和数据库在同一台服务器上，还需要考虑磁盘 I/O 竞争。

5.3 目标 Client 角色设置错误导致 SCCL 拒绝执行

现象：SCCL 点击“调度”后弹出错误消息，提示“Client 角色不允许拷贝”或类似信息。

原因：目标 Client 在 SCC4 里的角色被设置为“生产”，SCCL 不允许对生产 Client 执行拷贝。

解决：用 SCC4 把目标 Client 的角色改成“测试”或“定制”，拷贝完成后再改回去。注意 SCC4 的修改需要传输请求，如果是生产系统，需要走正常的变更流程。

5.4 拷贝后用户无法登录

现象：拷贝完成后，用目标 Client 的某个用户登录，提示“用户不存在”或“密码错误”。

原因：如果选了 SAP_ALL，目标 Client 的用户数据被源 Client 覆盖，原有用户可能不存在。如果选了 SAP_APPL，用户数据保留，但密码策略可能不同。

解决：用 SU01 检查用户是否存在，如果不存在需要重新创建。如果存在但密码不对，用 SU01 重置密码。对于 SAP* 用户，如果被锁定，需要通过数据库层面解锁或重置密码。

5.5 编号范围丢失导致业务单据无法创建

现象：拷贝后创建销售订单或采购订单时，系统提示“编号范围不存在”或“编号范围已满”。

原因：NRIV 表的编号范围数据在拷贝过程中丢失或未正确拷贝。

解决：用 SNRO 或 SNUM 检查编号范围对象，手动补充缺失的编号范围。对于自定义事务码，需要在开发系统里确认编号范围配置，然后手动同步到目标 Client。预防措施是在拷贝前用 SE16 查 NRIV 表，记录关键编号范围对象的当前值，拷贝后比对。

6. 跨 Client 传输与 SCC9 的进阶用法

同系统内的 SCCL 拷贝是最常见的场景，但实际项目中还会遇到跨系统拷贝的需求——比如从生产系统拷到测试系统，或者从旧系统拷到新系统。这种场景需要用 SCC9 或者 RFC 连接，配置逻辑系统映射。SCC9 的界面和 SCCL 类似，但多了一个“目标系统”的选择步骤，需要提前在 SM59 里配置 RFC 目标，并在 SCC4 里维护逻辑系统。

跨系统拷贝的第一个坑是 RFC 连接的稳定性。如果网络带宽不足或者 RFC 超时设置太短，拷贝过程中会出现 RFC 通信失败，作业直接终止。我一般会在 SM59 里把超时时间调到 3600 秒以上，并在拷贝前用 SM59 的“连接测试”功能确认 RFC 目标可达。

第二个坑是逻辑系统映射。跨系统拷贝时，源系统和目标系统的逻辑系统名称必须正确映射，否则拷贝后的数据里会残留源系统的逻辑系统信息，导致后续的 ALE 或 IDoc 通信出错。逻辑系统在 SCC4 里维护，需要确保源系统和目标系统的逻辑系统名称在拷贝前已经配置好。

-- 跨系统拷贝前的检查清单 -- SM59：确认 RFC 目标可达，超时时间足够 -- SCC4：确认源系统和目标系统的逻辑系统名称 -- BD54：检查逻辑系统定义 -- SM30：检查 V_T000 表的维护视图

跨系统拷贝的耗时通常是同系统拷贝的 2 到 3 倍，因为数据需要通过网络传输。如果源系统和目标系统之间的网络延迟超过 10ms，建议在业务低峰期执行，并考虑用并行进程加速。但并行进程数不宜超过 4 个，否则 RFC 连接可能成为瓶颈。

最后一个技巧是关于拷贝后的数据清理。跨系统拷贝后，目标系统里会残留源系统的后台作业、假脱机请求、工作流实例等运行时数据。这些数据在测试环境里通常不需要，可以用 SM37 删除旧作业，用 SP01 删除假脱机请求，用 SWWL 删除工作流实例。清理这些数据可以显著减少目标系统的存储占用，也能避免后续运维中的混淆。

我在多次集团拷贝中最大的教训是：永远不要在生产系统的工作时间做拷贝，哪怕只是测试。有一次我在生产系统上跑 SAP_APPL 拷贝，结果数据库 I/O 飙升，业务用户直接投诉到 CIO 那里。从那以后，我养成了一个习惯——拷贝前先确认业务低峰期窗口，拷贝中每 30 分钟检查一次 SM50 和 DB02，拷贝后跑完 SCC3 和 SM28 才收工。希望帮到你。

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