★ FEATURED ARTICLE 简介《SAP集团拷贝 client copy》是一份面向SAP ECC 6.0运维、BASIS初学者及需搭建测试环境的实施人员的中文操作文档聚焦集团拷贝Client Copy从000生产集团复制到新建测试集团的完整配置思路与注意事项。压缩包内共1个doc文件约776KB内容以图文步骤、参数说明和问题处理记录为主便于按章节查阅逻辑系统定义、客户端分配、SAP*登录及后台作业等关键环节。已有631人学习说明其在SAP基础运维与测试环境搭建场景中具有一定参考价值。文档结合ECC 6.0 32位系统实例强调跨客户端表修改、权限与数据一致性等易错点并提示备份与验证思路适合需要理解集团拷贝流程、排查配置问题或建立独立定制开发环境的读者作为实操参考。1. 从 000 到 790一次 client copy 集团拷贝到底在搬什么接手一台刚装完的 ECC 6.0 32 位系统DDIC 能进 000业务顾问已经在催一个能随便折腾的测试集团。这时候绕不开的就是 client copy 集团拷贝——把 000 里的定制、用户主数据按选定范围搬到新建的 790 里出问题只影响 790生产那套完全不受影响。它属于 Basis 的日常活但每一步都踩在跨集团表和 profile 参数上顺序错一步就得推倒重来。适合正在做 ECC 6.0 单机环境搭建的人也适合被网上同源教程坑过一次、想找个能照着走完的流程的人。下面这份流程从逻辑系统定义一路写到 SCC3 日志核对中间把 RZ10 参数、SCCL 选型、后台作业排程这几处容易翻车的地方拆开讲。2. 拷贝前的基础逻辑系统、账号与 Client 角色三件事很多人把 SCCL 当成整个流程的起点直接冲进去选个 SAP_ALL 就排作业结果作业跑完发现 790 里 RFC 目标全是空的、ALE 模型指向 000。问题不在 SCCL在前面三个前置动作没做或者做错了。这一章把逻辑系统、管理员账号、Client 属性这三块按依赖顺序捋一遍每一步都写清楚为什么必须在这个位置做。2.1 逻辑系统为什么必须在 Client 之前落地逻辑系统是 SAP 里一个纯配置对象本身不承载业务数据但它是 ALE、RFC 目标、SLD 注册、Web Service 这些集成场景的锚点。它存在表 TBDLS 里而 TBDLS 是跨集团表——整个系统共用一份不区分 client。这就是为什么在 SALE 里点「Define Logical System」时会弹出Caution: The table is cross-client。这条提示不是报错是提醒你接下来这条记录一旦保存所有 client 都能看到而且只需要定义一次。顺序上必须先定义逻辑系统再把它分配给 client。原因是分配那一步的 Logical system 字段走的是 F4 搜索帮助帮助里列的就是 TBDLS 里已有的条目。如果先建 client 再补逻辑系统你得回到 client 明细里二次修改而这时候如果 SCCL 已经跑过改配置就得搭传输请求走一遍白白多出一轮返工。操作路径固定为事务码 SALE → Basis settings → Logical System → Define Logical System → New Entries。填两个字段Logical system 用全大写、长度不超过 10 位的命名常见做法是按系统标识CLNTclient号或者ZLS_用途来编比如ZLS_TEST790Name 写一段人能看懂的描述。保存时会要求挂一个请求号Request新系统里没有现成请求就点新建生成一个再保存。涉及对象存储位置是否跨集团改动时机逻辑系统定义表 TBDLS是Client 分配之前全系统一次逻辑系统到 Client 的分配表 T000否每个 client 单独维护Client 角色与保护级别表 T000否分配逻辑系统时一并设置这里有个容易被忽略的点定义逻辑系统会产生一个 CTS 请求这个请求后续如果被释放逻辑系统定义就会跟着传输到其他系统。单机环境无所谓但只要系统接进了传输链路这个请求就别随手释放否则下游系统的 TBDLS 会被覆盖。2.2 SU01 复制管理员账号别直接拿 DDIC 去做定制DDIC 和 SAP* 是系统保留账号能登录、能做一部分管理操作但它们不是给日常定制开发用的。DDIC 在很多检查点上是受限的SAP* 更极端它是个应急账号不适合挂业务角色。正确做法是在源 client也就是 000里复制出一个自己的管理员账号让它随 client copy 一起带到 790。操作是 SU01输入要复制的源用户比如 DDIC走菜单里的 Copy目标用户填一个新 ID比如 ZADMIN然后逐项补齐。真正决定权限的是 Logon Data 页签里的 User type 和 Roles 页签里的角色分配。User type 选Dialog角色至少挂SAP_ALL和SAP_NEW两个。SAP_ALL给的是全量业务授权SAP_NEW管的是新增对象的授权检查两个都挂上后面建表、建程序、跑 SECATT 才不会突然弹权限不足。复制出来的用户还要检查三处地址信息里的 Last name 必须非空SAP 在某些版本上会因为姓名为空导致登录后被强制跳转到维护界面。Logon Data 里的 Initial password 要设一个并且勾上下次登录强制改密的选项避免空密码账号被扫描。Profiles 页签里确认SAP_ALL已经出现在列表里如果只挂在 Roles 页签而没同步到 Profiles用 SU01 的 User comparison 功能同步一次。这里有个取舍账号是在 client copy 之前建还是之后建。从方便的角度先在 000 里建好SCCL 选带用户主数据的 profileSAP_ALL 或 SAP_USER790 拷完直接就能用这个账号登录省掉一轮手工创建。代价是用户主数据也会被一起搬过去如果 000 里有大量业务用户790 里会多出一堆用不上的账号拷完得用 SU10 批量清理。2.3 Client 角色与跨集团对象开关选错就得重来Client 属性在 SALE → Basic Settings → Logical Systems → Assign Logical System to Client 里维护。进去之后能看到系统里所有 client 的列表前三个000、001、066 之类是系统自带的不要动。点 New Entries 新建一条Client 填 790描述随便写但要能认出来City 填站点代号Std currency 按实际选人民币环境选 RMBLogical system 从帮助里选上一步定义的那个。真正影响后续能不能干活的是下面四组开关字段可选值对测试 client 的建议Client roleCustomizing / Test / Production / Demo / TrainingCustomizing 或 TestAutomatic recording of changes勾选 / 不勾选勾选Cross-client object changes不允许 / 允许对资源库和跨集团定制做更改 / 不允许更改允许对资源库和跨集团定制做更改Protection level0 / 1 / 2 / 30eCATT and CATT allowed勾选 / 不勾选勾选Client role 决定了系统的缺省保护级别选 Production 会带出级别 1很多对象直接锁死改不了选 Customizing 或 Test 带出级别 0也就是无保护。保护级别 0 到 3 的含义大致是0 无限制1 不允许改资源库对象和跨集团对象2 不允许改跨集团对象3 任何更改都禁止。不同版本上这个对应关系略有出入拿不准的时候在该字段上按 F1 看系统自带帮助比翻网上教程靠谱。Cross-client object changes这一项如果设成「不允许」后面在 790 里用 SE11 建表、用 SE38 建程序都会被拦下来报的错还很隐晦往往表现为保存按钮灰掉或者提示对象被锁定。做测试和开发用途的 client 一定要放到「允许对资源库和跨集团定制做更改」。eCATT 那个开关是给后续做自动化测试留的口子现在勾上不吃亏事后要改又得走一轮配置。保存时会再弹一次跨集团表警告直接回车。系统提示Data was saved才算落地。3. SAP* 登不进 790RZ10 参数与 profile 导入的完整路径Client 建好、逻辑系统分配完下一步按理说是登录 790 验证。但新装的 ECC 6.0 上用 SAP* / PASS 登 790 大概率是被拒的。这不是密码错是系统参数把 SAP* 的自动创建关掉了。这一章把这个参数的来龙去脉和修改的完整路径讲清楚包括那个经常被跳过的 profile 导入动作。3.1 为什么新装的 ECC 上 SAP* 默认进不去SAP 有一个 profile 参数叫login/no_automatic_user_sapstar。它的值决定了两件事当系统里不存在 SAP* 这个用户时要不要自动创建一个密码为 PASS 的 SAP*以及已存在的 SAP* 能不能用 PASS 登录。值的含义可以这样理解设为 0允许自动创建 SAP*密码固定为 PASS且不受登录失败锁定影响。这是搭建和应急场景需要的状态。设为 1 或不设SAP* 只有在系统里已经存在、且未被锁定的情况下才能登录。新装的系统里 000 可能因为安装程序做过初始化而存在 SAP*但新建的 790 里没有这条用户记录登录自然失败。ECC 6.0 的缺省配置偏向安全很多安装介质打完之后这个参数就是 1。所以现象很典型000 能进790 死活进不去。解决路径不是去数据库里改表而是改 profile 参数再重启——直接改表在 SAP 里属于典型的血泪经验改完重启又被 profile 覆盖回去白忙一场。3.2 从 RZ10 导入活动服务器 profileRZ10 第一次打开时Profile 的搜索帮助里可能是空的。这不是权限问题是系统还没把操作系统层面的 profile 文件读进缓冲区。原文里提到的那步 Import profiles 就是干这个的很多人跳过它然后在选参数文件那一步卡住。操作路径事务码 RZ10 → 菜单 Utilities → Import profiles → of active servers。执行后会看到一个日志界面正常情况下应该出现三条Profile import executed correctly之类的记录分别对应 DEFAULT、实例 profile、启动 profile。如果某一条报错先解决那一条别急着往下走。导入完成后退回 RZ10 初始界面再点 Profile 的搜索帮助这时候能列出三个已装载的 profile。命名规则一般是SID_实例名_主机名这种形式比如SID_DVEBMGS00_host其中SID是系统标识DVEBMGS00是实例编号和类型host是操作系统主机名。三个里面选那个实例级的带 DVEBMGS 或 ASCS 字样的因为登录参数属于实例级配置。需要注意RZ10 里改的是操作系统上的 profile 文件不是数据库里的配置表。这意味着两件事改动不会立即生效必须重启实例以及如果同一台机器上有多个实例共用 profile 目录改之前确认自己改的是哪个文件。3.3 扩展维护加参数并让它在重启后生效选中 profile 之后点 Edit Profile在弹出的对话框里把维护模式切到Extended maintenance再点 Change。基础维护模式只能改已有参数的值加新参数必须用扩展维护。进入参数列表后点 Parameter 按钮新建一行两个字段Parameter namelogin/no_automatic_user_sapstarParameter val0填完点 Copy回到列表后确认这一行已经出现在参数清单里然后保存。保存后建议退回 RZ10 初始界面用 Display 模式再打开一次这个 profile确认参数确实写进去了而不是只停在编辑缓冲区。接下来是最关键也最容易被省掉的一步停实例、再启动。停的时候用操作系统层面的工具stopsap 或者 sapcontrol -nr 实例号 -function Stop确认进程全部退出、共享内存段释放干净之后再启动。只停不停干净就重启新 profile 可能读不进去表现为参数列表里明明有这一行但 SAP* 依然登不上。重启完成后用 SAP* / PASS 登录 790。如果还是失败按这个顺序排查先用 RZ11 查login/no_automatic_user_sapstar的运行值是不是 0RZ11 看的是内存里的生效值RZ10 看的是文件里的配置值两者不一致就说明没重启或者重启没读完 profile再确认登录的确实是 790 而不是 000最后确认客户端号没输错SAP GUI 的 Client 字段是三位的790 就是 790。4. SCCL 发起拷贝配置文件、并行度与后台作业的取舍前置动作做完才轮到 SCCL。这一步的输入参数不多但每一个都直接决定拷贝结果的范围和耗时。选大了跑十几个小时选小了拷完发现缺东西32 位系统上并行度开高了还可能直接把作业跑挂。这一章把参数逐个拆开再讲后台作业和 SCC3 日志怎么读。4.1 SCCL 选型SAP_ALL、SAP_USER 与 SAP_CUST 的差别SCCL 界面上最核心的字段是 Selected profile它决定了搬哪些东西过去。常用的几个Profile包含内容适用场景SAP_ALL定制 应用数据 用户主数据与授权要一个和源端几乎一致的测试环境SAP_CUST仅定制跨集团和集团相关的定制只要配置不要业务数据SAP_APP仅应用数据已有定制只补数据SAP_USER用户主数据与授权补账号不动业务数据SAP_UCUS用户主数据 定制介于两者之间第一次从 000 拷到 790通常选 SAP_ALL图的是拷完就能用不用再补配置。代价是耗时最长而且会把 000 里的所有业务数据一起搬过来——如果 000 本身是干净的新装系统这个代价可以接受如果 000 里已经灌了大量测试数据SAP_ALL 会让 790 的库体积迅速膨胀32 位系统上要提前算好表空间。其余几个字段Source Client源集团填 000。Target Client目标集团填 790必须是已经建好且与源不同的 client。Test run第一次强烈建议勾上。勾上之后 SCCL 只做检查不做实际复制能提前暴露目标 client 有用户在线、表空间不足、权限缺失这些问题。检查通过再去掉勾选正式跑。Parallel processing最大并行进程数。32 位系统的可用内存有限这个值开大之后每个进程都要占一块很容易把系统压到 dump。保守做法是先按 CPU 核数的一半设跑起来观察 SM50 里的进程状态和 ST06 的内存曲线稳定了再调。Maximum size of tables / Size of the processed tables控制大表是否分段处理。表很大的时候不设上限单个表的复制可能长时间占着一个进程看起来像卡死。还有一个隐含前提目标 client 里不能有活动用户。SCCL 在执行期间会锁定目标 client如果有用户挂在上面作业一启动就会失败。跑之前用 SM04 看一眼 790 有没有会话有就踢掉。4.2 后台作业排程与 SCC3 日志读法参数填完点Schedule as Background Job。系统会弹一串对话框确认一路回车最后到排程界面选执行时间。测试环境选「立即」就行生产系统上通常排到维护窗口。确认后排程界面会给出一个作业名记下来。作业跑起来之后用 SM37 查状态。正常的状态流转是Released→Ready→Active→Finished。如果停在Released很久不动检查后台工作进程是不是被别的作业占满了如果变成Cancelled去作业假脱机里看报错文本常见的是表空间不足或者目标 client 被占用。查看进度的正式入口是 SCC3。这个事务码会列出所有 client copy 的日志选中当前这次能看到每个表的复制情况。表里的几列值得盯表名和表分类能看出哪些表被跳过了。已复制的记录数和源端对不上就说明有问题。状态列正常是已复制异常会写明原因比如因为表分类被排除、因为表在排除清单里、因为空间不足中断。日志文件在操作系统上也有落盘路径一般在/usr/sap/SID/SYS/global/下面SCC3 读的就是这些文件。作业跑到一半系统崩了SCC3 里可能看不到完整记录直接去这个目录下翻文件更靠谱。4.3 拷贝完成后的三件收尾SCC3 里所有表都显示完成不等于活干完了。下面三件事不做790 用起来会各种别扭。第一重新确认逻辑系统。Client copy 会把源 client 的 T000 记录一起带过来790 的逻辑系统字段可能还指着 000 的那个值。回 SALE 里把 790 的 Logical system 改成自己定义的那个否则后续做 ALE 或者 RFC 的时候目标地址全指错。第二处理 SAP*。拷贝完成后 790 里已经有了完整的用户主数据SAP* 的自动登录就没必要一直开着。把login/no_automatic_user_sapstar改回 1再重启一次避免留一个密码固定的后门账号。改之前确认自己的管理员账号能正常登录别把自己锁在外面。第三重建集成相关的对象。RFC 目标、SLD 注册、ALE 模型、后台作业的变式这些要么是跨集团对象不走 client copy要么是带着源系统的地址信息过来的需要逐个检查重配。判断标准很简单凡是配置里出现主机名、系统编号、client 号的地方都过一遍。5. 避坑清单五条从 SALE 到 SCC3 的翻车记录这一章的五条都是实际跑流程时撞出来的每条按现象、原因、解决三段写。新手看完能提前规避熟手可以对照自己环境里的差异。5.1 现象SCCL 一启动就失败日志只有一行现象是作业刚进入 Active 就转 CancelledSCC3 里几乎没有内容SM37 的假脱机里只有一句类似「目标 client 被锁定」或者「用户正在目标 client 中活动」的提示。原因基本只有一个790 上有活动会话。SCCL 在执行期间要求目标 client 处于独占状态只要有一个用户挂着整个拷贝就起不来。刚建完 client 的时候自己用 SAP* 登进去看过一眼没退出来是最常见的情况。解决分两步。跑之前用 SM04 选到 790把所有会话清掉包括自己的如果清完还是报同样的错用 SM50 检查有没有后台进程挂在 790 上有些定时作业会在 client 上留下句柄。另外一个容易漏的点是 SAP GUI 的登录窗口——有些人习惯开着一个连 790 的登录界面不点确定这也会被算作活动会话。5.2 现象SCC3 里大片表显示未复制拷贝跑完了状态看着是成功但 SCC3 明细里一大堆表标着未复制或者已排除790 里对应的功能点进去是空的。原因有两类。一类是 profile 选小了比如选了 SAP_CUST 却期望业务数据也在或者选了 SAP_USER 只搬了账号。另一类是表本身被排除在复制范围外——SAP 有一批表在交付时就标了不参与 client copy包括一些跨集团表、系统表和缓冲表这些本来就不该被拷属于正常行为。解决的关键是分清「该拷没拷」和「本来就不拷」。SCC3 的状态列会写明原因看到「因为表分类被排除」这种就是正常的看到「因为空间不足中断」才是真问题。对于前者确认业务上确实不需要别硬去改表的复制属性改了容易在后续升级时出问题。对于后者扩表空间后重跑SCCL 支持在失败点续跑不用从头来。5.3 现象拷完 790 里自建程序全不见了790 建好之后准备做开发结果 SE38 里搜不到 000 里已有的自建程序SE11 里自建表也是空的但标准功能都正常。原因是资源库对象程序、表定义、数据元素、域这些属于跨集团对象client copy 不搬它们。SCCL 搬的是集团相关的定制和业务数据跨集团的部分要走传输请求CTS也就是在源系统里把这些对象收集进请求释放再在目标系统里导入。这是 SAP 的设计不是配置漏了。解决路径是回到 000用 SE01 或 SE10 建一个请求把需要的开发对象挂进去释放之后在 790 对应的系统里导入。单机环境下如果源和目标是同一个系统那这些对象其实已经在系统里共享了790 里直接就能看到不存在「丢」的问题——出现这个现象说明你面对的是跨系统的场景得按传输的方式处理。5.4 现象RZ10 参数加了SAP* 还是登不上按流程在 RZ10 里加了login/no_automatic_user_sapstar 0Display 里也能看到这一行但用 SAP* / PASS 登 790 依然被拒。三个可能的原因按概率从高到低排。第一改完没重启实例或者只重启了 SAP 没重启数据库层面的东西profile 文件里的值还没读进内存。第二改的 profile 不是当前实例实际使用的那个三个 profile 长得像选错了很常见。第三参数名拼错SAP 对参数名的拼写是严格匹配的多一个下划线或者少一个字母都不会报错只是不生效。排查手段是 RZ11。在 RZ11 里输入参数名看「当前值」这一栏。如果显示的还是 1说明内存里的值没变回到重启那一步如果显示 0 但登录仍然失败检查 SAP* 这个用户是不是被锁了用 SU01 在 000 里看它的状态锁了就解锁。还有一种情况是登录时 client 号输成了 000那当然用的是 000 的用户表跟 790 没关系。5.5 现象32 位系统上作业跑一半系统卡死拷贝进行到某个大表的时候SM50 里进程状态变成Running但长时间不动ST06 显示内存和交换区都快满了最后作业被系统取消或者整个实例无响应。32 位系统的地址空间上限摆在那里每个后台工作进程都要占一块并行度设高了、单个大表又没做分段内存很快被吃光。这不是参数调优能彻底解决的问题是架构上限。解决分短期和长期。短期把 Parallel processing 降到 1 到 2同时给大表设 Maximum size of tables让它分段处理别一次性把整张表读进内存。长期看32 位系统只适合做学习和验证真要跑规模化的 client copy换 64 位是迟早的事。另外跑之前用 DB02 看一眼表空间余量空间不够的话作业跑到一半照样中断跟内存问题是两种不同的报错别混为一谈。6. 进阶验证用表行数比对和 SCC3 明细确认拷贝真的干净SCC3 显示全部完成只是说明 SCCL 这个进程正常结束了不代表数据一定完整。真正让我放心的是行数比对——挑一批关键表在 000 和 790 各数一遍数字对不上就说明中间有问题。最直接的办法是写个小报表在两个 client 里各跑一次。下面这段在 ECC 6.0 上能直接跑作用是把系统里所有自建透明表的行数统计出来REPORT z_check_client_copy. TABLES: dd02l. DATA: lt_tabname TYPE STANDARD TABLE OF tabname, lv_tab TYPE tabname, lv_lines TYPE i, lv_total TYPE i. 取所有激活状态的自建透明表Z 开头按需替换成业务表前缀 SELECT tabname FROM dd02l INTO TABLE lt_tabname WHERE tabclass TRANSP AND as4local A AND tabname LIKE Z%. SORT lt_tabname. LOOP AT lt_tabname INTO lv_tab. 动态表名统计行数表不存在时会被短转储捕获跑之前确认表都在 SELECT COUNT(*) FROM (lv_tab) INTO lv_lines. WRITE: / lv_tab, lv_lines. lv_total lv_total lv_lines. ENDLOOP. WRITE: / TOTAL:, lv_total.这段代码有三个地方需要按环境改。tabclass TRANSP限定了只统计透明表如果自建对象里有池表或簇表把条件放宽或者去掉as4local A表示只取激活版本避免把未激活的修改也算进去tabname LIKE Z%是按命名空间过滤如果自建对象用的是其他前缀改这里。SELECT COUNT(*)走的是数据库层的计数大表上会慢但不会把数据读到应用层内存压力可控。跑完之后把两边的输出贴到文本对比工具里 diff 一遍。正常情况下 000 的行数应该大于等于 790因为拷贝期间 000 可能还在产生新数据反过来 790 比 000 多那就一定有问题通常是拷贝期间有人往 790 里灌了数据或者 SCCL 重跑过一次导致重复。第二个验证手段是看 SCC3 里的明细列。除了状态重点看「已复制记录数」和源表的总记录数是否一致。对于被跳过的表逐条确认跳过原因是不是「表分类排除」这类正常原因。这个动作看起来枯燥但它是唯一能证明「拷贝范围符合预期」的证据。第三个手段是抽样做功能验证。挑三到五个关键业务流程在 790 里从建单到过账走一遍。这一步的目的是验证定制和数据是配套的——有些表的数据拷过来了但定制没拷或者反过来光看行数发现不了只有跑流程才会暴露。说个自己的习惯。早些年我图省事SCC3 一显示完成就直接把 790 交给业务方结果对方第一天就报库存数和 000 对不上。后来查出来是拷贝中途某个大表因为空间不足被跳过SCC3 里那一行状态写得很清楚是我没往下翻。从那以后我每次跑完 client copy 都强制走一遍行数比对加明细核对宁可多花半小时也不要在业务方那边返工。这套流程后来还帮我提前发现过一次 profile 选错的问题算是把后悔药提前吃了。希望帮到你。本文还有配套的精品资源点击获取
阅读完成 · 觉得有帮助？
