如果您在管理 SAP 系统架构，那么您一定在某些场景下执行过客户端复制。客户端复制有多种业务场景，例如在已有系统上为开发或测试目的创建新客户端，或在特定客户端内进行数据刷新。执行客户端复制比恢复或运行整个数据库备份更简单、 ” 侵入性 ” 更低。虽然客户端复制是一项常用且具有高附加值的功能，但在客户端大小和总体运行时间方面存在一定的局限性。

客户端复制是SAP 系统中的标准功能。但也有一种替代方案——CrystalBridge DTS （Data Transformation Streamlined ，数据转换流式处理）—— 它可以节省大量时间和客户工作量。在比较两者之前，让我们先简要总结一下SAP 的标准功能。

SAP 标准场景：本地客户端复制和远程客户端复制

客户端复制是SAP 系统中的标准功能，有两种基本场景：

■ 本地客户端复制（SCCL ） —— 在同一个数据库上创建客户端的本地副本，用于测试或开发目的，不会影响生产客户端。所有更改都在同一数据库上执行。

■ 远程客户端复制（SCC9 ） —— 通过预先创建的 RFC 连接，将客户端从源系统复制到目标系统。数据从源系统读取，然后写入目标系统的数据库。

对于这两种场景，都有多种配置文件（Profile ）可用，简化了要复制对象的选择和组合，通常根据业务场景进行选择。一般来说，SAP 提供以下配置文件：

SAP 客户端复制配置文件

客户端复制可能需要数天甚至数周

规划客户端复制时需要考虑的因素主要包括客户端大小、流程总体持续时间以及所选的场景。

客户端复制的持续时间取决于源客户端的实际大小。每个SAP 表都在一个后台进程中处理，这在运行时间方面造成了巨大的瓶颈。客户端传输的总体时间取决于系统中更大的SAP 表的复制时长。特别是对于大型客户端，SAP 提醒客户客户端复制可能需要数天或数周的时间（见SAP Note 2163425 ）。

数天的运行时间通常对客户来说是不可接受的。为避免过长的运行时间，SAP 建议执行完整的数据库复制，这需要额外的资源和投入（例如额外的硬件和必要的系统调整）。

客户端复制过程中遇到问题？需要从头开始

另一个影响运行时间的因素是所选的场景。一般来说，本地客户端复制比远程复制更快、问题更少。由于源系统和目标系统是相同的，不太可能出现与字典差异或软件版本差异相关的问题。但对于远程复制，首先需要考虑的是源系统和目标系统应具有相同的组件版本和内核版本。如果这些不一致，远程客户端复制将被中止。

如果在复制过程中出现问题—— 例如DDIC 字典变更、网络相关问题、连接丢失、RFC 故障或意外系统不可用—— 是无法继续复制的。一旦发生这些情况，需要解决问题、删除目标客户端，然后从头开始整个过程，这可能导致数天的损失。

CrystalBridge DTS 提供灵活性并显著缩短总体运行时间

CrystalBridge DTS 为这两种场景提供了可行的替代方案。使用独特的方法和工具集，SNP 可以更快、更省力地执行本地和远程客户端复制，并且风险更小—— 因为该过程可以随时暂停和恢复。

如果需要进行调整，范围内的表可以动态更新并按需重新执行。从性能角度来看，更大的优势体现在远程客户端复制中。CrystalBridge DTS 还支持所有版本的SAP S/4HANA 以及标准SAP ECC 上的客户端复制。

案例研究：CrystalBridge DTS 仅用九小时完成任务

■ 场景 ：远程客户端复制 —— 以 S/4HANA 作为源和目标进行客户端传输。客户希望将客户端从开发系统传输到质量系统以执行 UAT （用户验收测试）。

■ 客户端大小 ：2 TB HANA 内存 + 约 2TB 磁盘空间

■ 源和目标系统 ：S/4HANA 1909 FPS 01

最初，SAP 标准远程客户端复制（SCC9 ）被用作默认解决方案，但在运行约27 小时后，复制进程停滞。在提交SAP 事件工单后，建议是遵循并应用SAP Note 2761821 、2868569 和2163425 中的修正以提高性能。应用修正后，远程客户端复制被重置并从头开始执行。32 小时后再次停滞，客户无法完成复制。

由于项目进度紧张，客户随后决定使用CrystalBridge DTS 来执行远程客户端复制。使用默认的CrystalBridge DTS 设置，客户端复制在不到9 小时内成功完成。

总结

由于SAP 标准客户端复制功能在运行时间和执行限制方面存在局限，SNP 提供了一种替代且高效的客户端复制方式。CrystalBridge DTS 提供了一种全新且可靠的客户端复制方法，显著缩短了运行时间并改善了执行效率。除标准SAP ECC 复制外，还完全支持S/4HANA 客户端复制—— 包括远程和本地。