简介这份资源是一份面向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应用数据定制用户权限全新测试环境搭建是SAP_APPL应用数据定制刷新业务数据否SAP_UAPP用户权限应用数据用户权限同步是SAP_CUST仅定制配置对比/传输否SAP_USER仅用户主数据用户批量同步是选 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安装检查 -- ST22Dump 分析 -- 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 才收工。希望帮到你。本文还有配套的精品资源点击获取