简介这是面向SAP Basis顾问和ECC系统管理员的集团拷贝Client Copy操作指南完整演示在ECC 6.0 32位环境中从客户端000复制出测试客户端790的流程。资料以1个doc文档打包大小776KB收录了作者实测整理的操作笔记目前已有629人学习下载。文档从管理员账号创建、SALE定义逻辑系统、分配逻辑系统到新客户端再到修改SAP*默认密码及后台执行SCCL拷贝逐步梳理了关键T-Code和参数设置对逻辑系统的跨客户端属性、新客户端的城市/货币/角色配置、系统修改自动记录等选项均有明确说明。同时指出Copy过程中常见的数据不一致、权限限制等易错点并给出RZ10调整login/no_automatic_user_sapstar参数等排错思路特别强调跨客户端表的影响及配置注意事项可帮助读者减少踩坑。适合需要独立搭建SAP测试环境、进行定制开发或备查Basis操作细节的入门与进阶读者。1. SAP集团拷贝是什么一个复制不出错的底层逻辑「SAP集团拷贝」也就是 client copy在SAP系统里指的是把一个集团Client也就是我们常说的租户里的配置、主数据、业务数据按指定范围复制到另一个集团。它解决的核心问题非常直接你不想在一个环境里重复做基础配置也不想在测试环境里拿生产数据时一点点导而是希望用一条完整链路把整个集团的内容搬过去。常见场景包括创建新的测试集团、在质量保障环境拉一份生产数据做演练、把定制化配置从一个集团同步到另一个集团。适合读这篇文章的人是正在做SAP Basis或系统管理的工程师可能要独立完成集团创建、数据复制、后台作业调优也踩过复制完成却发现目标集团登录不进去、数据缺失一半、权限错乱这类典型的坑。这篇文章会把三种常用的复制模式拆开讲清楚给出可直接执行的步骤和参数同时把最容易翻车的地方列出来让你在动手之前就知道需要在哪个节点停下来检查。2. 集团拷贝的运行机制理解三种模式再动手才不至于复制完没法用2.1 三种模式对比本地拷贝、远程拷贝、逻辑删除后复制在R/3乃至S/4HANA的日常运维里集团拷贝并不是一个单一事务码而是一组围绕同一个生命周期管理的操作。我们通常说的三种模式分别是本地集团拷贝、远程集团拷贝、以及无覆盖模式的拷贝。理解它们的本质区别直接决定你的复制策略。本地集团拷贝是指源集团和目标集团都在同一个SAP系统实例里通过后台作业直接读取源集团数据写入目标集团。整个复制过程不经过网络、不经过RFC速度相对可控。远程集团拷贝则发生在两个不同的SAP系统之间源系统作为发送端目标系统作为接收端通过RFC连接建立会话目标系统在接收数据的过程中会持续写入自己的数据库。远程拷贝最大的优势是可以在保持生产系统离线压力较小的前提下把数据搬运到一个完全独立的环境。还有一种常被忽略的模式是「不覆盖已有数据」的拷贝——它在目标集团已经存在部分数据但你又不想整体删除时很有用。这三个概念初学者容易混淆的点在于SCC1和SCC9事务码都能发起远程拷贝但SCC9是专门针对远程场景设计的它的界面更简单而SCC1既可以做本地也可以做远程内部通过「目标系统」字段来区分。如果选错模式你会看到复制作业很快结束但目标集团里什么都没有——因为后台作业根本没触发。模式事务码适用场景网络要求覆盖行为本地拷贝SCC1 / SCCL同一系统内建新集团无可选择覆盖/不覆盖远程拷贝SCC9 / SCC0分配跨系统迁移或刷数据RFC连接默认覆盖目标已有数据无覆盖复制SCC1不勾选覆盖选项目标集团数据需要保留无不删除已有数据在动手之前我一般会先看一眼源集团和目标集团的Client Role。用SCC4可以看到每个集团的属性如果目标集团的角色设置有误比如一个本该是Customizing的集团被设成了Production复制结束后某些功能会异常最典型的就是传输请求无法释放。所以在做集团拷贝之前先用SCC4把目标集团的属性确认一遍这个步骤一次都不要省略。2.2 Profile选择逻辑SAP_ALL、SAP_CUST、SAP_USER到底指什么集团拷贝的核心不是事务码本身而是你选择什么样的Profile来限定拷贝范围。SAP系统预置了多个Profile最常用的几个包括SAP_ALL拷贝全部数据、SAP_CUST只拷贝定制化配置不含业务数据、SAP_USER只拷贝用户主数据及授权、SAP_UCUS用户主数据加定制化配置。每个Profile背后实际对应一组表集合SAP_ALL意味着把系统里所有与应用无关且属于集团级别的表全部纳入拷贝范围。这里有一个容易被忽视的关键点SAP_ALL并不等于「整个数据库」。它仍然排除了一些特定的表比如与集团无关的跨集团表以及某些应用在表层面明确标注了「不许复制」的场景。这意味着即便是SAP_ALL复制完成后目标集团和源集团也可能存在细微差异。比如某些应用服务器的本地缓存表、某些序列号计数器表它们在SAP_ALL里也是被排除的。如果你要复制的场景是测试环境想拿到一份包含主数据、业务数据、配置在内的完整副本直接选SAP_ALL通常没问题但如果你的目标集团已经被初始化过并且已有部分定制化配置你只想把遗漏的配置补过去那么选SAP_CUST更科学。对于用户权限同步SAP_USER已经很成熟注意它只会复制用户主记录不会复制角色里定义的权限参数但复制用户和授权参数的前提是目标系统里已经存在相应的角色定义否则用户复制过去也是空权限。在Profile之外SCC1还允许你通过「表清单」自行定义复制范围。如果预置Profile不能满足需求可以选中「手动选择表」通过事务代码SE16N查询表清单后自行勾选。这里强烈建议不要自己通过手动选择表的方式拼一个不完整的Profile因为你极容易漏表而且你在复制后很难定位到底是哪张业务表没跟上。2.3 复制过程中的四个阶段数据导出、传输、导入、激活集团拷贝尽管在外层只是一个事务码内部却是一个多阶段的流水线。了解每个阶段在做什么能够在后台作业出问题时帮你快速定位卡点。第一个阶段是「导出」源集团通过逻辑数据库读取所有需要复制的表数据按照内部格式写入导出文件或内存表。第二个阶段是「传输」如果是远程拷贝数据会通过RFC连接传递到目标系统如果是本地拷贝这个阶段实际上是内部临时存储。第三个阶段是「导入」目标系统逐表写入数据库。第四个阶段是「激活」这一步会执行一些程序生成和设置更新操作包括更新目标集团的T000、设置默认货币、重新生成某些缓存。绝大多数复制失败的场景发生在第三和第四阶段尤其是Big Table大表在导入时容易超时或表空间不足。这里有个运维习惯我一直在用SCC1提交之后不要马上关掉SCC3监控界面至少让它刷新到作业条目生成完毕。后台作业一旦进入运行状态SCC3会显示每个表的复制状态如果你想在复制过程中看到实时进度SCC3是可以做到的很多新手不知道这一点只能干等着作业结束。另外SCC3监控界面看到的「表复制完成」不代表整体复制成功必须看到最终的「复制结束」状态标记才算完整收尾。3. 本地集团拷贝实操SCC1提交一个最小可用复制作业3.1 准备工作用SCC4核实目标集团属性并创建逻辑系统本地拷贝的第一步不是直接输入SCC1而是先确认目标集团是否存在。如果一个集团在系统里不存在SCC1复制过去只会报错。创建新集团的操作在SCC4里完成输入你要创建的集团号填写描述、城市、逻辑系统名称、以及Client Role。Client Role的选择直接影响这个集团后续能不能被传输请求写入Customizing角色允许写入Production角色默认不允许传输请求直接落入。很多项目组在创建测试集团时习惯直接选Customizing但如果是用于最终验证的预生产集团建议选Production并配合手动传输否则后续变更管理的节奏会被打乱。逻辑系统名称这一项需要特别注意。一个集团必须关联一个逻辑系统如果逻辑系统名留空后续做ALE、RFC或系统间通讯时会没法识别这个集团。标准的做法是在SCC4里维护逻辑系统名如果是新建集团可以直接在SCC4界面点保存时一并创建逻辑系统。对于已有集团你需要确认它的逻辑系统名在SCC4里已经维护好而且没有和别的集团冲突。完成SCC4配置之后通常还会顺手处理一下默认参数文件确保目标集团的T000已有正确的货币和语言设置。T000的维护入口是SE16N直接对表T000插入一条记录字段包括集团号、货币、语言、Client Role等信息。如果你不做这一步SCC1复制过程中会自动创建T000条目但自动创建的条目可能缺失某些字段比如完整客户端角色的默认值。经验来看先手工维护T000再执行拷贝能避免后续很多隐蔽问题。3.2 执行SCC1关键字段填写与选项说明SCC1的执行界面看起来字段不多但每个字段的语义都要弄清。它要求输入源集团、目标集团、Profile复制配置文件三个核心要素另外还有几个可选项最常用的是「覆盖目标集团中的数据」和「创建传输请求」。源集团直接填编号即可目标集团如果和源集团相同系统会拒绝执行这也是一个常见的低级错误。我一般会在这个界面里先把Profile选为SAP_ALL第一次跑时不要自定义表范围。如果目标集团里已经有一些你不想保留的历史数据勾选「覆盖」选项系统会在开始复制前先删除目标集团里已存在的表数据然后再写入源集团的数据。不勾选时目标集团的已有数据会保留源集团数据只做叠加和覆盖相同表项某些情况下会产生重复主数据。提交之后系统会询问是否立即启动后台作业这里选「是」并注意记录作业号或作业名。随后打开SCC3监控页面输入刚才的作业名可以看到当前复制到哪张表了。SCC1执行之后不要立刻去目标集团登录尤其是在大表很多的生产系统里复制可能持续数小时。哪怕看起来SCC1已经弹出「已计划作业」的提示后台仍然可能处于等待资源的状态。以下是提交SCC1最简步骤序列对应的就是实际操作界面里每一步动作1. 事务码SCC4 → 确认目标集团属性Client Role选择Customizing或Production 2. SE16N打开表T000 → 检查目标集团是否已有对应条目无则手工插入 3. 事务码SCC1 → 输入源集团、目标集团、Profile如SAP_ALL 4. 勾选「覆盖目标集团中的数据」 → 点击执行 5. 系统提示后台作业已计划 → 记录作业名或作业号 6. 事务码SCC3 → 输入作业名核对总体状态和各表状态逻辑说明第一步做的是环境校准确保目标集团在系统属性层面是一个「能接收数据」的合法集团。第二步是常见补充步骤SCC4创建集团并不一定自动写T000手工维护可以避免因为缺少T000而导致复制落库时报外键错误。第三步之后的动作就是纯粹的执行流程这部分没有特殊的取巧空间核心在于提交之后的监控。参数说明Profile字段决定复制哪些表SAP_ALL指全部集团级别数据包含配置和应用数据勾选覆盖选项后目标集团内所有表在复制前会被清除所以目标集团一定要确认无误再勾选。作业名通常以SAP_COPY_开头SCC3页面的「表目录」视图可以看到单表复制耗时如果某张表一直卡在某个百分比优先怀疑表空间或锁表。3.3 本地拷贝中途报错的处理姿势从SCC3日志追到具体表复制作业进行到一半SCC3界面出现红色状态这是所有Basis都会遇到的场景。处理方法不要一上来就杀作业先看SCC3里具体是哪个表复制失败。SCC3的日志视图可以展开每一张表的详细状态包括错误消息号、表名、已处理行数和耗费时间。拿到表名之后去分析这张表是主数据、事务数据还是配置表再决定处理策略。最常见的错误是TSV_TBL_SPACE_VIOLATED翻译过来就是表空间不足。这个错误会直接导致作业终止而且你需要手动删除目标集团里已复制一半的数据再重新启动复制。处理方式是在操作系统层面确定表空间剩余情况为对应的表空间扩容然后重新执行SCC1。还有一种情况是SQL error during table copy比如表结构在源和目标之间不一致通常发生在版本升级或做了ADD_STRUCTURE之后。这种时候不要硬跑需要做的是使用事务代码SE14调整数据库表结构让它和目标系统的数据字典一致。出现错误之后SCC3里的作业状态是红色的但后台作业可能仍然处于已释放状态如果不及时取消它会不断尝试重启。正确的收尾姿势是在SM37里找到对应的后台作业先取消它的周期执行标志然后再决定是否重跑。重跑前建议在SCC1里重新选择一个新Profile比如只选择SAP_CUST先把配置部分稳定复制过去再考虑用SAP_ALL处理剩余数据。这样做的目的是缩小故障定位范围而不是一口气把所有数据再次堆进去。4. 远程集团拷贝跨系统复制时RFC连接是成败关键4.1 远程拷贝的场景与前置条件RFC用户、目标系统可达性远程集团拷贝最常见的需求是把生产系统的集团复制到预生产或开发系统。从操作上看和本地拷贝最大的区别在于多了RFC连接这个传输通道。没有RFC远程拷贝就是空中楼阁。提前检查源系统和目标系统之间的RFC连接是否通不是等到执行时报错了才查而是在执行前就要确认。创建RFC连接的入口是SM59定义一个指向目标系统的ABAP连接。你要确认的是这个连接里的目标主机、实例号、网关服务是否可通以及连接用户是否有对应的权限。连接用户必须是一个在目标系统里有足够权限的对话用户通常我们会用某个管理员账号专门用于系统间数据交换避免在复制过程中被权限不足卡住。另一个前置条件是源系统和目标系统的版本兼容性。跨版本复制不是绝对不可行但风险很高尤其是一个S/4HANA系统往一个旧的ECC系统复制集团数据字典层面的差异会让复制结果不可预料。经验上同版本或小版本间复制是最稳妥的。如果是大版本跨级复制不建议通过SCC9直接复制数据而是用系统迁移工具或传输请求方式处理毕竟集团拷贝在跨版本场景下既慢又容易出现表结构不兼容。目标系统的数据库空间也要提前确认。远程复制时数据是实时写入的不像本地复制可以先导出全部数据再统一导入。如果目标系统剩余空间不够复制进行到一半会因为数据库无法扩展而中断清理空间再重跑整个耗时翻倍。我的习惯是复制前先估算源集团数据总量用S_ALR_87004333或直接查表TABART、DD02L的数据量再给目标系统的表空间预留1.5倍的空间。4.2 执行SCC9从源系统发起还是目标系统发起这是个考点远程集团拷贝有一个容易搞反的方向问题。SCC9的执行逻辑是你登录在源系统会话连接指向目标系统然后数据从源系统流出流向目标系统。如果你登录在目标系统上执行SCC9指向的是另一个源系统那方向就反了。一定要在你想复制数据的「来源」系统上发起SCC9。SCC9界面上需要输入源集团、目标系统RFC目的地、目标集团、复制Profile。注意目标集团号是目标系统的集团号不是当前登录系统的集团号。如果目标集团的编号在目标系统里不存在SCC9会直接报错所以需要在目标系统上提前用SCC4创建好这个集团。这又意味着远程拷贝的前置动作其实发生在两个系统上源系统测RFC目标系统建集团两边都准备好再发起SCC9。SCC9的多线程设置比SCC1更关键。远程拷贝由于网络和RFC负载的因素如果并发进程设置不当很容易造成目标系统数据库锁竞争和源系统RFC通道拥堵。常见的并发值设置在3到6之间具体取决于两个系统的硬件资源。并发太高可能导致目标系统数据库Hang住太低则复制速度极慢。SCC9界面上没有直接提供并发设置需要你在后台作业定义时通过变式参数控制或者在SCC3里后续调整作业的并行进程数。以下是用SCC9发起一次远程拷贝的完整命令序列和说明1. SM59 → TCP/IP连接 → 创建指向目标系统的RFC连接 → 保存并测试连接 2. 登录目标系统 → SCC4 → 确认目标集团存在且Client Role正确 3. 登录源系统 → SCC9 → 输入源集团、目标RFC、目标集团、Profile 4. 选择覆盖选项根据需求 → 提交后台作业 5. SM37 → 监控远程拷贝后台作业 → 记录作业运行状态 6. SCC3 → 查看表复制明细确认无红叉逻辑说明SM59连接是远程复制的物理通道连接测试必须成功否则后续所有动作都在空转。SCC4确认目标集团是目标系统侧的准备动作和本地拷贝逻辑一致。SCC9提交后有可能会出现RFC连接被服务器拒绝的问题这在跨应用服务器时尤其明显当网关进程过载时额外新建的连接会排队等待。参数说明Profile字段的取值和本地拷贝一致但远程拷贝建议避开SAP_UCUS因为用户主数据在跨系统复制时容易因为角色缺失而产生一堆无效授权。如果目标系统和源系统的用户角色定义不一致复制过去的用户没有任何菜单和权限排查起来非常费劲。4.3 远程复制比本地慢一倍瓶颈定位与加快复制的方法远程复制的瓶颈通常出现在两个位置RFC网络带宽和数据库写入性能。前者可以通过检查网络链路排除后者则需要关注目标系统的数据库日志和重做日志切换频率。如果你看到SCC3里每张表的复制耗时都在增长而且表本身并不大大概率是目标系统的磁盘I/O已经到了瓶颈这时候加并发线程反而会加剧磁盘争用。加快远程复制的有效手段是把大表拆分复制。SCC1和SCC9都支持指定并行任务数量以及按表大小排序复制。在复制大表时可以在SCC3里暂停某些表让它先跳过等整体复制结束后再补跑。具体操作是通过SCC3选中这张表然后设置它的复制状态为「跳过」最后在全部完成后单独对该表执行一次补拷贝。这里注意补拷贝不要用SCC9再跑一遍全量Profile直接在目标系统上通过SCC1从源系统拉这张表速度会快很多。5. 集团拷贝避坑手册5个高频翻车点与排查路径5.1 现象复制结束目标集团正常登录但部分事务码提示无权限原因分析Profile选择SAP_USER或者SAP_UCUS时只复制了用户主数据和部分授权对象角色定义依然依靠目标系统原来的角色数据。如果目标系统里本来就不存在这些角色用户的权限参数全部悬空。即使SAP_ALL复制如果源系统和目标系统的角色描述存在差异比如角色名一致但职责内容不同权限也会发生变化。解决方法复制前在目标系统用SUPC对照确认角色是否存在复制完成后用SUIM检查用户的角色分配情况对缺失角色进行补充分配。不要在不确认角色表的前提下盲目复制用户数据否则你花大量时间做同步最终得到的依旧是权限错乱的账号。另外如果是本地拷贝注意SCC4里目标集团的Client Role如果是Production某些权限继承也不会像Customizing那样宽松。5.2 现象后台作业一直处于Released状态SCC3里看不到表复制记录原因分析作业没有被系统真正启动执行通常是因为后台作业调度资源不足或者复制作业的前置步骤一直处于等待状态。另一种可能你的SCC1提交界面没有真正完成后台化仅仅是作业被记录但未释放。解决方法查看SM37找到这个作业如果状态是Released先检查是否有其他占用资源的作业在跑如果后台作业队列被占满只能等待或调整作业的优先级。如果作业被Schedule但未启动尝试重跑SCC1并换个作业名。注意不要反复提交同一个SCC1作业因为重复作业偶尔会同时触发导致目标集团数据写入重复。5.3 现象复制完成后目标集团里的配置表数据缺失了一部分原因分析这类问题最隐蔽。多数情况是Profile选择了手动或某个不完整的自定义Profile漏掉了部分自定义表。另一种可能表在源集团被逻辑删除但物理数据还在而复制逻辑对这些表做了过滤。解决方法找到缺少的表用SCC1单独补拷贝该表或者用SE16N在源集团里查询该表数据是否存在。确认源数据存在后直接在目标集团通过SCC1重新执行该表级复制。建议长期使用固定Profile不要每次都手动选表如果必须自定义用SCU0或SCC4维护一套标准Profile下次直接复用。5.4 现象复制后目标集团的T000表内容被改写货币或语言不符合预期原因分析SCC1在复制过程中会覆盖T000的数据包括货币和语言如果目标集团之前在SCC4里设置的默认货币和源集团不一致复制后会被源集团覆盖。这个行为在SAP里是硬逻辑不会因为你提前维护了T000而跳过。解决方法复制完成后重新用SE16N打开T000确认货币和语言是否需要改回目标集团的设置。如果是建立测试集团通常希望货币和语言与生产一致那就可以放着不动但如果目标集团有自己的本地化要求比如语言是中文生产是英文复制完需要手工把T000里语言字段改回来。这里有一个技巧把这些T000改动写进一个传输请求下次再做同样复制时直接释放请求即可。5.5 现象SCC1执行后系统提示「源集团和目标集团不能相同」但自己没填错原因分析这个报错其实经常不是因为你填错了集团号而是你在SCC1界面上的「源系统」字段被误填了系统理解为你要把同一集团从同一系统复制到同一系统。解决方法检查界面中的「源集团」和「目标集团」之外还要检查是否存在一个「逻辑系统」字段这个字段如果指向了源集团所属的逻辑系统而目标集团也属于同一逻辑系统系统也会拒绝对相同逻辑系统的复制。此时需要确认目标集团的逻辑系统是否已正确配置为一个独立逻辑系统如果还未配置在SCC4里补上。5.6 现象复制过程中断错误指向特定表但表和业务无关原因分析这类问题常见于数据库统计信息缺失。复制过程中查询优化器选择了错误的执行计划导致某张表一直读取缓慢或锁等待超时。尤其在跨版本数据库或最近做过迁移的系统中统计信息过期是常规现象。解决方法针对报错的表执行DBACOCKPIT里的统计信息更新或者直接使用事务代码DB02针对表空间刷新统计信息。之后再重新启动SCC1。如果仍然复现检查该表是否被其他后台作业锁住SM12里查看锁条目释放后再重试。6. 进阶用法把集团拷贝做成可重复的自动化流程当集团拷贝的频率变高比如每个月都要把生产集团复制到测试集团这时候手工操作SCC1虽然能完成但每次都去核对SCC4和T000不仅累还容易在某个环节疏忽。我的做法是把集团拷贝做成一个可重复执行的流程配合变式Variant和后台作业链一次配置后续只改集团号就能运行。第一步把SCC1的执行参数保存为变式。变式里可以保存源集团、Profile、覆盖选项等参数唯一不能保存的是目标集团因为目标集团每次可能不同。用SE38或SM36创建变式时以SAPCOPY的作业模板为基础把Profile固定为SAP_ALL覆盖选项勾选上。这样每次执行只需要在SM36里输入变式名修改目标集团号就可以提交。第二步把T000的维护也做进流程。通过一个简单的ABAP程序在复制前自动比对源集团和目标集团的T000字段如果不一致就更新。这个程序我一般是挂在SCC1作业前的一个前置步骤这样每次复制前都会自动做一次「环境校准」。如果不想写ABAP也可以直接用SE16N手动更新T000但自动化的价值就在这里显现——你不需要记住每次都要改哪些字段。第三步设置SCC3的自动监控和结果通知。SM36里配置后台作业完成后发送系统日志或邮件给管理员这样即便凌晨跑复制第二天早上看到通知就已经知道结果而不必登录系统逐个检查。SCC3的监控状态可以抽取到表TCOLL或作业日志中通过简单的报表程序把结果导出甚至可以做到复制完成后自动发消息给项目组避免反复人工确认。第四步把复制完的收尾动作做成后置作业。常见收尾动作包括启动目标集团的外围接口Job、重新生成授权数据、检查RFC连接池。某些操作需要手工干预比如确认某个增强是否生效但大部分日常动作已经可以通过后置作业自动完成。我个人的习惯是每次做集团复制都在一个固定的操作清单文件里记录作业名、开始时间、结束时间、复制模式、发现的问题。这个清单文件不复杂就是一个简单的文本记录但长期积累下来每次遇到复制异常时我都能快速对比上一次成功和失败的差异点节省大量排查时间。比如某个表复制失败如果上一次成功时该表耗时已经很大我就会提前关注是不是数据量增长导致的问题。如果你是在一个需要频繁刷新测试数据的团队里照着这个思路把集团拷贝沉淀成一个可重复执行的自动化流程至少能省掉一半的重复劳动。更重要的是把可变参数收敛到集团号之后人为出错的机会也大幅减少复制后翻车的次数会明显下降。希望这篇整理对你有帮助下次做SAP集团拷贝时可以在动手前先看一眼SCC3的状态再决定要不要放心大胆地等待。本文还有配套的精品资源点击获取