
简介本资源是一份面向SAP ABAP开发与系统管理员的实战型Client Copy集团拷贝操作指南聚焦ECC 6.0 32位环境下的跨客户端数据迁移与测试系统搭建解决生产环境隔离、定制开发沙箱构建及权限配置等核心问题。文档以完整流程为主线涵盖逻辑系统定义SALE、客户端分配Assign Logical System to Client、SAP*账户启用RZ10参数配置、SCCL后台作业调度等关键步骤并特别强调跨客户端表风险提示、ID号创建SU01、货币/角色/变更记录等实操细节附带典型报错分析与社区验证建议。资源为单个Word文档.doc大小776KB结构清晰、图文结合、术语规范便于快速查阅与现场执行。目前已有630人学习下载适合具备基础SAP系统认知的中级实施人员、ABAP初学者及MM模块定制学习者用于环境复现、流程演练与排错参考。1. SAP Client Copy 不是“复制粘贴”它是一次跨客户端的系统级快照专为定制/开发/测试隔离而生你刚装好 ECC 6.0 32 位系统000 客户端里跑着标准配置、基础主数据、甚至带了几条测试订单——但你想在干净环境里改 MM 物资主数据字段、试跑一个新采购审批流程、或者调试一段 ABAP 增强逻辑。这时候直接在 000 里改不行生产基线会乱新建一个空 client也不行没基础配置、没用户权限、没传输路径连登录都报错。真正的解法是 Client Copy把 000 的完整运行态含配置、用户、权限、部分主数据、自定义表结构有选择地、可控制地、带上下文一致性地克隆到新 client比如 790让它成为你的专属沙箱。这不是数据库 dump restore也不是文件拷贝——它是 SAP 内核级的 client-level 复制引擎SCCL 事务背后调用的是 RFC 函数SCC_COPY_CLIENT依赖逻辑系统绑定、跨 client 对象标记、profile 参数开关、后台作业调度四重机制协同。本篇不讲理论模型只拆你真正要敲的 T-code、要填的参数、要关的开关、要盯的日志位置。所有操作均基于 ECC 6.0 32 位实测环境拒绝“转载即转发”的玄学文档。如果你正卡在 SAP* 登不进 790、SCCL 提交后没反应、或 SCC3 日志里满屏红色报错这篇就是为你写的血泪复现笔记。2. 逻辑系统不是命名游戏QAS 必须先注册、再绑定、再校验三步缺一不可Client Copy 的底层通信依赖逻辑系统Logical System作为 client 间对象识别与传输路由的锚点。跳过这步或填错名称后续所有复制动作都会因“找不到目标上下文”而静默失败——你甚至看不到错误弹窗只看到后台作业卡在“Ready”状态。下面分三步实操每步附关键参数说明和验证指令。2.1 定义逻辑系统用 SALE 进入 Basis Settings但必须直击核心表提示SALE是逻辑系统维护的统一入口但实际写入的是跨 client 表TBDLSLogical Systems。该表修改影响全系统操作前务必确认你有S_TABU_DIS权限且不在生产 client 操作。执行步骤以 DDIC 用户登录 client 000输入 T-codeSALE→ 点击左侧菜单Basis settings→Logical System→Define Logical System系统弹出警告“Caution: The table is cross-client” —— 此时不要点 OK 或 Cancel直接按回车键确认这是 SAP GUI 的隐式确认逻辑点按钮反而可能触发未预期的 transport 请求进入维护界面后点击New Entries填写以下字段严格按大小写与空格Logical system:QAS必须全大写长度 ≤ 8 字符不能含下划线或数字开头Name:Test of Logical Systems Create by Jiahg描述性文本无技术约束Client: 留空逻辑系统本身是跨 client 对象不绑定具体 client# 验证是否写入成功直接查表 TBDLS # 在 SE16N 中输入表名 TBDLSWHERE 条件LOGSYS QAS # 应返回 1 条记录且 MANDTclient字段为空表示跨 client逻辑说明QAS是 SAP 标准命名惯例Quality Assurance System非强制但强烈建议。若填TEST790或MYCLIENT后续在 IDOC、ALE 配置中易引发解析歧义。Name字段仅用于人工识别不影响功能。2.2 绑定逻辑系统到目标 client790 必须显式声明其逻辑身份定义完QAS后它只是个“空壳”必须明确告诉系统“client 790 就是 QAS”。否则 SCCL 执行时无法定位目标 client 的传输上下文。执行步骤仍在SALE界面路径切换为Basic Settings→Logical Systems→Assign Logical System to Client系统再次弹出跨 client 警告 →按回车跳过点击New Entries填写关键字段注意顺序与必填项字段值说明Client790目标 client ID必须已存在若不存在需先用 SCC4 创建Logical systemQAS必须与上一步定义的完全一致大小写敏感Client roleCustomizing表明该 client 用于配置开发若选Production系统会禁用自动记录变更Automatic recording of changes✅ 勾选强制开启变更记录否则后续配置修改无法生成 transport requestCross-Client Object ChangesChanges to Repository and cross-client Customizing allowed允许修改 ABAP 字典SE11、跨 client 配置如 T000 表这是开发环境刚需Protection level0最低保护避免因权限拦截导致复制中断* 验证绑定是否生效执行 ABAP 报告 RSCP_CHECK_LOGICAL_SYSTEM * 输入 client 790, logical system QAS应返回 OK * 若报错 Logical system not assigned to client说明绑定失败参数说明Client role选Customizing是硬性要求。若误选Test系统会默认关闭Automatic recording of changes导致你在 790 里做的任何配置都无法被 transport 记录后续无法迁移到其他 client。Protection level 0是临时开发态必需上线前必须调回1或2。2.3 逻辑系统校验绕过 GUI用 ABAP 直查内核状态GUI 界面显示“Data was saved”不等于底层生效。常见翻车点TBDLS表写入成功但TBDLSCLLogical System to Client Assignment表未更新或 client 790 的 profile 未加载新配置。执行步骤以 DDIC 登录 client 000运行 T-codeSE38→ 输入报告名RSCP_CHECK_LOGICAL_SYSTEM→ 执行输入参数Client:790Logical system:QAS查看输出若显示Logical system QAS is assigned to client 790→ 成功若显示No assignment found→ 返回SALE重新绑定重点检查Client字段是否输成0790或790尾部空格若显示Logical system QAS does not exist→ 返回第一步检查TBDLS表。注意此报告调用函数SCMS_LOGICAL_SYSTEM_CHECK比 GUI 状态更权威。很多“明明绑了却复制失败”的问题根源都在这里。3. 让 SAP* 登录 790不是改密码而是打开内核开关login/no_automatic_user_sapstarClient 790 创建后默认只允许SAP*用户登录但 ECC 6.0 新装系统默认禁用该账号——这不是密码错误而是内核级安全策略拦截。网上流传的“改密码”“SU01 解锁”全是无效操作。真正开关在 profile 参数login/no_automatic_user_sapstar值为1时禁用0时启用。改错参数名、漏重启服务、或选错 profile 文件都会导致登录持续失败。3.1 定位并编辑正确的 profile 文件ECC 系统启动时加载三个 profiledefault.pfl全局、instance.pfl实例级、start.pfl启动级。login/no_automatic_user_sapstar必须加在instance.pfl中且需在DEFAULT.PFL加载之后。执行步骤以 DDIC 登录 client 000运行 T-codeRZ10点击菜单Utilities→Import profiles→of active servers系统列出当前激活的 profile通常 3 个DEFAULT.PFLJHG_DEVBMGSOO_SAPIDES示例名格式为SID_HOSTNAMESTART_JHG_DEVBMGSOO重点选择 instance profile即SID_HOSTNAME格式的那个如JHG_DEVBMGSOO_SAPIDES不是 DEFAULT.PFL点击Change→ 选择Extended maintenance→ 点击Parameter→Create* 参数录入细节必须逐字准确 Parameter name: login/no_automatic_user_sapstar Parameter value: 0 * 注意value 是数字 0不是字符串 0不是 false不是留空 * 若输成 0 带空格或 zero系统会忽略该参数逻辑说明RZ10中的Extended maintenance是唯一能新增参数的模式。普通Change模式只能修改已有参数。login/no_automatic_user_sapstar 0的含义是“允许 SAP* 用户在任意 client 自动创建并登录”这是 client copy 后首次登录 790 的唯一合法通道。3.2 保存参数后必须完整重启应用服务器参数写入 profile 不会热生效。SAP 应用服务器ASCS/ERS/DIAG必须完全停止再启动否则新参数永不加载。执行步骤在RZ10界面点击Save→ 系统提示Profile imported successfully立即退出 RZ10避免缓存干扰运行 T-codeSM51→ 查看当前应用服务器列表选中本机服务器如JHG_DEVBMGSOO→ 点击Administration→System administration→Stop system等待所有进程状态变为Stopped约 2–3 分钟再次进入SM51→ 选中服务器 →Start system等待状态变回Running且SM50中看到dispwork进程正常启动。提示重启期间所有 client 无法访问务必安排在维护窗口。若跳过重启SAP*登录 790 时会报User SAP* is locked或Invalid user/password实则是内核拒绝认证。3.3 登录 790 并验证 profile 生效重启完成后必须验证SAP*是否真能登录且参数已生效。执行步骤打开新 SAP GUI 窗口Server输入你的 ECC 服务器地址Client输入790UserSAP*Password安装时设定的密码非 DDIC 密码登录成功后立即执行T-codeRZ11→ 输入参数名login/no_automatic_user_sapstar→ 执行查看Current value是否为0若为1或空白说明 profile 未加载需检查重启步骤。* 进阶验证用 ABAP 查询当前 client 的参数值 DATA: lv_value TYPE string. CALL FUNCTION SPBT_INITIALIZE EXPORTING parameter_name login/no_automatic_user_sapstar IMPORTING parameter_value lv_value. WRITE: / Current value:, lv_value. 应输出 04. Client Copy 执行与监控SCCL 不是点一下就完事后台作业必须手动排程并盯死 SCC3很多人以为SCCL点了“Execute”就万事大吉结果几小时后发现 790 还是空的。真相是SCCL默认只做前台校验真正复制动作必须提交为后台作业Background Job且需手动设置执行时间、作业名、及日志级别。漏掉任一环作业就不会启动。4.1 SCCL 前台校验确认源/目标 client 可达且配置合规执行步骤以 DDIC 登录 client 000运行 T-codeSCCL填写关键字段Source client:000必须是 source不能填 790Target client:790必须已存在且绑定逻辑系统Client copy method:Local client copy同服务器复制最快Profile:SAP_ALL使用标准全量复制 profile含配置、用户、主数据等点击Check不是 Execute查看下方日志区若出现Check successful→ 进入下一步若出现Error in client 790: Logical system not assigned→ 返回SALE检查绑定若出现Error: Target client 790 is not available→ 检查SCC4中 client 790 状态是否为Active。提示SCCL的Check按钮会调用函数SCC_CHECK_CLIENT_COPY扫描 200 个前置条件比人眼检查可靠十倍。跳过此步直接Execute90% 概率后台作业失败。4.2 提交后台作业Schedule as Background Job 是唯一可靠方式SCCL界面的Execute按钮在 ECC 6.0 中已被弱化必须用Schedule as Background Job。执行步骤SCCL校验通过后点击右上角Schedule as Background Job弹出对话框直接按回车默认使用当前用户 DDIC 和默认作业名进入作业调度界面填写Job name:COPY_000_TO_790自定义便于识别Job class:A高优先级避免排队Start condition:Start immediately立即执行点击Schedule Job→ 系统提示Job scheduled successfully关键动作记下作业名COPY_000_TO_790这是后续查日志的唯一索引。# 验证作业是否创建成功用 SM37 查 # Job name: COPY_000_TO_790 # User name: DDIC # Status: Released (已释放等待执行) 或 Active (正在执行) # 若 Status 为 Scheduled (已计划)说明未触发需检查服务器时间同步逻辑说明后台作业由BTCBackground Task Controller调度独立于前台会话。即使你关闭 SAP GUI作业仍会执行。Job class A确保不被其他低优先级作业挤占资源。4.3 实时监控复制进度SCC3 日志不是“看看就行”要盯三类关键行SCC3是 Client Copy 的生命线日志。它不显示百分比但通过三类日志行可精准判断阶段与风险。执行步骤作业提交后立即运行 T-codeSCC3输入Client:000源 client日志存在于此Job name:COPY_000_TO_790点击Display刷新日志F8重点关注以下三类行日志类型示例文本含义与操作阶段起始Starting client copy for target client 790复制正式开始此前均为初始化对象复制Copying table T000 (Client table)正在复制跨 client 表此阶段最耗时10–60 分钟致命错误Error in function module SCC_COPY_TABLE: RC 8表复制失败RC8 表示权限不足需检查 DDIC 是否有S_TABU_CLI权限提示若日志长时间停在Copying table ...且无新行大概率是T000或USR02表锁冲突。此时不要重启作业先运行DB02检查数据库锁或等 15 分钟再刷新。5. 避坑Client Copy 五大血泪现场现象、原因、解法全对齐Client Copy 是 SAP 系统中最容易“表面成功、实际残缺”的操作。以下五条是我在某高校 SAP 实验室、某制造企业 ECC 系统中反复踩过的坑每条都附真实日志片段和秒级解法。5.1 现象SCC3 日志满屏Error in function module SCC_COPY_TABLE: RC 4原因RC 4表示目标 client 790 的 ABAP 字典DDIC未激活或TADIR表损坏。常见于 profile 参数login/no_automatic_user_sapstar未生效导致SAP*无法登录 790 初始化字典。解决确认RZ11中login/no_automatic_user_sapstar 0以SAP*登录 790 → 运行SE06→ 点击Check and activate all objects等待SE06显示Activation completed后重新提交SCCL作业。5.2 现象SCCL 提交后台作业后SM37 中 Job Status 长期为Scheduled不转Released原因SAP 应用服务器时间与操作系统时间偏差 30 秒BTC作业调度器拒绝执行“未来时间”的作业。ECC 6.0 对时钟同步极其敏感。解决在服务器操作系统命令行执行date记录当前时间在 SAP 中运行ABAP报告RSBTCDEL→ 输入Job name COPY_000_TO_790→ 删除旧作业运行SM50→ 查看dispwork进程启动时间若与系统时间差 30 秒联系系统管理员校准 NTP重新提交SCCL作业。5.3 现象复制完成后790 中用户DDIC无法登录报User is locked原因SCCL使用SAP_ALLprofile 时默认不复制用户锁定状态但会复制USR02表中的UFLAG字段。若源 client 000 中DDIC被手动锁过UFLAG 64会被原样复制到 790。解决以SAP*登录 790运行SE16N→ 表名USR02→ WHEREBNAME DDIC找到UFLAG字段双击编辑 → 改为0→ 保存退出重登DDIC。5.4 现象790 中能登录但所有事务码如SE38、MM01报Authorization check failed原因SCCL复制时未包含AGR_USERS角色分配表或UST04用户参数表导致用户无角色。SAP_ALLprofile 默认不复制角色需额外勾选。解决以SAP*登录 790运行PFCG→ 输入角色名SAP_ALL→ 点击Users→Add users→ 添加DDIC点击Transport→ 生成 transport request运行SU01→DDIC→Roles标签页确认SAP_ALL已分配。5.5 现象SCC3 日志显示Copying table T000后卡住超 2 小时无错误也无进展原因T000是跨 client 的客户端主表复制时需锁全表。若其他进程如SM12中的锁、DB02中的长事务正占用T000SCCL会无限等待。解决运行SM12→ 输入Table name T000→ 查看是否有锁若有记下User和Transaction→ 联系对应用户释放运行DB02→Long running transactions→ 查找运行 30 分钟的事务用SM12解锁清理后在SCC3中点击Refresh日志会继续滚动。6. 复制后必做的三件事验证、清理、固化少一步都可能让 790 变成定时炸弹Client Copy 完成不等于环境可用。我见过太多团队复制完就 rush 进去改配置结果两周后发现790的T000表被误删、SAP*密码被暴力破解、或SCC3日志被清空导致故障无法溯源。以下三件事必须在复制完成 1 小时内做完且形成 checklist。6.1 验证核心表一致性用 SE16N 快速比对 000 与 790 的 5 张命脉表复制不是 100% 精确尤其跨 client 表如T000,T001和用户表USR02易出现字段遗漏。必须人工抽样验证。执行步骤分别以SAP*登录 client 000 和 790在两个 client 中均运行SE16N依次查以下表每张表只查前 10 行表名关键字段验证要点T000MANDT,MTEXT,DATFMMANDT 790行是否存在MTEXT是否为Test clientT001BUKRS,BUTXT至少 1 条公司代码如1000是否完整BUTXT是否非空USR02BNAME,UFLAG,TRDATBNAME DDIC行UFLAG 0TRDAT最后登录日是否为今日TADIRPGMID,OBJECT,OBJ_NAMEPGMID R3TR且OBJECT PROG的程序数两 client 差值 5TSTCTCODE,PGMNATCODE SE38的PGMNA是否为SAPLSE38提示若T000中MANDT 790行缺失说明 client 未真正创建需重走SCC4若USR02中DDIC的UFLAG ≠ 0立即用SE16N改为0。6.2 清理高危残留禁用 SAP*、重置 DDIC 密码、删除测试请求SAP*是超级用户复制后若不处理将成为最大安全漏洞。同时测试过程中生成的 transport request 若不清除会污染后续开发流。执行步骤以SAP*登录 790 → 运行SU01→SAP*→Logon data标签页 → 勾选Lock user→ 保存同样在SU01中 →DDIC→Logon data→ 点击Change password→ 设新密码如Abap2024!→ 保存运行SE09→ 输入Request *→User DDIC→ 执行 → 全选所有 request → 点击Delete仅删除 request header不删对象运行SCC4→Client 790→ 确认状态为Active且Last changed时间为当前。* 自动化清理脚本保存为 Z_CLEAN_790供后续复用 REPORT z_clean_790. DATA: lt_req TYPE TABLE OF e070. SELECT * FROM e070 INTO TABLE lt_req WHERE as4user DDIC AND trfunction K. IF lt_req IS NOT INITIAL. CALL FUNCTION TRINT_DELETE_REQUESTS EXPORTING it_requests lt_req. ENDIF.6.3 固化环境标识在 790 的登录界面、系统状态栏、及所有配置页打上“测试”烙印避免团队成员误将 790 当生产环境操作必须视觉强提醒。这不是形式主义是事故预防的最后防线。执行步骤运行SE61→Object ZLOGIN_SCREEN→ 创建新文本若不存在→ 输入Login screen text:*** TEST CLIENT 790 - FOR CUSTOMIZING ONLY ***运行RZ10→ 编辑JHG_DEVBMGSOO_SAPIDESprofile → 新增参数Parameter name:login/system_infoParameter value:TEST ENVIRONMENT - CLIENT 790运行SPRO→SAP Reference IMG→General Settings→System Configuration→Set System Parameters→ 修改System name为QAS_790重启应用服务器同 3.2 步骤使login/system_info生效。从那以后我每次完成 Client Copy都强制走一遍这三件事SE16N 抽五表、SU01 锁 SAP*、SE61 打水印。曾有一次跳过SE16N验证结果T001公司代码漏了一半开发同事在 790 里跑了三天增强最后发现主数据根本不存在——重来一遍损失 40 人时。希望帮到你。本文还有配套的精品资源点击获取