SAP ECC 6.0 Client Copy 实操指南：解决 SCC3 无日志、SAP* 登录失败与权限阻断

简介：本资源是一份面向SAP ABAP开发人员、系统管理员及ECC实施顾问的实战型Client Copy（集团拷贝）操作指南，聚焦SAP ECC 6.0 32位环境下的跨客户端数据复制全流程，解决测试环境快速搭建、定制开发隔离与生产系统保护等核心问题。文档以Step-by-Step方式详解逻辑系统定义（SALE）、客户端分配（Assign Logical System to Client）、ID号创建（SU01）、参数配置（RZ10启用SAP*登录）、后台作业调度（SCCL）等关键环节，并特别指出跨客户端表风险、权限限制规避、常见配置错误辨析等易被忽略的实操细节。资源为1个776KB的Word文档（.doc），内容结构完整，含界面截图提示、参数值示例（如Client 790、Logical System QAS、Currency RMB）、安全设置说明（Automatic recording of changes、Cross-Client Object Changes选项）及社区更新指引。目前已有631人学习下载，适合中高级SAP从业者用于环境复现、流程验证与故障排查参考。

1. SAP ECC 6.0 Client Copy 实操落地：为什么刚装完的 000 客户端一复制就卡在 SCC3 日志空白、SU01 报错“User not authorized”、甚至 SAP* 登不进 790？

这不是配置疏漏，而是 ECC 6.0 32 位系统里一套被严重低估的「环境耦合链」——从 profile 参数加载顺序、逻辑系统跨客户端写入权限、到 client role 与 change recording 的开关组合，任意一环没对齐，Client Copy 就会静默失败：作业看似跑起来了（SCCL 提示“Job scheduled”），但 SCC3 查不到日志；或者 790 能进登录界面，输完 SAP*/PASS 却弹出“Invalid user/password”，连 DDIC 都救不了。我见过某高校实验室三台全新 ECC 6.0 虚拟机，两台因 RZ10 没 reload profile 直接卡死在 client copy 前置检查，第三台靠手动补login/no_automatic_user_sapstar = 0才勉强进 790，结果定制时发现 MM 模块所有事务码全灰——根源是Cross-Client Object Changes选项选成了 “Not allowed”。这套流程不是点点按钮就能过，它是一套必须按毫米级精度咬合的齿轮组。本文专为已装好 ECC 6.0 32 位服务器、手握 DDIC 和 SAP* 密码、正卡在 client copy 第一步的开发者/实施顾问而写。不讲 SAP 架构原理，只拆解你此刻终端里要敲的命令、GUI 里要勾的 checkbox、以及报错时该盯哪行日志。所有步骤均经 ECC 6.0 EHP7 SP12 环境实测，适配 Windows Server 2008 R2 + Oracle 11g 场景。

2. 准备工作：账号、逻辑系统、客户端角色三件套必须闭环

Client Copy 不是数据搬运工，它是 SAP 权限体系的一次压力测试。DDIC 和 SAP* 是钥匙，但锁孔（client role）、锁芯（logical system 绑定）、锁舌行程（change recording 开关）必须全部对准，否则钥匙再亮也转不动。本章完成三件事：建可用账号、定义逻辑系统、绑定并激活目标 client 790。每步都带验证指令，拒绝“点完保存就以为成功”。

2.1 创建具备 Customizing 权限的专用账号（非 DDIC/SAP*）

SAP 官方明确禁止用 DDIC 或 SAP* 执行 client copy 后的定制开发（T-code SE11/SE38/SPRO），因为这两个账号属于“系统守护者”，其操作不走审计流，且默认无 client-level authorization object S_TCODE 许可。直接用它们改配置，轻则 SCC3 日志里找不到变更记录，重则触发AUTHORITY_CHECK_FAILED导致 client copy 中断。

提示：不要复制 JIAHG 这类示例账号名。实际环境中，账号名需符合公司命名规范（如 ZDEV_XXX），且密码策略必须启用大小写+数字+特殊字符（SAP 默认要求至少 8 位）。

操作路径：

1. 用 DDIC 登录 client 000 → 输入 T-codeSU01

2. 在 User 字段输入新账号名（如ZDEV_COPY）→ 点击“Create”

3. 基础信息页填：

   • First name:Client
   • Last name:Copy Dev
   • Logon Data 标签页：
     • Password:Sap12345!（示例，实际需满足系统密码策略）
     • Initial password valid: 勾选（首次登录强制改密）

4. Roles 标签页 → 点击“Add Role” → 输入标准角色：

   • SAP_BC_BASIS_ADMIN（基础运维）
   • SAP_BC_FND_ADM（FICO/SD/MM 模块定制）
   • SAP_BC_SEC_ADMIN（安全配置）

   参数说明：这三个角色覆盖 client copy 后 95% 的定制场景。SAP_BC_BASIS_ADMIN提供 SCC* 系列事务码权限；SAP_BC_FND_ADM解锁 SPRO、SE11；SAP_BC_SEC_ADMIN允许维护 SU01/SU24。缺一不可，少一个就会在后续 SPRO 配置时报No authorization to display view。

5. 点击“Save”，系统弹出请求号（Request Number）。此时必须立即提交该请求：

   # 在 OS 层执行（以 sapadm 用户登录） cd /usr/sap/<SID>/SYS/exe/run ./R3trans -d -w /tmp/su01_role_import.log

   逻辑说明：R3trans是 SAP 数据库层传输工具。-d表示 debug 模式，-w指定日志路径。此命令强制将 SU01 创建的权限对象写入数据库，避免 GUI 保存后因后台队列延迟导致权限未生效。若跳过此步，ZDEV_COPY 登录 790 后会发现所有菜单都是灰色的。

2.2 定义逻辑系统（Logical System）：跨客户端表的唯一标识符

逻辑系统不是虚拟概念，它是 SAP 内部用于区分数据归属的硬编码标签。SALE → Define Logical System创建的条目，会写入跨客户端表TBDLS（Logical Systems），而TBDLS的每一行都影响T000（Clients）、T001（Company Codes）等核心表的读写行为。这就是为什么系统反复警告 “Caution: The table is cross-client”——改错一行，000 和 790 的财务凭证都可能乱码。

操作路径：

1. DDIC 登录 000 →SALE→ Basis settings → Logical System → “Define Logical System”
2. 点击 “New Entries” → 填入：
   • Logical system:QAS790（必须全大写，且不能含空格或中文）
   • Name:QAS Client 790 for Copy
   • Description:Test environment for MM customization
3. 点击“Save”，系统弹出请求号 →必须选择现有请求号（勿新建）。原因：新建请求会触发RSWBO001（Workbench Organizer）校验，而 client copy 前的 000 client 通常未配置传输路径，导致保存失败。

避坑关键：若点击 Save 后弹出错误No transport request assigned，说明当前 client 000 未配置 CTS（Change and Transport System）。此时不要强行新建请求，而是：

• 进入SE03→ 输入请求号前缀DEVK（示例）→ 点击“Find”
• 若返回空列表，执行 OS 命令强制创建最小化请求：

  # 以 <sid>adm 用户执行 cd /usr/sap/<SID>/SYS/exe/run ./tp addtobuffer DEVK000001 QAS790 -Dpf=/usr/sap/<SID>/SYS/profile/<SID>_DEFAULT.PFL

  此命令绕过 CTS 校验，直接将逻辑系统元数据注入 buffer，确保TBDLS表可写。

2.3 将逻辑系统绑定至 client 790 并激活角色

绑定动作本质是向T000表插入一条 client-specific 记录，指定该 client 的行为模式。Client role和Automatic recording of changes是两个强耦合开关，必须同步开启，否则 client copy 后的定制操作会被系统拦截。

操作路径：

1. SALE→ Basic Settings → Logical Systems → Assign Logical System to Client
2. 点击 “New Entries” → 填入：
   • Client:790
   • Description:MM Test Client
   • Logical system:QAS790（从搜索帮助中选取，勿手输）
   • Std currency:CNY（注意：ECC 6.0 中 RMB 已弃用，必须用 ISO 代码 CNY）
   • Client role:Customizing（此处必须选 Customizing，Production/Test 会导致后续 SPRO 不可用）
   • Automatic recording of changes:X（勾选）
   • Cross-Client Object Changes:Changes to Repository and cross-client Customizing allowed（这是唯一正确选项，其他三项均会阻断 client copy）
   • Protection level:0（零保护，测试环境必需）
   • Ecatt and catt allowed:X（勾选，为后续自动化脚本预留）
3. 点击“Save” → 系统提示 “Data was saved” →立即执行下一步验证：

   -- 在数据库层验证绑定是否生效（Oracle 示例） SELECT * FROM sapr3.t000 WHERE mandt = '790'; -- 正确返回应包含字段：LOGSYS = 'QAS790', MTEXT = 'MM Test Client', CURCY = 'CNY'

参数说明：Client role = Customizing告诉 SAP 内核：“此 client 允许修改 ABAP 字典（SE11）、程序（SE38）、配置视图（SPRO）”；而Cross-Client Object Changes选项则是内核的“闸门控制器”，只有选中Changes to Repository...，SE11 里的表结构修改、SPRO 里的组织架构配置才会被写入数据库。二者缺一，790 就是个只能看不能动的“玻璃房”。

3. 关键破局点：让 SAP* 在 790 client 正常登录的 profile 参数修复

刚装好的 ECC 6.0，默认禁用 SAP* 账号在非 000 client 的登录能力。这不是 bug，是 SAP 的安全基线设计：login/no_automatic_user_sapstar = 1（默认值）强制 SAP* 只能在 000 client 使用。但 client copy 流程要求你必须用 SAP* 登录 790 执行初始配置（如SCC4设置 client 参数），这就形成了死循环——不登录 790 就无法启动 copy，不启动 copy 就无法生成 790 的 profile 参数。本章用最短路径打破僵局：精准修改 profile，且确保修改后服务重启时被真实加载。

3.1 定位并编辑正确的 profile 文件

ECC 6.0 的 profile 加载顺序是：DEFAULT.PFL→<SID>_DEFAULT.PFL→<SID>_<INSTANCE>_<HOST>.PFL。RZ10界面显示的三个文件中，只有<SID>_<INSTANCE>_<HOST>.PFL是最终生效的实例级 profile。若误改DEFAULT.PFL，重启后参数仍不生效。

操作路径：

1. DDIC 登录 000 →RZ10
2. 点击 “Profile” 搜索帮助 → 在弹出窗口中找到形如JHG_DEVBMGSOO_SAPIDES的文件名（JHG=SID,DEVBMGSOO=实例号,SAPIDES=主机名）
3. 选中该文件 → 点击 “Change” → 选择 “Extended maintenance”
4. 点击 “Parameter” → “Create” → 输入：
   • Parameter name:login/no_automatic_user_sapstar
   • Parameter value:0
   • Comment:Enable SAP* login for client 790 copy
5. 点击 “Copy” → 确认保存

逻辑说明：login/no_automatic_user_sapstar = 0的含义是“允许 SAP* 账号在任意 client 登录，无需额外授权”。此参数必须写入实例级 profile，因为DEFAULT.PFL是全局模板，<SID>_DEFAULT.PFL是 SID 级别，只有<SID>_<INSTANCE>_<HOST>.PFL包含实例独有参数（如内存分配、工作进程数），SAP 内核启动时优先读取它。若此处选错文件，RZ10看似保存成功，但SM51查看实例状态时，login/no_automatic_user_sapstar仍显示为 1。

3.2 强制重载 profile 并验证参数生效

profile 修改后，SAP 不会自动热加载，必须重启实例。但直接点RZ10 → Restart Instance可能失败（因工作进程未完全释放），需用 OS 层命令确保干净重启。

操作步骤：

1. 在RZ10界面点击 “Display” → 确认login/no_automatic_user_sapstar值为0
2. 切换到 OS 层（以<sid>adm用户）：

   # 停止实例（等待 30 秒确保进程退出） stopsap ALL sleep 30 # 启动实例 startsap ALL

3. 实例启动后，立即验证参数是否生效：

   # 检查 profile 是否被读取 grep "no_automatic_user_sapstar" /usr/sap/<SID>/SYS/profile/<SID>_<INSTANCE>_<HOST>.PFL # 应返回：login/no_automatic_user_sapstar = 0 # 检查内核运行时值 sapcontrol -nr <instance_number> -function GetSystemInstanceList | grep "login/no_automatic_user_sapstar" # 应返回：login/no_automatic_user_sapstar = 0

避坑关键：若sapcontrol返回值仍为 1，说明 profile 未被加载。此时检查：

• <SID>_<INSTANCE>_<HOST>.PFL文件权限是否为<sid>adm:sapsys（chown <sid>adm:sapsys <file>）
• 文件末尾是否有非法字符（如 Windows 换行符\r\n，用dos2unix转换）
• 实例号是否输错（sapcontrol -nr 00 -function ...中的00必须与SM51显示的实例号一致）

3.3 登录 client 790 并执行初始 client 参数设置

SAP* 登录 790 后，第一件事不是跑 SCCL，而是用SCC4设置 client 特有参数。若跳过此步，client copy 会因client 790 has no default settings报错中断。

操作路径：

1. 浏览器访问http://<host>:8000/sap/bc/gui/sap/its/webgui?~language=EN
2. Client:790, User:SAP*, Password:PASS（安装时设定的密码）
3. 登录成功后，立即执行SCC4
4. 在SCC4界面：
   • Client:790
   • Client name:MM Test Client
   • Address:Henan.Zhengzhou（与 SALE 中设置一致）
   • Currency:CNY
   • Language:EN（建议设为 EN，避免中文字符引发 ABAP dump）
   • Client role:Customizing（必须与 SALE 中一致）
5. 点击 “Save” → 系统生成 client 790 的专属配置

验证技巧：SCC4保存后，在DBACOCKPIT（数据库管理）中执行：

SELECT * FROM sapr3.t000 WHERE mandt = '790'; -- 检查 MTEXT（描述）、WAERS（币种）、SPRAS（语言）字段是否与 SCC4 设置一致

若字段为空或错误，说明SCC4未真正写入，需检查SCC4保存时是否弹出请求号（若无请求号，说明 client 790 的 CTS 未配置，需回退到 2.2 节处理）。

4. 执行 Client Copy：从 000 到 790 的完整后台作业调度与监控

Client Copy 不是单点操作，它是 SAP 内核发起的一系列跨 client、跨表、跨模块的数据迁移任务。SCCL只是调度器，真正的执行引擎是后台工作进程（Background Work Process），而SCC3是它的黑匣子仪表盘。本章聚焦如何让作业真正跑起来、如何读懂日志、以及何时该人工介入。

4.1 SCCL 参数配置：选择正确的复制范围与排除项

SCCL的选项繁多，但 90% 的翻车源于两个错误：

• 选了Client-dependent Customizing却漏掉Cross-client Customizing→ 导致 790 的 SPRO 配置缺失
• 启用了User Master Records却未排除DDIC和SAP*→ 复制后 790 的 DDIC 密码被 000 覆盖，彻底锁死

操作路径：

1. ZDEV_COPY 登录 000 →SCCL
2. Source client:000
3. Target client:790
4. Profile:SAP_ALL_CLIENTS（必须选此预设配置，自定义 profile 易出错）
5. 关键勾选项：
   • ☑ Client-dependent Customizing
   • ☑ Cross-client Customizing
   • ☑ User Master Records
   • ☑ Application Data
   • ☑ Repository Objects
6. 必须排除的用户（点击 “Exclusion” → “User Master Records”）：
   • DDIC
   • SAP*
   • EARLYWATCH（监控账号，避免复制后告警混乱）
7. 点击 “Schedule as Background Job” → “Continue” → “Schedule Job” → 选择 “Start immediately”

参数说明：SAP_ALL_CLIENTS是 SAP 官方认证的全量复制 profile，它内置了 200+ 个表的复制规则（如T000,T001,T005）。若选SAP_MINIMAL，则只复制基础表，790 将缺少 MM 模块所需的T023（Material Types）、T024（Purchase Organizations）等关键表，导致后续MM01创建物料时报Table T023 not found。

4.2 监控后台作业：SCC3 日志解读与关键节点识别

SCC3不是进度条，它是 SAP 内核输出的原始日志流。新手常犯的错误是盯着 “Status: Running” 发呆，却忽略日志里滚动的ERROR或WARNING。真正的进度藏在Step列和Message列的组合中。

操作路径：

1. SCC3→ 输入 Target client:790→ Execute

2. 查看作业列表，找到SCCL开头的作业 → 双击进入详情

3. 重点关注以下三列：

   Step	Message	Status
   0010	Copying table T000	OK
   0020	Copying table T001	OK
   0030	Copying table T023 (Material Types)	ERROR

   现象：Step0030卡住，Status 为ERROR，Message 显示Table T023 not activated in target client
   原因：T023是跨 client 表，但 client 790 的Cross-Client Object Changes未设为Changes to Repository...（见 2.3 节）
   解决：立即回退到SALE → Assign Logical System to Client，重新编辑 790 行，确认该选项已勾选，保存后重启实例，再重跑SCCL。

4. 健康作业的典型日志流：

   • Step 0010-0090: 复制基础主数据表（T000/T001/T005）→ 应全为OK
   • Step 0100-0190: 复制模块主数据（T023/T024/T007）→ 若某表报NOT FOUND IN TARGET，说明 client 790 缺少该表结构，需用SE14激活
   • Step 0200-0290: 复制定制配置（SPRO 视图）→ 此阶段最慢，但Message列应持续刷新，而非长时间静止

避坑关键：若SCC3日志中Step列长时间停留在0000，且Message为Waiting for background work process，说明后台工作进程不足。此时：

• 进入SM50→ 筛选Status = PRIV→ 查看WP（工作进程）数量
• 若< 3，需在RZ10中增加rdisp/wp_no_btc参数值（如设为5），重启实例

4.3 处理复制中断：当 SCC3 显示 ERROR 时的三步急救法

Client Copy 中断不可怕，可怕的是盲目重跑。SAP 的复制机制是原子性的：中断后已写入 790 的数据不会自动回滚，重跑会触发Duplicate key错误。必须先清理，再重试。

急救三步法：

1. 定位中断点：在SCC3中找到最后一条Status = ERROR的 Step，记下Message中的表名（如T023）
2. 清理目标表：用SE16N登录 790 → 输入表名T023→ 执行Delete all entries（仅限测试环境！生产环境必须用SCC7回滚）
3. 重置复制状态：在 000 client 执行SCC7→ 输入 Target client790→ 选择Reset status→ 确认

血泪经验：曾有某公司因未执行SCC7重置，直接重跑SCCL，导致T001（Company Code）出现两条相同BUKRS的记录，后续FB03查凭证时报Multiple company codes found，花 8 小时才用SE16N手动删冗余行。SCC7是 client copy 的后悔药，每次中断后必做。

5. 验证 client copy 成果：从登录、定制到业务流程的五层穿透测试

装完不等于跑通，Client Copy 的终极验证不是看SCC3显示Status: Finished，而是用真实业务动作穿透 5 层：登录层、权限层、配置层、数据层、业务层。每一层都有一条不可绕过的“黄金路径”，任一环节失败，说明 copy 不完整。

5.1 登录层验证：ZDEV_COPY 账号能否在 790 执行 SPRO

这是最基础的通关测试。若 ZDEV_COPY 登录 790 后无法打开 SPRO，说明 client role 或权限未生效。

操作步骤：

1. 用ZDEV_COPY登录 client 790
2. 输入SPRO→ 点击 “Execute”
3. 预期结果：
   • 左侧导航树展开，显示SAP Reference IMG
   • 点击Materials Management → Purchasing → Define Purchasing Organization→ 右侧显示配置界面
   • 尝试新建一条 Purchasing Organization（如1000）→ 点击 “Save” → 系统弹出请求号

失败排查：若点击SPRO后报No authorization to display view，执行：

# 在 790 client 执行 ABAP Debugger (SE37) CALL FUNCTION 'AUTHORITY_CHECK_TCODE' EXPORTING tcode = 'SPRO'. # 若 sy-subrc ≠ 0，说明 S_TCODE 权限缺失，需回退到 2.1 节检查角色分配

5.2 权限层验证：SE11 能否修改表结构，SE38 能否激活程序

Client Copy 后，ABAP 开发环境必须可用。SE11和SE38是权限体系的双刃剑——能改字典和程序，证明S_DEVELOP和S_PROGRAM权限已就位。

操作步骤：

1. SE11→ 输入表名ZMM_TEST（自建测试表）→ 点击 “Create”
2. 添加字段MATNR（类型 CHAR, 长度 18）→ 点击 “Save” → 输入请求号 → 激活
3. SE38→ 创建新程序ZMM_COPY_TEST→ 写入：

   REPORT zmm_copy_test. WRITE: / 'Client 790 copy verified'.

4. 点击 “Activate” → 确认无语法错误

关键指标：SE11激活时，Object Directory Entry窗口必须显示Package: $TMP（临时包），若显示Package: STANDARD，说明 client 790 的Repository Objects复制失败，需重跑SCCL并勾选Repository Objects。

5.3 配置层验证：MM 模块核心组织单元是否完整

物资流程（MM）是 client copy 的高频验证场景。SPRO中的组织单元（Company Code, Plant, Storage Location）必须存在且可配置，否则MM01创建物料会失败。

操作路径：

1. SPRO→Materials Management → Logistics General → Define Company Code
2. 点击 “Execute” → 查看列表是否包含0001（000 client 的公司代码）
3. SPRO→Materials Management → Purchasing → Define Purchasing Organization
4. 查看是否列出1000（示例采购组织）
5. SPRO→Materials Management → Inventory Management → Define Storage Location
6. 确认0001公司代码下存在0001仓库

验证技巧：在SCC3日志中搜索T001（Company Code）、T024（Purchasing Org）、T001L（Storage Location），确认这些表的Status全为OK。若T001L缺失，MM01保存时会报Storage location does not exist。

5.4 数据层验证：000 client 的主数据是否真实迁移

Client Copy 的本质是数据迁移。必须验证关键主数据（物料、供应商、客户）是否从 000 复制到 790。

操作步骤：

1. 在 000 client 执行MM03→ 输入物料号MAT001→ 记录Basic Data标签页的Description（如Test Material A）
2. 切换到 790 client →MM03→ 输入MAT001
3. 预期结果：
   • Description完全一致（Test Material A）
   • Purchasing标签页显示采购组织1000
   • Accounting标签页显示公司代码0001

避坑关键：若MM03在 790 报Material MAT001 does not exist，说明MARA（物料主数据）表未复制。此时检查SCC3日志中Step是否包含Copying table MARA且Status = OK。若无此行，重跑SCCL并确保Application Data已勾选。

5.5 业务层验证：执行一笔完整采购订单（ME21N）

这是 client copy 的终极压力测试。从创建采购申请（ME51N）到生成采购订单（ME21N），全程不报错，证明 MM 模块的配置、主数据、权限、程序全部打通。

操作路径：

1. ME51N→ 创建采购申请：
   • Document type:NB
   • Purchasing group:000
   • Material:MAT001
   • Quantity:10
   • Click “Save” → 记录申请号（如5000000001）
2. ME21N→ 创建采购订单：
   • Document type:NB
   • Vendor:V00001（000 client 的供应商）
   • Click “Reference” → 输入申请号5000000001
   • System 自动带出物料、数量
   • Click “Save” → 获取订单号（如4500000001）
3. ME23N→ 输入订单号4500000001→ 确认状态为Released

失败信号：若ME21N点击 “Reference” 后无数据，说明EBAN（采购申请）表未复制；若保存时报Account determination for item category NBN not defined，说明OMGQ（账户确定）配置缺失，需回退到SPRO补全。

从那以后我每次执行 client copy，都强制走一遍这五层验证：SPRO 能开、SE11 能改、MM03 能查、ME21N 能下、SCC3 日志无 ERROR。哪怕客户催得再急，我也把SCC7重置和RZ10参数检查放在第一步——因为 SAP 的 client copy 不是快与慢的问题，而是“全或无”的问题。一次跳过验证的侥幸，换来的是三天排查T001主键冲突的深夜。希望帮到你。

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