SAP集团拷贝Client Copy完整流程与避坑指南

发布时间:2026/10/17 18:52:25
SAP集团拷贝Client Copy完整流程与避坑指南
简介面向SAP Basis顾问及ECC系统管理员的集团拷贝Client Copy操作指南详细讲解在SAP ECC 6.0 32位环境下从000集团复制到新建790测试集团的完整流程涵盖逻辑系统定义与分配、新客户端参数配置、SAP*账号启用、后台作业执行等关键环节并提示逻辑系统属跨集团数据修改将影响所有客户端。资源为单个doc文档压缩包仅776KB便携易用。文档以图文对照形式按步骤梳理操作路径特别指出网传资料存在未经验证的转载错误并针对数据不一致、跨集团表修改、权限不足等典型问题给出排查思路同时预告了后续在新集团中进行物料管理MM模块定制与经典程序收集的方向方便读者延伸学习。已有629人学习下载适合需要独立搭建SAP测试环境、系统掌握Client Copy完整步骤的初中级SAP顾问。1. SAP Client Copy 集团拷贝一装新环境就卡住的复制流程SAP 集团拷贝Client Copy大概是 SAP 基础运维里最容易被“看起来很顺利”骗过去的操作之一。网上一搜 client copy 集团拷贝能找到的教程一大半转载自同一个源头连错误也一起抄了过来真照着走新集团要么登不上要么复制日志里全是红叉。ECC6.0 装完之后默认只有 000、001、066 这几个客户端做业务流程定制、做 SECATT 回归测试都得先另起一个独立客户端。整个过程涉及逻辑系统、客户端参数、RZ10 配置文件和 SCCL 后台作业任何一个参数没对齐后面都没法收场。这份流程按 ECC6.0 32 位实际环境走了一遍从建账号一路讲到复制完成适合刚装完服务器想做隔离定制的顾问也适合不想在生产集团 000 里乱动的基础管理员。2. 复制前准备SU01 建账号与 SALE 定义逻辑系统2.1 为什么不能直接拿 DDIC 和 SAP* 做定制ECC6.0 装完管理员账号就两个DDIC 和 SAP*密码是安装系统时自己设定的。DDIC 理论上权限最大但这两个账号从设计上就不是给人做日常业务定制用的。SAP 的建议是拿它们做系统初始化和紧急维护日常定制开发另建账号。原因不复杂DDIC 改动定制对象时容易触发客户端依赖保护改错一张定制表后面想回滚都找不到干净基线SAP* 在很多新装系统里默认还被登录限制挡着等真能登进去你也未必想拿它做配置。所以第一步先在 000 集团建一个能定制的 ID。原流程用的 T-code 是 SU01直接复制一个 ID 号 JIAHG。注意是“复制”而不是“新建”好处是能把某个模板用户的角色、参数文件、缺省值一起带过来省得手工一项项配。很多人跳过复制直接新建结果后面登录新集团时菜单不全、权限报错反而多花时间。T-code: SU01 用户名: JIAHG自定义示例 复制自: 已有模板用户如有开发权限的账号 页签: 地址 → 密码 → 设置初始密码 复制范围: 用户主记录 角色分配 用户参数逻辑说明复制用户会同时复制用户主记录、角色分配和用户参数。用户参数尤其关键比如默认集团、默认输出设备这些设置藏在里面手工新建很容易漏漏一项后面执行事务码时系统行为就和预期不一样。参数说明模板用户最好挑一个角色干净、权限范围明确的账号来复制避免把一堆无关角色带到新 ID 上。2.2 Define Logical System先看懂跨 Client 警告账号备好就要定义逻辑系统。T-code SALE 进入 IMG 后路径是 Basis settings → Logical System → Define Logical System。点进去系统先甩一条警告Caution: The table is cross-client翻译过来就是“注意此表是跨集团的”。这个提示很多人直接回车就过了但值得停下来看一眼。它的意思是逻辑系统这张表存放的数据是跨客户端共享的也就是说它不是 000 或 790 私有而是数据库层面所有 Client 共用你在这张表里新增一条记录其他集团完全看得见。反过来如果有人在另一个集团删除或修改了这条记录你这边也跟着变。理解了这一点后面就不会对“为什么保存时要弹警告”感到莫名其妙。T-code: SALE 路径: Basis Settings → Logical Systems → Define Logical System 回车 → 确认跨 Client 警告 点击 New Entries 逻辑系统: QAS 名称: Test of Logical Systems Create by Jiahg可任写 保存 → 新建 Request 或选择本地对象参数说明逻辑系统名称在 SAP 里一般取系统角色缩写比如 QAS、DEV、PRD不要带中文和特殊字符。名称字段随意但尽量写清楚这个逻辑系统是谁建、干什么用的后面做 Assign Logical System to Client 时搜索帮助里能一眼对上号。2.3 Request 的保存新建还是复用保存逻辑系统这步会涉及到传输请求Request。新装 ECC6.0 没有可用的请求系统会提示你新建。点新建之后系统生成一个 Request 号再保存逻辑系统才算正式写入。这里有一个常见操作分歧有人为了省事保存时选“本地对象”不建请求有人随手点上了一个已有的请求号结果把跨集团修改挂到了某个要释放的传输路径上。常见做法是新建系统第一次做配置老老实实建一个新的 Request。哪怕你暂时不发传输也保留一个可追溯的变更记录因为跨 Client 表的修改在事后排查“谁在什么时候改了什么”时价值很大。如果环境将来要往别的系统传输这个 Request 还能直接放行。保存逻辑系统时: 1. 系统提示选择 Request 2. 查看已有请求列表SE09 可查 3. 新建请求填入简短描述 4. 保存逻辑系统记录逻辑说明传输请求本质是一个变更记录容器逻辑系统表的数据通过它登记版本。选本地对象和建请求的差别在于选本地对象配置只留在当前系统挂请求将来可以从传输路径发到别的环境。参数说明描述建议写成“New logical system QAS”之类方便后续在 SE09 里快速识别。3. 把逻辑系统挂到 790客户端参数与 SAP* 登录修复3.1 Assign Logical System to Client 的操作流程逻辑系统定义完要把它指派到一个客户端。再次进入 SALE路径是 Basic Settings → Logical Systems → Assign Logical System to Client。点击“Assign Logical System to Client”的瞬间系统又会弹一个警告大意是“此表为跨系统的”直接回车确认。确认后能看到系统里所有客户端的列表000、001、066 等默认客户端都在里面这部分不要动。我们要做的是新建一个 790 作为测试集团点 New Entries进入明细界面把参数一个一个对上。这里的每一项都会影响后续复制别跳着填。参数项设置值说明Client790目标集团号DescriptionTest Of Logic System集团描述可任写City按实际填写示例某测试城市Logical systemQAS上一步定义的逻辑系统Std currencyRMB本位币Client roleCustomizing按需可选 Test / ProductionAutomatic recording of changes勾选自动记录修改Changes to Repository and cross-client CustomizingChanges to Repository and cross-client Customizing allowed允许资源库和跨集团定制更改Protection level0保护级别为零CATT / ECATTEcatt and catt allowed允许运行 eCATT3.2 客户端角色、保护级别与 CATT 的取舍这一组参数里最容易翻车的是客户端角色和保护级别。Client role 选 Customizing表示这个客户端主要用来做定制配置如果你手滑选成 Production系统会拒绝一部分定制写入后面复制完能登录但改定制时会被弹权限错误。选 Test 也可以但既然建这个集团的目的是定制开发Customizing 更贴合流程。生产环境集团不要这样配。保护级别Protection level这一项原文档里设置为 0意思是跨集团对象的修改不做保护限制。这个值只在开发/测试集团里开配合“Changes to Repository and cross-client Customizing allowed”一起使用允许修改 Repository 和跨集团定制对象。生产环境集团保持系统默认避免有人在上面动 Repository。“Ecatt and catt allowed”是为了以后在这个集团跑 SECATT 或 eCATT 测试脚本。eCATT 是 SAP 自动化测试框架的一部分执行脚本时需要在目标客户端开放 CATT 权限现在勾选后面跑自动化测试就不用再回调参数。如果到时候发现这个字段是 NoSCCL 复制完成后还得回头改客户端参数麻烦。3.3 保存后的两次系统弹窗参数填完点保存系统会先弹一条消息“当更改逻辑系统时小心”直接回车。接着看到“Data was saved”说明 790 客户端配置已经写入。注意此时只是把客户端参数定义好790 里还没有任何定制数据SAP* 能不能登录也还是未知数。很多新手到这里以为大功告成直接跳到登录 790然后被 SAP* 登录失败卡住。实际上这只是配置阶段后面还有最关键的一步让 SAP* 能登进新集团。3.4 新装 ECC6.0 的 SAP* 登录限制与 RZ10 参数修改790 建好后文档默认的登录信息是 User: SAP*Password: PASS或安装时设定的 SAP* 密码。但新装 ECC6.0 直接登录大概率失败原因不是密码错而是 SAP 对 SAP* 用户加了 login/no_automatic_user_sapstar 这个限制参数默认值是 1禁止自动登录机制使用 SAP*。此时要回到 000 集团用 RZ10 改参数文件。这一步的操作顺序比参数本身更关键。很多教程只写了“加参数、重启”漏了中间的 Utilities → Import profiles → of active servers。新装的系统如果不先把服务器的 profile 导入到视图里RZ10 的“Profile”搜索帮助是空的你想选都选不到。T-code: RZ10在 000 集团执行 菜单: Utilities → Import profiles → of active servers 确认 profile 导入成功 退回 RZ10 初始界面 → Profile 搜索帮助 → 选择当前服务器 profile Edit Profile 选项 → 勾选 Extended maintenance 点击 Change 新建 Parameter: Parameter name: login/no_automatic_user_sapstar Parameter value: 0 Copy → 保存 停止服务器 → 完全停止后重新启动逻辑说明RZ10 是 SAP 实例参数文件维护入口。要改参数必须先让系统知道当前激活的 profile 是哪些Import profiles 这一步就是干这个的。Profile 名称的命名规则类似 JHG_DEVBMGSOO_SAPIDES其中 JHG 是 ECC 服务器的系统标识SAPIDES 是操作系统计算机名各人环境不同关键是选当前实例对应的那个。参数说明login/no_automatic_user_sapstar 设为 0意思是放开 SAP* 登录限制生产环境不要长期设 0测试环境操作完也可以考虑改回去。改完参数要完全停止服务器再启动只重启 SAP 服务或仅重启对话实例都不一定生效。因为参数文件在实例进程启动时被读取热更新不生效。等服务器起来再回到登录界面SAP* 才能顺利进入 790。4. 执行 SCCL从 000 复制到 790 的完整步骤4.1 用 SAP* 登录 790 并打开 SCCL服务器重启完成后用 SAP* 和密码PASS 或安装时设定的密码登录 790 集团。此时进去系统基本是空的连定制表都没有。直接输入 T-code: SCCL回车。SCCL 是 Client Copy 的调度器进入主界面后需要设定源集团、目标集团和复制方式。原文档场景是把源集团设为 000复制到目标集团 790。复制方式这一栏SAP 标准提供了几个常用 Profile最常见的是 SAP_ALL它会复制客户端特定的定制设置、用户主数据和一部分应用配置业务单据数据不会原样带过去适合搭一个干净可定制的测试集团。如果只想复制用户主数据可以选 SAP_USER如果只想带定制配置可以选 SAP_CUST 或 SAP_APPL 这类裁剪方式。具体列表以你 ECC6.0 屏幕实际显示为准。T-code: SCCL 源集团: 000 目标集团: 790 复制方式: SAP_ALL按需选择 执行方式: Schedule as Background Job逻辑说明SAP_ALL 覆盖面和容量最大对于从 000 复制出一个可用于定制开发的测试集团这是最省心的选择。选择它之后系统会按表清单把 000 里客户端相关的配置逐表读到 790同时写入用户主数据。参数说明如果你打算在这个新集团里继续做 MM 等模块的定制SAP_ALL 至少保证基础框架是一套完整的复制不会出现“这个表有、那个表没有”的怪状态。4.2 Schedule as Background Job为什么不能在前台硬等选好复制方式后下一步点击“Schedule as Background Job”按钮进入后台作业排程。这一步不是可选项集团复制是表级别的批量操作会锁住大量表前台执行耗时又容易超时而且整个屏幕被占用期间什么都干不了。后台作业的好处是交给系统调度你可以定时执行或立即执行人不用守着。后台作业的配置过程不算复杂系统会先弹一个对话框直接回车进入下一步再点“Schedule Job”按钮选择执行时间原文档里选的是“立即”回车后弹出一个对话框点“Continue”确认。这时系统会提示可以用 T-code: SCC3 查看 COPY 日志回车复制就正式开始了。SCCL → 复制方式: SAP_ALL → 点击 Schedule as Background Job → 弹窗回车确认 → 点击 Schedule Job → 执行时间: 立即 → 回车 → Continue → 提示可用 SCC3 查看日志逻辑说明后台作业排程实际是把集团复制任务包装成一个批处理作业交给系统后台进程去跑。选择“立即”意味着作业被直接释放进入等待执行队列你也可以指定未来某个时间点生产环境通常这么干。参数说明如果你在一个负载较高的服务器上做复制建议把时间设到低峰期避免和其他批处理作业抢资源。4.3 复制中段会发生什么复制过程中SCC3 日志会持续追加内容。能看到系统在逐表处理有的表插入记录有的表删除记录还有一部分表跳过。日志里能清楚看到表名、记录数和耗时。复制耗时取决于 000 的数据体量、服务器磁盘 IO 和数据库配置有的环境几十分钟有的要几个小时。这个阶段不要去手工调整 790 里的数据也不要重复触发 SCCL。实在要中断只能在后台作业管理里终止对应作业然后根据 SCC3 日志评估数据完整性必要时清空 790 重新复制。复制完成后SCC3 日志会给出一个整体状态这是下一章验证的主要依据。5. 避坑实录同源教程和五个常见问题网上关于 Client Copy 的资料很多但认真分析后会发现问题都出在同一个源头大多数转载只是复制粘贴根本没做过验证连错误一起传下来。这里挑五个实际环境中出现频率最高的坑按“现象 → 原因 → 解决”写清楚。5.1 现象一改完逻辑系统其他 Client 跟着中招现象在 000 里定义逻辑系统 QAS 并保存后没过多久发现 001 客户端或另一个测试集团里的配置也被牵连菜单结构或者某些定制表的值发生了变化。原因SALE 里那两条警告不是摆样子的。“The table is cross-client”说明逻辑系统相关的数据库表是跨集团共享的客户端表 T000 也一样。你在 000 里新增一条记录其他集团完全可见有人对已有条目做了修改影响范围是全部客户端。解决定义逻辑系统时只做“New Entries”绝不修改已有条目尤其是 000 自带的逻辑系统保持原样。如果在 Assign Logical System to Client 界面看到警告确认自己是在新增 790 而不是编辑既有客户端。只要坚持“只加不删”跨集团串数据的影响就可控。5.2 现象二RZ10 加完参数SAP* 还是登不上 790现象login/no_automatic_user_sapstar 设置为 0也点了保存服务器重启过但登录 790 时 SAP* 仍然报认证错误或直接卡在登录界面。原因最常见的是没有真正把参数写进当前实例读取的 profile或者没有走 Extended maintenance 模式还有人是只重启了对话实例没有把服务器完全停掉再启动参数文件根本没重新加载。解决回到 RZ10点 Display 查看参数列表确认第一行真的是 login/no_automatic_user_sapstar 0。如果没看到重新走一遍 Extended maintenance → Change → 新建参数。停服务器时选择完全停止等进程全部结束后再启动。如果还不行用 RZ11 查看运行时参数值确认改的是不是当前激活的 profile。5.3 现象三复制日志大量红叉记录数对不上现象SCC3 日志里出现大量红叉某个表复制 0 条或者合计记录数和源集团明显不一致。原因目标集团 790 里有残留数据一般是上次复制失败留下的半截结果或者复制过程中有用户同时在 000 里操作主数据和定制表数据处于变化状态也可能是复制方式选得不对裁剪掉了部分需要的数据。解决先不要在原基础上补复制老老实实把 790 清空重新来过。可以用 SCC5 清空目标集团或者直接删除 790 再重建客户端。复制期间把 000 锁住禁止其他用户写入保证源数据在一个静态快照上。复制方式不确定时就用 SAP_ALL避免裁剪造成数据不完整。5.4 现象四Request 选错跨集团修改被带到了其他环境现象保存逻辑系统时系统弹出 Request 选择窗口随手选了一个已有的请求号后来这个请求被释放改动被传输到了另一套系统引发配置漂移。原因新装系统 Request 列表本来应该是空的但如果之前在同一个请求跨 Client 对象上做过其他修改列表里就会有历史请求。没有仔细看描述就选上去新改动被归入了旧请求的传输范围。解决新建请求时看清请求描述如果是本机测试环境保存时直接选“本地对象”不释放。如果一定要建请求新建一个独立的 Request不要复用历史请求。传输路径上不确定的请求尽量别去碰发出去就收不回来了。5.5 现象五后台作业一直显示 Scheduled没有实际执行现象SCCL 里点了“立即”到 SM37 查看后台作业发现状态一直停在“已计划”Scheduled没有进入“运行中”或“已完成”状态。原因后台作业的执行依赖应用服务器的批处理工作进程。如果系统刚重启完批处理进程还没有完全就绪或者作业被调度到了另一台负载过重的应用服务器作业就会一直排队。解决用 SM37 打开作业日志确认作业状态和调度时间用 SM51 查看应用服务器状态确认当前实例的批处理进程是绿的。必要时手动 Re-schedule 这个作业或者把作业调度到负载更低的应用服务器上执行。不要反复触发 SCCL否则会产生多个复制作业抢数据锁更难收拾。6. 验证与收尾SCC3 日志检查与登录冒烟测试6.1 三步检查日志状态、用户数据、定制表打开 T-code: SCC3查看复制日志。重点看三条信息作业执行状态、错误消息数量、每个表复制记录的合计。干净的集团复制日志末尾应该是成功状态没有“ABORTED”或“STATUS: ERROR”错误消息列表为空。如果有红叉先对照 5.3 排查不要带着错误往下走。用 SAP* 重新登录 790依次执行几个事务码做冒烟测试。SU01 打开用户主数据能看到被复制过来的用户 JIAHG 及其角色信息这证明用户主数据移植成功SE11 查看任意定制表比如 T001能看到公司代码相关配置已经带过来再跑一个简单的 ABAP 报表做读取测试比如 SA38 执行一个系统标准程序确认数据库查询正常。这几步全过这个 790 就具备继续做定制开发和测试的条件了。6.2 复制完成后的收尾习惯复制完成后建议在 790 里再确认一次客户端参数没有被复制过程改动尤其是 Client role 和 CATT 设置。如果后续要在这个集团里跑 SECATT事先就要把“Ecatt and catt allowed”确认好不要等脚本报错再回头找原因。实际经验是集团拷贝这套流程每一步产生的现象都能在 SCC3 日志里找到对应线索。从那以后我每次做完集团拷贝都强制走一遍“SCC3 日志确认无错 → SU01 验证用户 → SE11 验证定制表 → SA38 验证可执行”这四步省掉过不少返工时间。希望帮到你。本文还有配套的精品资源点击获取