资讯动态

SAP client copy避坑:SAP*登录与SCCL/SCC3排错

发布时间:2026/10/27 5:46:22 来源:尧图企业网站定制
简介这是一份面向SAP Basis管理员、实施顾问及ECC系统学习者的Client Copy实操资料围绕SAP集团拷贝Client Copy场景帮助读者在不影响生产客户端的前提下搭建定制、开发与测试环境。压缩包共1个文件为doc格式的操作手册约776KB内容按主题组织并配有系统界面截图与配置要点说明便于对照查阅。资料覆盖逻辑系统定义、客户端分配、管理员账号与SAP*登录参数处理、SCCL后台拷贝及常见问题排查等模块还整理了网络资料中易被误转的注意点。已有630人学习适合需要梳理集团拷贝流程、建立测试集团或查漏补缺的初中级SAP从业者。1. 集团拷贝卡在登录SAP* 进不去 790后面全白搭做 SAP client copy 的人十个里有八个在第一步就翻车SCCL 排完后台作业日志显示成功转头用 SAP* 登 790屏幕弹“用户名或密码错误”或者干脆提示用户被锁。这不是什么玄学ECC6.0 装完默认就把 SAP* 自动登录关掉了参数 login/no_automatic_user_sapstar 是 1你不改SAP* 在新建集团里根本不存在可用密码。血泪经验是所有集团拷贝client copy 集团拷贝的教程都从 SALE 讲起没人告诉你这个参数得先动。这篇东西就是按我自己踩坑的顺序从逻辑系统定义、790 集团参数、SAP* 解锁到 SCCL 排程和 SCC3 读日志一步步拆开讲新手能照着敲熟手能对根因。2. 拷前准备翻车逻辑系统与 790 集团参数没配对很多人以为 client copy 就是 SCCL 点一下实际上 SCCL 只管“搬数据”搬之前 790 这个集团在系统里得先存在、先有逻辑系统归属否则拷贝出来的集团是个“黑户”——后续做 MM 定制、配 RFC、上传输请求全报“logical system not assigned”。这一章把前置配置的坑按顺序捋清楚每一步都给可抄的路径和参数。2.1 SALE 里定义逻辑系统跨集团表的警告不是吓唬人进 T_code: SALE走 Basis Settings → Logical System → Define Logical System系统第一下就弹“Caution: The table is cross-client”。这句话的意思是这张表存的数据是全集团共享的你在 000 里改一条790、800 全都跟着变。所以逻辑系统这种东西只能定义一次、命名要长期可用不能今天叫 QAS 明天改 QAT。点 New Entries逻辑系统名填 QAS命名习惯三位系统标识别用中文别用空格Name 填个能看懂的描述比如“Test of Logical Systems”。保存时会要求挂一个 Request新系统没现成的就现场建一个记下 Request 号后面查传输用得上。T_code: SALE 路径: Basis Settings - Logical System - Define Logical System Logical System: QAS Name: Test of Logical Systems 保存 - 新建 Request记下 Request 号参数说明Logical System 是后续分配到 Client 的那个键值Assign Logical System to Client 里搜索帮助能搜到的就是它Name 只是给人看的。这里最容易犯的错是逻辑系统名和集团号混着起比如直接叫 790后面做 ALE、RFC 时两边对不上只能删了重建而这张表跨集团删的时候其他环境一起受影响。2.2 Assign Logical System to Client790 的参数一个都不能漏回到 SALE走 Basic Settings → Logical Systems → Assign Logical System to Client同样弹跨系统警告回车过去。界面列出系统里所有 Client前三个是系统自带的 000/001/066 之类点 New Entries 手工加 790。关键参数这么填字段取值说明Client790新集团号三位数字DescriptionTest Of Logic System可任意建议写清用途City城市名可任写不影响功能Logical systemQAS必须选 2.1 定义的那个Std currencyRMB币别定错后面财务凭证全歪Client roleCustomizing定制/测试用生产选 ProductionAutomatic recording of changes勾选自动记录修改方便后续传输Cross-Client Object ChangesChanges to Repository and cross-client Customizing allowed允许改资源库和跨集团定制Protection level0无保护测试环境常规选法eCATTeCATT and CATT allowed后续要跑 eCATT 就得开保存后弹“当更改逻辑系统时小心”回车再提示“Data was saved”才算成。Client role 和 Protection level 是最容易被忽略的两项role 选了 Production790 里就不能做定制SCCL 拷完你会发现改啥都提示“不允许修改”Protection level 不为 0连 SE80 打开都受限。常见做法是测试集团一律 Customizing 保护级别 0 勾 eCATT这三个配套用。提示跨集团表的修改会立刻对所有 Client 生效改之前确认没有别人正在依赖这个逻辑系统。2.3 新集团里 SAP* 登不上RZ10 改 login/no_automatic_user_sapstar这是整篇里最值钱的一段。ECC6.0 装完SAP* 的默认密码是 PASS但系统参数 login/no_automatic_user_sapstar 默认为 1含义是“禁止 SAP* 用默认密码自动登录”所以你在 000 里能进新建的 790 里 SAP* 就是进不去甚至报“user SAP* does not exist”。处理路径T_code: RZ10 菜单: Utilities - Import profiles - of active servers 先导入否则 Profile 搜索帮助是空的 选中当前实例的 profile如 SID_INSTANCE_HOST Edit Profile - Extended maintenance - Change 新建 Parameter: Parameter name : login/no_automatic_user_sapstar Parameter val : 0 Copy - 保存 Display 确认参数已写入第一行 停服务器 - 完全停止 - 重启逻辑说明这个参数是实例级启动参数改完必须重启应用服务器才生效光保存不重启等于没改。导入 profile 这一步也不能省——新装的系统不执行 Import profilesProfile 的搜索帮助里一个值都没有很多人卡在这里以为是权限问题。参数说明值设 0 表示允许 SAP* 以默认密码登录设 1 是生产环境的安全做法。所以正确姿势是拷完、建好正式账号、验证完把这个参数改回 1。我一般会在文档里给这一步单独标红不然测试环境长期开着 SAP*审计一查一个准。重启后登 790User: SAP*Password: PASS进去第一件事不是别的是用 SU01 建一个自己的对话框用户把 SAP* 留作应急。管理员 DDIC 在 client copy 里也有它的位置——DDIC 是 000 里做系统级操作比如 SM13、部分 Basis 事务的账号但它同样不允许做定制所以要定制还得靠 SU01 复制出来的那个 ID。2.4 SU01 复制 ID别拿 DDIC 直接干定制的活正确顺序是先 DDIC 登 000T_code: SU01输入要复制的模板用户点 Copy目标用户名填自己的比如按项目规范起一个角色和参数文件照抄保存后设初始密码、勾“用户首次登录必须改密码”。这样出来的账号带足 Basis 权限又能做定制不至于在 790 里点哪哪报“没有授权”。一步到位的检查清单SALE 两个配置完成、790 参数齐、RZ10 参数为 0 且已重启、SU01 账号可登录。这四项有一个没做SCCL 排下去也是白排日志还会给你一个模棱两可的成功提示。3. SCCL 排程与 SCC3 读日志作业跑了但数据不对的排查前置全绿之后才轮到 SCCL。这一步的坑不在“会不会点”而在“参数选错”和“日志读不懂”。后台作业一跑几个小时跑完日志说完成结果进 790 一看没有数据、或者数据只来了一半这时候要能从 SCC3 的日志细节里判断是拷贝范围选错、还是表被跳过、还是后台作业根本没起来。3.1 SCCL 参数怎么选从 000 拷到 790 的正确配置用 SAP* 或刚建好的账号登 790注意SCCL 要在目标集团里跑不是在源集团T_code: SCCL界面上的核心几项T_code: SCCL登录目标集团 790 执行 Source Client : 000 Target Client : 790当前登录集团只读显示 Selected Profile : 按需选测试集团常用 SAP_ALL 或自定义 SAP_ALL : 全量拷贝含定制主数据应用数据 SAP_APPL : 应用数据定制 SAP_CUST : 仅定制 SAP_USER : 仅用户主数据 SAP_UCUS : 用户定制 Max. Number of Dialog Processes / Background Processes : 默认 Analysis of Tables : 可先跑检查表大小和数量 Schedule as Background Job - Schedule Job - 立即逻辑说明Profile 决定拷什么。只做 MM 定制和程序开发SAP_CUST SAP_USER 一般够用拷 SAP_ALL 会连业务数据一起搬几个小时的作业变成十几个小时。Analysis of Tables 这一步别跳过它能提前告诉你哪些表特别大避免作业跑一半卡在某个大表上。参数说明Schedule Job 里选“立即”最省事选时间段要注意别和生产备份窗口撞车。排完系统提示可以用 SCC3 查日志记住这个事务码接下来全靠它。3.2 SCC3 日志读法哪几行才是真正的失败信号SCC3 进去能看到每次拷贝的记录双击进详情。大多数人只看最上面那个总体状态绿的就说成功这是最大的误读。真正要看的是三段第一段是“已拷贝表数量/总表数量”如果两个数字差很多说明有表被跳过往下翻能看见跳过原因常见是“table is locked”或“table not found in source client”。第二段是每个阶段的耗时和状态client copy 分几个 phase 跑先跑定制、再跑应用数据、最后跑用户中间任何一个 phase 报黄整体也会显示完成但数据是缺的。第三段是日志末尾的统计汇总会写明拷贝了多少条记录。拿这个数字和源集团对一下量级差一个数量级就说明有问题。T_code: SCC3 双击最近一次 copy 记录 看三处: 1) Tables copied / Tables total - 差值大 有表被跳 2) 各 Phase 状态 - 有黄/红 该阶段不全 3) 末尾记录数统计 - 与源端量级对比3.3 作业一直“正在运行”不动SM37 与 SM50 联合定位SCCL 排下去之后最常见的第二个现象是SM37 里作业状态一直 Running几个小时不动SCC3 里也没有新日志。别急着杀作业先看 SM50进程概览找正在跑的那个后台进程看它当前的动作。如果卡在某个表上多半是大表在慢慢搬或者源端有锁。具体排查顺序SM37 - 找到 SCCL 生成的作业 - 看状态与 Spool SM50 - 找 Type BGD 的进程 - 看 Table / Action 列 SM12 - 查是否有锁对象占着要拷的表 ST22 - 若进程消失查是否有 dump常见根因有三种源集团里有长时间未提交的锁SM12 能看到大表数据量超出预期Analysis of Tables 提前就该发现后台进程数配得太少RZ10 里 rdisp/wp_no_btc 相关参数。对应处理分别是找锁的持有人沟通释放、调整 Profile 只拷定制、让 Basis 加后台进程后重启。硬杀作业的后果是 790 处于半拷贝状态得用 SCCL 的 reset 功能清掉重来白白多花一轮时间。3.4 拷完定制在、数据不在Profile 选错的典型表现还有一种迷惑性很强的现象790 里 SE80 能打开、SPRO 能进但打开 MM 的物料主数据一条都没有。这不是拷贝失败是 Profile 选成了 SAP_CUST只搬了定制没搬数据。反过来如果定制在、主数据在、但用户登不上那是漏了 SAP_USER。判断方法很简单SCC3 日志里每个 profile 对应的对象类型是分开列的看“Application Data”那一段是否为空即可。要补的话不用整体重拷单独用 SCCL 再跑一次 SAP_APPL 或 SAP_USER 就行前提是目标集团允许增量拷贝——Client role 是 Customizing 且保护级别 0 的情况下一般没问题。注意反复在同一目标集团上叠加不同 Profile 的拷贝容易产生主数据与定制不一致测试环境可以接受别在接近生产的集团这么干。4. 拷贝过程中的避坑清单五个高频翻车现场这一章全是实打实踩过的记录每条按“现象 → 原因 → 解决”给遇到对得上的直接照做。4.1 现象SALE 保存时提示“Request 不存在”保存不下去原因新装的系统没有可用的传输请求或者当前账号没有 S_CTS_ADMI 相关授权。 解决保存弹框里选“新建 Request”描述随便填记下号如果新建也失败用 SU01 检查账号是否带了 Basis 的传输权限或临时用 DDIC 登 000 操作这一步。顺带说跨集团表的修改建议都挂到同一个 Request 下后面追溯方便。4.2 现象RZ10 里 Profile 搜索帮助打开是空的原因新系统安装后没执行过 Import profiles of active serversprofile 参数没被系统读进来。 解决RZ10 → Utilities → Import profiles → of active servers先导入。导入后日志应显示“Profile import executed correctly”三条 profile 都列出来再回去做 Extended maintenance。导入本身不需要重启但改完参数必须重启。4.3 现象SAP* 密码明明输的 PASS还是报“用户名或密码错误”原因两种可能——login/no_automatic_user_sapstar 还是 1或者 SAP* 在这个集团里被锁/被删。 解决先用 DDIC 登 000 确认参数是否已生效RZ10 Display 看第一行参数没问题就用 SU01 在目标集团里查 SAP* 状态锁定的解锁不存在的用 SU01 重建并给 SAP_ALL 权限。还有一种情况是改完参数没重启显示已保存但实际没加载重启一次就好。4.4 现象SCCL 排程后马上报“User is not authorized”原因执行 SCCL 的账号缺 S_CTS_ADMI 或 SCCL 相关授权对象或者是用了没有 Basis 权限的定制账号。 解决用 SAP* 或 DDIC 执行或者 SU01 里用角色 SAP_BC_CTS_ADMIN 之类补齐权限。别用 2.4 里复制出来的定制账号直接跑 SCCL那个账号是给 SPRO 用的。4.5 现象拷贝日志全绿但 790 里 SPRO 进不去或显示“Client is not changeable”原因Assign Logical System to Client 里 Client role 选成了 Production或者 Protection level 设了非 0。 解决回 SALE 改 790 的 role 为 Customizing、Protection level 归 0保存后重新登录 790。这个改动对已有数据没影响但改完最好再确认一次客户端状态SCC4 也能看和改这些参数效果一样。5. 快速定位这类问题的排查习惯做了几轮 client copy 之后我形成一个固定动作任何一次拷贝在 SCCL 排程之前先花两分钟过一遍“四件套”——SALE 逻辑系统在不在、790 的 role 和保护级别对不对、RZ10 参数是否已加载、账号权限够不够。这四项对应了绝大多数“作业跑了但没用”的场景提前确认比事后看几小时日志划算得多。真出了问题定位顺序我也固定成一条链现象第一现场第二现场常见根因登不进 790RZ10 Display 看参数SU01 查 SAP* 状态参数未加载 / 账号被锁作业不动SM37 状态SM50 进程动作 SM12 锁大表 / 锁未释放 / 进程不足日志绿但没数据SCC3 phase 状态Profile 与对象类型对照Profile 选错定制改不了SALE 的 Client roleSCC4 保护级别roleProduction / 保护非 0保存报 Request 错弹框新建 RequestSU01 查传输授权无请求 / 授权缺失再补两个小技巧。一是每次改完 RZ10 参数重启后用 RZ11 查一下 login/no_automatic_user_sapstar 的当前值比翻配置文件快而且能确认是否真的加载进了内存。二是 SCC3 的日志别只看最新一条把前几次的记录对比着看正常拷贝的耗时和表数量是稳定的某次突然腰斩基本就是 Profile 选窄了或者源端有表被跳一眼就能看出来。提示测试环境验证完 SAP* 能登记得把 login/no_automatic_user_sapstar 改回 1 并重启这是后悔药别等审计来提醒。从那以后我每次做集团拷贝都强制走一遍“四件套 SCC3 三段看日志”的流程哪怕系统是熟的、流程是跑过的也不省这两分钟。这套顺序救过我至少三次——有一次就是差点把 role 设成 Production 就排了作业两分钟的自检省了一整晚的重拷。希望帮到你。本文还有配套的精品资源点击获取

读完文章,也想定制专属网站?

尧图设计师 24 小时内与您沟通定制方案

免费获取报价 →
↑