简介：SAP集团拷贝Client Copy操作手册，面向刚完成ECC 6.0 32位系统安装、需要从生产集团000复制出测试或定制集团的SAP Basis管理员与开发人员。文档围绕逻辑系统定义与分配、新集团参数设置、SAP登录及SCCL后台排程等关键环节展开，并补充RZ10参数调整、跨集团表提示、权限与数据一致性等常见问题的排查思路；对客户端角色、标准货币、自动记录修改、跨集团对象更改许可及ECATT允许等选项也有说明。文档还记录了SAP默认关闭时导入活动服务器参数并重启的处理，以及传输请求保存、表跨客户端共享风险等注意事项。资源包含1个doc文件，约776KB，以分步说明结合界面截图组织，便于对照系统界面逐步核验。已有630人学习，适合需要独立完成集团拷贝、搭建隔离测试环境并保护生产环境安全的初、中级SAP技术人员参考，也可作为定制开发前的环境准备清单。
1. 从 000 复制出一个 790：这件事值得先做对
刚装完 ECC 6.0，手上只有 000 一个集团，接下来要往里面塞 MM 的定制、做流程数据导入、写程序、跑测试。直接在生产 000 上动手，等于拿唯一的干净环境当试验田，改坏一次就得重装。SAP 集团拷贝（Client Copy，国内顾问习惯叫"客户端拷贝"）就是解决这个问题的：把 000 的定制、仓库对象、必要的用户主数据整体搬到新建的 790 里，之后所有折腾都在 790 完成，000 保持可回退的原始状态。
这份手册要走通的链路是 SALE 定义逻辑系统 → SU01 建管理员 → RZ10 打开 SAP* 登录开关 → SCCL 调度 → SCC3 看日志。适合刚接手 Basis 活的 ABAP/MM 顾问，也适合一个人要独立撑起整套测试环境的运维。里面的坑都是照着原笔记一步步敲进去才发现的，网上一大票同源资料没验证过，跟着抄会卡住。
2. 逻辑系统与集团主记录：SALE 里两步配置改的到底是哪张表
动手之前先把选型说清楚，不然容易在 T-Code 之间绕圈。SAP 里跟集团拷贝沾边的操作有一串：SCCL、SCC4、SCC5、SCC7、SCC8、SCC9，名字像亲兄弟，用途差得远，搞错方向就是事故。
2.1 SCCL、SCC8、SCC9 各管什么，先分清再动手
SCCL 是本地集团拷贝，源和目标都在同一套系统里，日志和调度也都在本机，最常用的就是从 000 复制出 790、800 这类测试集团。SCC8 是导出，把某个集团的内容打成文件放到传输目录；SCC9 是导入，在另一套系统里把这份文件灌进目标集团。两者合起来才是跨系统拷贝，中间还依赖 STMS 的传输路由。SCC4 用来维护集团属性（角色、是否允许登录、是否自动记录修改），SCC5 是删除集团，属于清理动作，点错没有后悔药。
这套流程里还会碰到一个容易被忽略的细节：在 SALE 里分配逻辑系统，系统会弹"此表为跨集团的"警告。很多人直接回车跳过，其实这句警告是有实义的——逻辑系统定义存在 TBDLS 里，这张表没有 MANDT 字段，全系统所有集团共用一份。你在 790 相关的界面里新建了一个叫某代号的逻辑系统，000、001、066 的逻辑系统分配界面上都能看到它。所以命名要按全局标准来，别随手写个只有自己看得懂的名字，后面接外围系统、配 IDoc、做 ALE 分发时会对不上。
选型建议很朴素：本地测试集团用 SCCL，跨系统搬环境用 SCC8 + SCC9，只想搬一部分配置用 SCC1 挂传输请求。新手最常见的误用是拿 SCC8 当本地拷贝用，导出的文件其实要落到传输目录再由 SCC9 读，中间环节一多，出错定位就变难。
2.2 定义逻辑系统：SALE 第一步和 Request 的处理
登录 000，用 DDIC 进系统，执行 SALE。不同版本菜单层级略有差异，找 Basis Settings 下的 Logical Systems 节点即可，点 Define Logical System 进入维护界面。系统先弹跨集团表的警告，回车继续，点 New Entries 新增一行。
这里要填两列：Logsyst 是逻辑系统名，按惯例用三字符大写代号，比如 QAS 表示测试；Name 是描述，写成能让人一眼看懂用途的短语，比如"测试环境逻辑系统，用于 790 集团"。描述别写个人的名字缩写，等半年后回来看，谁也记不起这是谁建的。
保存时会要求挂一个请求号。新装的系统里通常还没有可用请求，直接在弹出框里新建一个，请求描述写"client 790 初始化配置"，把这次所有配置都塞进同一个请求，将来要重建环境时把请求放出来重放一遍就行。这一步属于"给自己留后悔药"的动作，很多人图省事随便建一个 unnamed 请求，后面想查改了什么都查不到。
提示：如果 SALE 里点 Define Logical System 提示无权或者直接报错，先确认当前用户是不是 DDIC 或 SAP*，以及该用户有没有 S_CTS_ADMI 相关权限。定制账号不允许做系统级配置，这是设计如此，不是系统坏了。
2.3 把逻辑系统挂到 790：T000 里实际改了哪几个字段
回到 SALE，走 Basic Settings → Logical Systems → Assign Logical System to Client。又一次跨集团警告，回车。进来这一屏会列出系统里所有集团，前三个是安装时自动生成的默认条目，不用动。
点 New Entries 新建 790，参数逐项落到下面这些字段上：
| 字段 | 本例取值 | 说明 |
|---|---|---|
| Client | 790 | 新建集团号，避开 000-099 的系统保留段 |
| Client Name | Test Of Logic System | 显示名，写清用途即可 |
| City | 内部约定的站点代号 | 别填真实办公地点，写团队内部代号更合适 |
| Logical system | QAS | 上一步定义的逻辑系统，可用搜索帮助选 |
| Std currency | RMB | 集团本位币，定了之后再改代价很大 |
| Client role | Customizing and Development | 定制开发角色，测试期最常用 |
| Automatic recording of changes | 勾选 | 开发期自动记对象修改，上线前关掉 |
| Cross-Client Object Changes | Changes to Repository and cross-client Customizing allowed | 允许改仓库和跨集团定制 |
| Protection level | 0 | 无覆盖保护，测试集团不需要 |
这张表背后其实是 T000 的集团主记录，其中的 LOGSYS 字段被赋值为 QAS。想验证有没有写进去，用 SE16 打开 T000，按 MANDT = 790 查一条记录，看 LOGSYS 列是不是 QAS，改完立刻能确认。这一步比盯界面上的"Data was saved"可靠得多，保存成功不等于字段值符合预期，尤其是填了搜索帮助之后又手工改过的情况。
Currency 和 Client role 是两项后面很难回头的参数。本位币一旦有业务数据就改不动，客户角色从 Customizing 改成 Production 只是个下拉切换，但切过去以后 SE38、SE80 的修改入口会受限。所以建 790 的时候按"先开发后测试"的路径规划，别一上来就设成 Production，后面再手忙脚乱地切回来。
保存时可能弹"当更改逻辑系统时小心"的提示，回车确认即可。注意这个提示不是错误，只是在提醒你 T000 的这次写入会影响该集团后续跟外围系统的对应关系。
2.4 参数之外的隐性动作：请求号要归拢
整个第 2 章一共会生成两类东西：跨集团的 TBDLS 条目和集团级的 T000 条目。前者跟着请求走，后者也留痕。我的习惯是每做完一段配置就在请求描述里追加一句备注，比如"含逻辑系统 QAS 定义、790 集团主记录"，别指望三个月后的自己还记得当时点了哪个按钮。
如果这套系统将来要给多个人用，建议把逻辑系统命名和集团号编成一张对照表，写进团队内部的知识库。SAP 系统里跨集团表一旦污染，清理起来比新建还麻烦，宁可动手前多花十分钟定规则。
3. 账号与 SAP* 登录开关：SU01 建号、RZ10 改参数
集团建好了，接下来要解决"用谁登录"的问题。这一步在原始笔记里被压缩成几行，实际踩起来坑不少，我按顺序拆开。
3.1 为什么不能拿 DDIC 做定制
DDIC 是系统安装时创建的数据字典维护账号，权限大得离谱，但它被设计成不做业务定制的角色。用它登录 790 跑 SPRO，要么入口被限，要么某些操作会因为缺少特定业务角色而报权限错。SAP* 同理，它是应急账号，只在系统维护时用。
正确做法是复制一个带完整业务权限的管理员 ID，日常用这个 ID 干活，DDIC 和 SAP* 收起来只在系统级操作时用。这不是洁癖，是减少误操作的手段：一个能改任何东西的账号天天挂着，手滑的概率迟早会兑现。
3.2 用 SU01 复制出一个管理员 ID
登录 000，执行 SU01，输入一个参照用户，比如 DDIC，然后走复制功能生成新用户。关键参数如下：
| 字段 | 取值 | 理由 |
|---|---|---|
| User | 自定义，如某管理员代号 | 别用 sapstar、admin 这类通用名 |
| Last name / First name | 内部约定的标识 | 方便审计时识别是谁 |
| User type | Dialog | 日常操作使用 |
| Initial password | 强口令 | 首次登录强制改密 |
| Roles / Profiles | SAP_ALL、SAP_NEW | 管理测试环境够用，生产环境严禁 |
复制完的账号先别急着用，回到 790 里还没有可用用户，所以顺序是：先在 000 里把账号建好，等 SCCL 拷贝完成，这个账号会随用户主数据一起进 790。这里就引出一个关键的取舍——如果拷贝 profile 选的是 SAP_ALL 或 SAP_USER，用户主数据会被带过去，SAP* 也会被带过去，密码还是从 000 来的那个值；如果选 SAP_CUST，790 里除了 SAP* 什么都没有。
我的做法是从 000 拷贝时带上用户主数据，省得在 790 里再建一遍权限角色，代价是拷完之后 790 里所有用户密码都跟 000 一致，必须立刻改一遍，尤其是 SAP*。
3.3 SAP* 登不进去：RZ10 参数、profile 导入和重启顺序
新装的 ECC 6.0，用 SAP* / PASS 登录 790 有时会失败，报用户名或密码错误。这不是密码记错了，而是login/no_automatic_user_sapstar这个参数在起作用。
参数含义要说清：值为 0 时，系统每次启动会检查各集团里是否存在 SAP*，不存在就自动创建，密码固定为 PASS；值为 1 时禁止这个自动创建行为，此时如果 SAP* 被删或没建，就真的登不进去。所以"新系统登不上"的真实原因往往是某个安全基线模板把参数设成了 1，而不是系统默认关闭了它。原始资料里把这一步写成"系统默认账户 SAP* 是关闭的，需要配置参数"，方向对但表述含糊，照着抄很容易在"到底改成 0 还是 1"上卡住。
操作路径：用 DDIC 登录 000，执行 RZ10。先进菜单 Utilities → Import profiles → of active servers，把当前活动服务器的 profile 导入一遍。新装的系统如果没做过这一步，Profile 的搜索帮助里是空的，直接去选参数名会什么都选不到，这是第一个卡点。
导入完成后回到 RZ10 初始界面，通过 Profile 搜索帮助选中你系统对应的实例 profile。它的命名一般是"系统标识_主机名_SID"这种拼接形式，各人安装的系统不同，前缀后缀都不一样，按自己环境实际显示的去挑，别照抄别人的字符串。
选中后选 Extended maintenance 扩展维护模式，点 Change，再点 Parameter 新建一行：
- Parameter name：
login/no_automatic_user_sapstar - Parameter value：
0
点 Copy 带回参数列表，保存。然后点 Display 确认新参数确实出现在列表里，这一眼很关键，因为保存成功和参数生效之间还隔着一次激活和一次重启。
接着停应用服务器，确认完全停止后再启动。系统启动时才会读新 profile，热改不生效。重启后回 790 用 SAP* / PASS 登录，进去第一件事是 SU01 改密码，第二件事是确认第 3.2 节建的管理员账号已经存在并可登录。
注意：如果在实例 profile 和默认 profile 里同时存在这个参数，实例 profile 的优先级更高。改了默认 profile 却不见效，多半是实例 profile 里那份覆盖了它。
3.4 参数生效后必须补做的三件事
参数打开只是临时通道，不是长期状态。SAP* 的密码 PASS 是公开常识，测试环境也一样要收口，尤其当系统接进了公司内网。
第一件，用 SAP* 登录后立刻改密码，改成符合公司口令策略的强口令。第二件，确认 DDIC 的密码也改过，安装时设定的初始口令往往沿用了模板。第三件，如果拷贝带过来了用户主数据，用 SU10 或者批量方式把一批测试账号锁掉或者重置口令，别留一堆默认密码的账号在 790 里。
做到这里，790 具备了"能登录、能配置、有可用管理员"的三个条件，可以开始真正的拷贝动作了。
4. SCCL 调度本地集团拷贝：profile 选择到后台作业落地
到这一步很多人会翻车在方向问题上。SCCL 的规则只有一条：在目标集团里发起。也就是说，要往 790 复制，就得先登录 790，然后执行 SCCL，源集团填 000。在 000 里执行 SCCL，目标就是 000 自己，等于拿一份数据覆盖自己，轻则定制回滚，重则业务数据被清，这是整个流程里最贵的一课。
4.1 登录 790 发起 SCCL：界面参数逐项过
用新密码的 SAP* 或管理员账号登录 790，执行 SCCL，界面上的参数按下面这套走：
| 参数 | 取值 | 说明 |
|---|---|---|
| Selected profile | SAP_ALL | 全量拷贝，含定制、仓库对象、用户 |
| Source client | 000 | 源集团号 |
| Target client | 790 | 灰显，就是当前登录的集团 |
| Maximum number of parallel processes | 1 到 4 | 单机测试环境别贪多 |
| Test run | 先勾一次 | 只做检查不写数据 |
| Start | Immediately 或指定时间 | 生产环境走停机窗口 |
并行进程数这一项值得单独说。它决定同时开几个后台进程跑表传输，设得高确实快，但单机装的 ECC 6.0 内存和表空间都有限，四五个进程同时灌数据，很容易把数据库日志写满，作业被数据库层面中断，日志里只留一句语焉不详的错误。测试环境我一般固定 2 个，等第一次跑通、摸清数据量之后再调。
Test run 是免费的检查机会，它会验证权限、目标集团状态、表空间余量，不写业务数据。跑一遍模拟，把报错先清掉，再跑真拷贝，能省下大量回滚时间。跳过模拟直接上，碰到的第一个错误往往就发生在写了几个小时的进度之后。
Profile 的选择直接决定 790 里有什么，常见的几个选项差别如下：
| Profile | 包含内容 | 适用场景 |
|---|---|---|
| SAP_ALL | 定制 + 仓库对象 + 应用数据 + 用户主数据 | 从 000 这类几乎无业务数据的集团初始化测试集团 |
| SAP_CUST | 仅定制数据 | 只要配置，业务数据和用户手动补 |
| SAP_APPL | 定制 + 应用业务数据 | 需要带着业务样例数据一起测试 |
| SAP_USER | 仅用户主数据 | 补账号用，通常和别的 profile 组合 |
| SAP_UCUS | 用户主数据 + 定制 | 想省掉业务数据但保留账号体系 |
从 000 复制到 790 的常见组合是 SAP_ALL，因为 000 本身是干净集团，业务数据基本为空，全量搬过去不会带一堆垃圾数据。反过来说，如果源集团是跑了几年业务的生产集团，选 SAP_ALL 就意味着把几年的凭证、物料、供应商全搬进测试环境，体积和一致性风险都会成倍增长，这时候应该用 SAP_CUST 加按需导出业务数据。
4.2 调度后台作业：别用前台硬扛
界面下方有 Schedule as Background Job 的入口，点进去会弹确认框，回车后进入开始条件设置，选 Immediately 表示立即执行。接着系统会让你确认调度，点 Schedule Job 完成排程。这一步的意义是把拷贝放进后台批处理，前台会话断掉也不影响，几小时的任务可以关掉电脑回家。
排完之后用 SM37 查作业状态，作业名通常带集团号和拷贝标识，状态从 Released 走到 Active 再到 Finished。如果一直是 Released，说明后台工作进程被别的作业占满了，或者作业类被限制，去看 SM50 的进程占用。如果跑到一半变 Canceled，别急着重跑，先按第 5 章的顺序查日志。
调度的开始时间有一个容易忽略的点：如果排到晚上执行，而晚上恰好有别的批处理作业在跑大批量数据，两边抢表锁，拷贝会卡在某个表上不动。测试环境反而应该选一个确定没人用的时间窗，哪怕是工作时间，只要没人动系统。
4.3 拷贝期间哪些事不能做
拷贝期间最忌讳的是"顺手改点东西"。SCCL 跑起来之后，目标集团 790 会被系统锁住，登录可能被拒绝，或者进去之后无法做定制修改，这是正常的保护机制。但源集团 000 是开放的，有人图方便在 000 里调一个配置，那这个配置要么被拷进去，要么拷到一半状态不一致，日志里就出现莫名其妙的表级错误。
同样的道理适用于传输请求。拷贝过程中不要往系统里导传输，也不要释放请求，传输导进去的对象和拷贝正在写的表可能冲突，尤其是跨集团表。
还有一个常被忽略的动作：拷贝前用 DB02 或数据库层面看一遍表空间余量。ECC 6.0 里集团拷贝会产生大量日志和临时数据，日志文件写满导致作业中断是很典型的现场，日志里只有一行数据库错误码，不看数据库日志根本不知道为什么。
5. 拷贝翻车排查：五类高频失败的现象、原因与处置
SAP 的拷贝失败信息往往藏在三个不同的地方：SCC3 给集团拷贝层面的结论，SM21 给系统日志，ST22 给 ABAP dump。只看其中一个，很容易得出错误判断。我的习惯是按 SCC3 → SM21 → ST22 → 数据库日志的顺序往下钻，一层层排除。
5.1 五条踩坑记录
第一条：在 000 里执行了 SCCL。
现象：作业跑完，000 的定制数据出现异常，某些配置回到初始状态，SCC3 日志显示目标集团是 000。
原因：SCCL 的目标集团恒等于当前登录集团，登录 000 执行就是把 000 覆盖。
解决：立即停掉相关业务操作，从备份恢复，或者用之前留的配置请求重放关键配置。事后必做的事是给 SCCL 加口头禁令：任何人在执行前必须先报当前登录的集团号。
第二条：790 登录被拒，报"该集团不允许登录"。
现象：拷贝完成，用管理员账号进 790 被弹回，提示集团被锁定或不允许登录。
原因：SCC4 里 790 的 Client role 被设成了 Production，或者拷贝过程中系统对该集团加了保护；另外 SCC4 的"Client is locked"标志也可能被勾上。
解决：用 SAP* 或 DDIC 登录 000，执行 SCC4 找到 790，把角色改成 Customizing and Development，清掉锁定标志，保存后重新登录。改完记得回 790 验证一次 SE38 能不能进。
第三条：SAP改完参数还是登不上。*
现象：RZ10 加了login/no_automatic_user_sapstar = 0，重启后 SAP* / PASS 依旧报错。
原因：参数存在实例 profile 和默认 profile 两份，实例 profile 优先；或者改完没有重启应用服务器；或者 SAP* 在 790 里已被删除而参数值是 1。
解决：在 RZ10 里用 Display 确认参数落在实例 profile 上，重启整个实例而不是只重启数据库；如果 SAP* 被删，先把参数置 0 重启让它自动重建，登录后立刻改密再把参数恢复成 1。
第四条：作业跑一半中断，SCC3 里大量表显示未拷贝。
现象：SCC3 日志中若干大表标红，提示空间不足或者进程被终止，SM21 里有数据库错误。
原因：并行进程数设得过高，或者数据库日志空间、表空间余量不足。
解决：清理日志和表空间，把并行进程降到 1 到 2，重跑一次。注意重跑前确认目标集团状态，必要时用 SCC5 把 790 删掉重建，比在半个状态的集团上续跑干净。
第五条：逻辑系统名在别的集团里也看得见，被同事误改。
现象：某天发现 790 的 LOGSYS 对不上，追溯发现是别的集团维护逻辑系统时改了同一条记录。
原因：逻辑系统定义在 TBDLS 这类跨集团表里，全系统共享一份。
解决：约定命名规范并集中管理，重要系统把 SALE 相关权限收归少数几个人；发现被改后，在 SALE 里改回来，并用 SE16 查 T000 确认 790 的 LOGSYS 仍然指向正确值。
5.2 拷贝前的检查清单
把上面这些坑反过来写成检查项，动手前逐条过一遍，能省掉大部分返工：
- 当前登录的是不是目标集团，SCCL 界面上的 Target client 显示的是什么；
- 790 在 SCC4 里的角色是不是可登录、可配置，有没有被锁；
- SAP* 或管理员账号能不能正常登录 790；
- 选定的 profile 是否匹配源集团的数据性质，SAP_ALL 只适合干净源集团；
- 并行进程数是否控制在基础设施扛得住的范围内；
- 表空间和数据库日志余量是否足够，DB02 看一眼；
- 拷贝时间窗内源集团有没有批处理作业或业务操作；
- 配置请求号是否已经归拢，出事能不能重放。
这份清单不复杂，但每一条对应一次真实翻车。尤其第 1 条和第 8 条，前者决定事故规模，后者决定恢复速度。
6. 拷贝完成之后：用条目数比对和 SCC3 明细验证结果
作业状态变成 Finished 不等于拷贝成功，SCC3 里点进去看明细才算数。双击已完成的拷贝作业，能看到按表列出的传输结果：拷贝了多少条、跳过多少条、哪些表报错。"already exists"或"not copied"这类提示有一部分是正常的，比如某些空表本来就没有数据，某些系统表不允许拷贝；但出现成片的红色条目，就得回到第 5 章的顺序排查。
比看日志更硬的办法是自己数一遍。建一个临时报表，对几个关键表统计条目数，跟源集团对比。ABAP 写法如下：
REPORT zclient_cnt. * 统计指定集团下若干关键表的条目数，用于拷贝前后比对 PARAMETERS: p_mandt TYPE mandt DEFAULT '790'. DATA: lv_t000 TYPE i, lv_t001 TYPE i, lv_tadir TYPE i, lv_mara TYPE i. SELECT COUNT(*) FROM t000 INTO lv_t000 WHERE mandt = p_mandt. SELECT COUNT(*) FROM t001 INTO lv_t001 WHERE mandt = p_mandt. SELECT COUNT(*) FROM tadir INTO lv_tadir WHERE mandt = p_mandt. SELECT COUNT(*) FROM mara INTO lv_mara WHERE mandt = p_mandt. WRITE: / 'T000 :', lv_t000, / 'T001 :', lv_t001, / 'TADIR :', lv_tadir, / 'MARA :', lv_mara.逻辑说明：T000 里每个集团一条记录，用来确认 790 的主记录存在；T001 是公司代码，反映定制数据有没有搬过来；TADIR 是仓库对象目录，直接体现开发对象数量，是判断"程序、函数、类有没有跟着过来"最快的指标；MARA 是物料主数据，反映业务数据规模，如果源集团是干净的 000，这里应该是 0 或很少。
参数说明：p_mandt是集团号，类型用 MANDT，默认值给 790，跑的时候可以改成 000 做对照。把两次的输出并排看，定制类表（T001、TADIR）应该接近一致，业务类表（MARA）按你选的 profile 决定。注意 TBDLS 这类跨集团表没有 MANDT 字段，别往里加条件，加了直接语法报错。
我在实际比对时会再加一步：用 SE16 查 T000 确认 790 的 LOGSYS 是预期的逻辑系统代号，CCCATEGORY（集团角色）是允许定制的类别，这两个字段错了，后面的配置都会别扭。
拷贝完成后的收尾动作有几个固定项：回 SCC4 把"自动记录修改"的勾去掉（除非还要继续做开发留痕），把客户角色定成阶段需要的值；用 SU01 清理或重置随拷贝带过来的测试账号；如果 790 要作为传输目标接收其他系统的请求，去 STMS 里把它加进目标集团清单，并在传输路由里确认可达。
还有一个容易被跳过的验证：随便挑一个业务场景走一遍。比如进 SPRO 打开一个 MM 的定制节点看看能不能改，进 SE38 打开一个自建程序看看能不能激活，进 SE16 查几张主数据表。这三下花不了五分钟，但能提前暴露权限、角色、仓库对象三类问题，比等业务顾问在 790 里开工后才发现要强得多。
从那以后我每次做集团拷贝，都会先把目标集团号写在便签上贴在屏幕边上，执行 SCCL 前盯着它核对一遍，跑完再用那个小报表数一遍表条目数——这两步看着笨，救过我至少两次。希望帮到你。
本文还有配套的精品资源，点击获取
