在SAP中更快、更灵活地执行客户端复制的方法

如果您在管理SAP系统架构那么您一定在某些场景下执行过客户端复制。客户端复制有多种业务场景例如在已有系统上为开发或测试目的创建新客户端或在特定客户端内进行数据刷新。执行客户端复制比恢复或运行整个数据库备份更简单、”侵入性”更低。虽然客户端复制是一项常用且具有高附加值的功能但在客户端大小和总体运行时间方面存在一定的局限性。客户端复制是SAP系统中的标准功能。但也有一种替代方案——CrystalBridge DTSData 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客户端复制——包括远程和本地。