企业官网建设流程全解析

简介：SAP集团拷贝（Client Copy）实操手册面向SAP ECC 6.0系统管理员与Basis入门者，重点讲解如何从生产集团000复制出测试集团790，以便在不影响生产环境的前提下进行定制、开发和测试。全文以32位ECC系统为环境，依次梳理逻辑系统定义、逻辑系统分配至客户端、新集团登录等关键环节，并记录启用SAP*账户所需的参数配置等易错细节，对数据不一致、权限不足一类问题也给出排查方向。压缩包内仅1个doc文件，约776KB，属于纯文字操作手册，便于打印对照或随时查阅。目前已有630人学习，适合需要独立完成集团拷贝，又不愿被转载且未经核实的网络资料误导的读者，可据此获得一套可照做的流程与避坑参考。

1. 接手一台刚装好的 ECC 6.0，第一件事不是配业务

新装完一套 ECC 6.0（32 位）系统，很多人第一反应是打开 SPRO 配业务，结果配到一半发现改的东西直接影响 000 生产集团，回头想把测试集团单独拆出来，才发现 SAP 集团拷贝（Client Copy）这条路前面还埋着好几个开关。我见过最典型的翻车现场是：SALE里逻辑系统定义好了，790 集团也建出来了，SCCL后台作业排下去，喝杯水回来一看——SAP*登不进 790，SCC3日志干干净净，一行有用的报错都没留。这套流程几乎每个刚接手 Basis 活的运维都要走一遍，坑集中在三处：管理员账号、逻辑系统、profile 参数。下面按我实际装下来的顺序，从环境盘点一路写到你确认拷贝真的跑通了。

2. 拷贝前的环境盘点：SID、管理员账号和逻辑系统

在敲第一个 T-code 之前，我习惯先把这台机器的底盘信息抄到一个 txt 里。原因很直接：RZ10里那堆 profile 文件名，前半段是 SID，后半段是主机名，改参数的时候对不上号，你会在搜索帮助里翻十分钟还找不到自己这台机器。

2.1 先把版本、位数和 SID 对清楚

ECC 6.0 的 32 位系统和 64 位系统在 Client Copy 这种大批量数据搬运的场景下表现差别不小。32 位内核的地址空间有限，拷贝 SAP_ALL 这种全量 profile 时，后台作业更容易撞上内存相关的运行时错误，尤其是表数据量大的系统。这不是说 32 位不能跑，而是你要对"作业跑一半被杀掉"有心理准备，并且提前把日志空间和表空间留够。

表里最后一行要特别留意。DDIC和SAP*的密码是安装过程中设定的，不是你后来改的，装完系统没记下来的话，先找当时的安装记录，别急着重装。这两个账号的定位也不一样：DDIC是系统保留账号，专门用于数据字典和软件维护，SAP 不允许拿它做系统定制；SAP*是紧急超级用户，平时不该用它做日常操作。所以真正要在 790 里做定制开发，得另建一个普通对话账号。

提示：把 SID、实例号、主机名、profile 文件名一起记下来。后面每次改参数、查日志、重启实例都要用到，少一个就得回去翻系统状态。

2.2 用 SU01 复制一个能干活的管理员 ID

新建账号最省事的做法是用SU01复制，不是从零建。步骤是：用DDIC登录 000 → 事务码SU01→ 在用户字段输入目标 ID（比如JIAHG这类你们团队约定的命名）→ 点“复制”按钮 → 参照源用户选一个权限已经比较全的对话用户 → 保存。

SU01 用户：JIAHG ← 目标账号，先别在这里点创建 按钮：Copy ← 关键，从已有用户复制属性 参照（Reference）：填入一个权限齐全的对话用户 保存

为什么要“复制”而不是“创建”：复制会把参照用户的地址信息、登录语言、用户组、参数页签一起带过来，尤其是参数页签里的CATT、SAPGUI这类默认值，手工建很容易漏。复制完有两个地方必须回头核对：一是“角色”页签，确认 SAP_ALL、SAP_NEW 这类大权限是按你的测试需求给的；二是“登录数据”页签里的初始密码和“首次登录必须修改”标记，测试集团里我一般把强制改密关掉，省得每次拷贝完还要改一遍。

注意：给 SAP_ALL 只在测试集团里说得通。790 是拿来跑定制和开发的，权限给足没问题；但你不要把这个账号的权限顺手复制到 000，那是另一码事。

2.3 在 SALE 里定义逻辑系统 QAS

逻辑系统是给集团做身份标记用的，SAP 用它来区分“这批数据是从哪来的、要传到哪去”。路径是SALE→ Basis Settings → Logical System → 点“Define Logical System”。进去之前系统会先弹一句警告，大意是“此表是跨集团的”，意思是这张表存在数据库里，所有集团共用一份，你在任何一个集团里改了，其他集团看到的也跟着变。这句话不是吓唬人，回车继续就行，但心里要清楚：这类跨集团表的改动，一律记进请求号，出问题能顺藤摸瓜。

点“New Entries”新建一条：Log.System填QAS，Name填一段能看懂的描述，比如“Test of Logical Systems Create by Jiahg”这种团队内部能认出来的写法。保存的时候系统会弹请求号（Request），新系统里如果还没有请求，就按提示新建一个，填个描述确定即可；已有请求的话挂上去也行。

SALE Basis Settings → Logical System → Define Logical System New Entries Log. System : QAS Name : Test of Logical Systems Create by Jiahg 保存 → 记录请求号（Request No.）

请求号一定要抄下来。后面分配逻辑系统到集团、改集团参数，都会往同一个请求里写，等哪天要往其他系统传配置，这个号就是唯一的线索。我踩过一次坑：请求号随手点了确定没记，后来要查是谁在什么时候改了逻辑系统，只能从SE10里一条条翻，翻了半小时。

3. 建出 790 集团：Assign Logical System to Client 的字段取舍

逻辑系统有了，接下来才是真正把 790 这个集团“登记”进系统。这一步在SALE里的路径是 Basic Settings → Logical Systems → Assign Logical System to Client。点进去同样会弹跨系统表的警告，回车。

3.1 New Entries 里每个字段怎么填

点“New Entries”进入集团明细界面，这里的每个字段都会影响后面SCCL能选什么、系统允许你做什么，值得一个一个过。

货币这一项要单独说一句。集团标准货币在集团建好之后再改，涉及已过账凭证的换算，非常麻烦。测试集团跟随生产用同一种货币就行，别在这里做实验。

3.2 Client role、保护级别和跨集团开关，三个最容易选错的

Client role决定这个集团的“性格”。选 Customizing，系统认为这是个做定制的集团，SCCL里可以选全量拷贝，也能做请求传输；选 Testing，偏向测试，某些传输行为会受限；选 Production，系统会把它当生产集团对待，很多操作直接给你拦掉。790 是拿来定制开发和测试的，选 Customizing 最合适，后面想改成 Testing 也不是不行，但改之前先想清楚你要不要往这个集团传请求。

Protection level从 0 到 3，数字越大保护越严。3 基本等于只读，连登录都受限制。测试集团选 0，不然你会发现自己在 790 里什么都点不动，回头还得回来改。

Cross-client object changes这一项是血泪经验。原文里选的是“Changes to Repository and cross-client Customizing allowed”，意思是允许在这个集团里改 ABAP 资源库对象和跨集团定制。如果这里设成不允许，你在 790 里打开SE38想改个程序，系统直接拒绝，报的错还特别含糊，新手很容易以为是权限问题，跑去SU01折腾半天。同一个界面上还有“自动记录修改”的勾，建议勾上，定制的每一步都进请求，将来要往测试机或生产机搬的时候有据可查。

3.3 保存之后确认集团真的存在

参数填完点保存，系统会先弹一句“当更改逻辑系统时小心”，回车即可，然后提示“Data was saved”。到这里别急着去登录，先退回SALE的集团分配列表，确认 790 那一行确实出现了，逻辑系统列显示的是 QAS，角色列是 Customizing。这一步看起来多余，但我遇到过保存提示成功、实际因为请求号被锁住没写进去的情况，列表里一查就露馅。

SALE Basic Settings → Logical Systems → Assign Logical System to Client New Entries Client : 790 Client Name : Test Of Logic System Logical system : QAS Std currency : RMB Client role : Customizing 保存 → 返回列表核对 790 行

4. 让 SAP* 能登进新集团：RZ10 参数与 SCCL 排程

集团建出来了，接下来按大多数人的习惯，打开 SAP GUI 选 790，用户名SAP*、密码PASS，回车。新装的 ECC 6.0 在这一步有相当大概率直接给你一句“用户或密码错误”。这不是你密码记错了，是系统压根就没在新集团里给你准备SAP*。

4.1 新集团登不进 SAP* 的原因

SAP 有一个参数叫login/no_automatic_user_sapstar，它控制“当一个集团里不存在 SAP* 用户时，系统要不要自动用默认密码 PASS 建一个”。这个参数是全局的，写在 profile 里，实例启动时读入。ECC 6.0 装完之后这个参数通常是 1（禁止自动创建），所以 000 里的 SAP* 是安装时手工建的，而你新建的 790 里空空如也，自然登不进去。把参数改成 0，重启实例，再登录 790，系统会自动在该集团创建 SAP*，密码就是 PASS。

注意：这个参数是全局生效的，不是只对 790 生效。改完之后，任何“没有 SAP* 用户”的集团都能用默认密码进，安全性上是打了折扣的。所以进去第一件事就是给 SAP* 设一个强密码，或者干脆用 2.2 里SU01复制出来的账号干活。

4.2 RZ10 先做 Import profiles，否则搜索帮助是空的

登录 000，事务码RZ10，菜单 Utilities → Import profiles → of active servers。这一步很多人跳过，结果在后面的 profile 搜索帮助里一个值都看不到，以为系统坏了。原因很简单：刚装完的系统，profile 文件躺在操作系统目录里，但还没导进数据库表，RZ10只认数据库里的那份。

导入完成后界面会显示三条状态，大意是“配置文件导入执行正确”。看到这个再往后走，否则后面所有操作都是空转。返回RZ10初始界面，点Profile字段的搜索帮助，这时候应该能看到至少三个已装载的 profile。

RZ10 Utilities → Import profiles → of active servers 确认状态：Profile import executed correctly 返回 → Profile 搜索帮助应能看到已装载的 profile

profile 的命名规则是“SID_实例相关标识_主机名”，每台机器都不一样。比如 SID 是 DEV、主机名是 SAPTEST，你看到的可能类似DEV_ECC01_SAPTEST这种形式，前半段对 SID，后半段对主机名。照着这两个线索找，别照抄别人文档里的文件名。

4.3 Extended maintenance 里加参数

选中你那个 profile，在 Edit Profile 选项里选“Extended maintenance”，点“Change”，然后点“Parameter”按钮新建一行：

Parameter name : login/no_automatic_user_sapstar Parameter value: 0

填完点“Copy”，弹窗回车，然后保存。保存后别急着退出，点“Display”看一眼，确认这一行真的写进去了，而且值确实是 0 不是 1。我吃过一次亏：参数名少打了一个下划线，保存照样成功，重启照样生效，就是不起作用，查了快一个小时。

4.4 停实例、起实例，参数才会被读进去

profile 参数不是保存即生效，必须重启实例。以<sid>adm身份在操作系统层执行：

# 切换到 <sid>adm，SID 按现场替换，这里是 devadm su - devadm # 停止实例，等它完全停下来 stopsap # 用 sapcontrol 确认进程真的没了，实例号按现场替换（00） sapcontrol -nr 00 -function GetProcessList # 确认停止后再启动 startsap # 启动后复查进程状态，所有进程应为 GREEN sapcontrol -nr 00 -function GetProcessList

stopsap和startsap是最省事的封装脚本，等价于对实例下所有进程做有序停止和启动。sapcontrol -nr 00里的00是实例号，填错了会报找不到实例。中间那次GetProcessList不要省，SAP 有时候stopsap返回了但某个进程还在收尾，这时候直接startsap容易出奇怪的状态。等所有进程都是 GREEN 再登录。

4.5 SCCL 排程，SCC3 看日志

参数生效后，登录 790，用户名SAP*、密码PASS，能进就说明前面的活都对了。进去先改密码。然后事务码SCCL，这是 Client Copy 的主入口。

界面上要填的就三块：源集团（Source Client）填 000，目标集团（Target Client）就是当前登录的 790，然后选拷贝 profile。profile 的选择决定了你这次搬多少东西：

• SAP_USER：只搬用户主数据，量最小，适合先探路
• SAP_CUST：只搬定制，不含业务数据
• SAP_APPL：搬应用数据，通常配合定制一起用
• SAP_ALL：全量，定制加数据加用户，最慢也最吃资源

我的习惯是先跑一次SAP_USER，几百兆的量，几分钟就能看到结果，确认源到目标的通路是通的、后台作业能正常起，再排SAP_ALL。一上来就全量，跑两小时挂掉，你连是哪一步出的问题都不知道。

勾上“Schedule as Background Job”，点执行，弹窗直接回车，进入排程界面选“立即”，再回车，点“Continue”。系统会提示你可以用SCC3查看拷贝日志。

SCCL Source Client : 000 Target Client : 790 Profile : SAP_USER（先探路）/ SAP_ALL（全量） 勾选 Schedule as Background Job → 立即 → Continue 记下生成的作业名，用 SCC3 跟踪

5. 避坑与排查：Client Copy 五个卡点，现象、原因和补救

这一节是我自己踩过、也帮别人收拾过的五处，按“现象 → 原因 → 解决”写。每一条都不是理论推演，是真实卡住流程的地方。

第一条：RZ10 里 Profile 搜索帮助一片空白。现象是打开RZ10，点 Profile 字段的搜索帮助，列表里什么都没有，或者只有一两条不是你机器的。原因是安装完成后没有执行 Import profiles，profile 文件还在操作系统层，没进数据库。解决就是回RZ10菜单走一遍 Utilities → Import profiles → of active servers，确认状态行显示导入成功，再返回看搜索帮助。顺带一提，如果你刚换过内核或者改过 profile 文件，也要重新导入一次，别以为导入过就一劳永逸。

第二条：参数改成 0 也重启了，SAP还是登不进 790。* 现象很气人，RZ10里 Display 看得清清楚楚login/no_automatic_user_sapstar = 0，实例也重启过，790 照样报用户密码错误。原因通常是两个：一是你改的 profile 不是实例启动时真正加载的那个，机器上可能有多个 profile，改错了文件；二是保存后系统提示“需要生成新 profile”，你没做这一步，参数写进了数据库但没落到实际读的文件里。解决是先sapcontrol -nr 00 -function GetProcessList确认实例号，回RZ10选中正确的 profile 再 Display 确认一遍，保存时留意有没有生成新 profile 的提示。实在拿不准，改完重启后看实例的启动日志，里面会打印实际加载的 profile 路径。

第三条：SCCL 作业排下去几秒钟就“完成”，SCC3 里日志是空的。现象是后台作业状态显示已结束，点进SCC3什么记录都没有，或者只有一行“作业已取消”。原因多半在逻辑系统：790 的 Logical system 字段是空的，或者填了一个SALE里根本没定义的名称，系统在准备阶段就退出了。另一种可能是 790 的角色被设成了 Production，SCCL在准备阶段直接拒绝执行。解决是回SALE检查 790 那一行的 Logical system 是不是 QAS、Client role 是不是 Customizing，改完重新排一次SCCL。排程前先跑SAP_USER这个小 profile，能在几分钟内暴露这类配置问题，比等全量跑一半失败划算得多。

第四条：790 里 SAP能用了，000 的 SAP反而出问题。** 现象是改完参数重启，790 顺利进去，回头登 000 发现 SAP* 的行为变了，或者多出来一批不该有的默认账号。原因是这个参数全局生效，它对所有集团一视同仁，不是单独给 790 开的。解决思路是别把这个参数当成长期状态：进 790 之后立刻给 SAP* 设强密码，日常工作用SU01复制出来的JIAHG账号，然后把参数改回 1 再重启一次，把口子收回去。测试环境图省事可以放着，但你要清楚这是拿全局安全换的便利。

第五条：全量拷贝跑到一半失败，SCC3 日志里一堆表名。现象是作业跑了很久，突然状态变成“已取消”，SCC3展开日志能看到具体某张表拷贝失败。原因集中在资源上：32 位系统地址空间有限，大表读取时容易内存不足；或者表空间、日志空间不够，写到一半没地方落；还有一种是后台作业被其他管理员手动取消了，这种情况日志里的提示会明显不同。解决是先看日志里失败的第一张表是哪张，判断是数据量问题还是空间问题；用DB02或数据库端工具确认表空间余量；32 位系统跑SAP_ALL建议分批，先SAP_CUST再单独跑数据，别指望一次成功。跑之前把实例参数里的内存相关项按 SAP 的标准建议调一遍，这个投入比失败重跑划算。

提示：每一条排查都从“先确认现象是不是你以为的那个现象”开始。SCC3 的日志是黑匣子，但它只记结果不解释过程，配置层面的问题往往要在 SCCL 排程之前就查掉。

6. 装完怎么验证：SCC3 日志、T000 字段和一份对照清单

拷贝作业结束不等于拷贝成功，这一点必须说清楚。后台作业显示“已完成”只代表进程跑完了，数据是不是真的搬过去了，要分三层看。第一层是SCC3的日志本身，展开每一次拷贝记录，状态列应该是成功，失败的表会单独列出来；第二层是目标集团的系统状态，登录 790 跑一遍日常操作，看有没有缺表、缺视图的报错；第三层是数据层面对照，用SE16查几张关键表，比对 000 和 790 的记录数。

我一般用下面这几条做终检：

T000 那几个字段名在不同版本、不同界面上显示可能略有差异，以SE16实际列出来的为准，别死记硬背。下面这段 SQL 是给习惯从数据库端直接看的人用的，字段名同样以现场为准：

-- 确认 790 已注册，且逻辑系统和角色正确 SELECT MANDT, MTEXT, LOGSYS, CCCATEGORY, CCNOCLIIND FROM T000 WHERE MANDT IN ('000', '790'); -- 确认 790 里有可登录的对话账号（SAP* 或你自己复制的 ID） SELECT MANDT, BNAME, USTYP, UFLAG FROM USR02 WHERE MANDT = '790';

第一段查 T000，重点看三列：LOGSYS 应该是 QAS，CCCATEGORY 应该是 C，CCNOCLIIND 应该允许跨集团更改。如果 LOGSYS 是空的，说明你当时在SALE里保存没落库，回第 3 章重走一遍。第二段查 USR02，USTYP是用户类型，UFLAG是锁定状态，测试集团里不要出现一堆锁死的账号。

最后加一条经验性的检查：登进 790，随便打开一个事务码SE38，试着新建一个测试程序，能建、能激活、能删，说明资源库是可写的；再跑一个简单的业务查询，能出数据，说明应用数据搬过来了。这两下做完，这个集团才算真的能用。

从那以后我每次做完 Client Copy，都会强制走一遍“SCC3 日志 + T000 三字段 + 一次写操作 + 一次读操作”这套动作，不管作业状态显示多漂亮。SAP 的后台作业太容易给你一个“已完成”的假象，省这一步，后面做定制开发时冒出来的怪问题，排查成本是这里的十倍。希望帮到你。

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