A much faster and more flexible way to do a client copy in SAP

If you are running an SAP landscape, then you must have had to perform a client copy in one of your systems at some point. There are multiple business scenarios for client copies, such as creating a new client for development or testing purposes on an already existing system or a data refresh within a specific client.

2/13/2023  |  6 min

Topics

  • S/4HANA
people_business_men_laptops.jpg

An alternative to the standard client copy

If you're running an SAP landscape, then you must have had to perform a client copy in one of your systems at some point. There are multiple business scenarios for client copies, such as creating a new client for development or testing purposes on an already existing system or a data refresh within a specific client. Performing a client copy is also easier and less “invasive” than restoring or running a backup of the whole database. Although client copy is a commonly used function with high added value, there are certain limitations when it comes to the client size and overall runtime duration.

Client copy is a standard feature available in SAP. But there is also an alternative solution – CrystalBridge DTS (Data Transformation Streamlined) – which can save lots of time and customer effort. Before comparing the two, let us briefly summarize the SAP standard capabilities.

SAP standard scenarios: Local client copy and remote client copy

Client copy is a standard feature available in SAP systems, with two basic scenarios:

  • Local client copy (SCCL) – Creating a local copy of a client, for testing or development purposes without the risk of affecting the productive client. All the changes are performed on the same database.
  • Remote client copy (SCC9) – Copying client from the source system is copied to the target system via RFC, which is created in advance. Data is read from the source and then written to the target’s database.

For both scenarios, multiple profiles are available that simplify the selection and combination of the objects to be copied, and they are often chosen depending on the business scenario. In general, SAP delivers the following profiles:

SAP client copy profiles

Profile Purpose
SAP_USER

Users, user roles and authorization profiles are copied. The client is not reset.

SAP_UONL

Users without authorization profiles and roles

SAP_PROF    Only authorization profile and roles
SAP_CUST   Client-specific customizing including authorization profile is copied. The application data is deleted but the user data is retained.
SAP_CUSV     Corresponds to SAP_CUST with variants
SAP_UCUS     Corresponds to SAP_CUST with master data
SAP_UCSV     Corresponds to SAP_UCUS with variants
SAP_ALL     All client data except change documents (see note 180949) and local data is copied.
SAP_APPL     SAP_ALL without user master data
SAP_APX     SAP_ALL without authorization profile and roles

Client copy can take several days or even weeks

Factors that you need to consider when planning the client copy are mainly the client size and the overall duration of the procedure, as well as the chosen scenario.

The duration of the client copy is dependent on the actual size of the source client. Each SAP table is processed in one background process which creates a huge bottleneck in terms of runtime. Overall time for a client transfer is based on the duration of the copy of the biggest SAP table in the system. Especially for large clients, SAP warns customers that the client copy can potentially take several days or weeks (see SAP Note 2163425).

A runtime of several days often means a no-go for the customer. To avoid very long runtimes, SAP recommends performing a full database copy, which requires additional effort and resources. (such as additional hardware and necessary system adjustments).

Ran into an issue during a client copy? You need to start over

Another factor that affects the runtime is the chosen scenario. In general, a local client copy is faster and less troublesome than a remote copy. Since the source and target systems are identical, you are unlikely to have issues related to differences in dictionaries or software versions. However, for remote copies the first thing that needs to be considered is that the source and target system should have the same component version and kernel versions. If these are not identical, the client remote copy will be aborted.

It is not possible to continue with the copy if issues occur – for example, DDIC changes, network-related issues, loss of connectivity, RFC failure or unexpected system unavailability. If that happens, the issues need to be resolved, target client dropped and the whole process must start over, which can lead to a loss of several days.

CrystalBridge DTS offers flexibility and significantly reduces the overall runtime 

CrystalBridge DTS offers a viable alternative to both scenarios. Using a unique approach and toolset, SNP can perform both local and remote client copies much faster, with less effort and with minimal risk as the process can be paused and resumed at any time.

In case any adjustments are needed, the tables in scope can be dynamically updated and re-executed, if necessary. From the performance point of view, the biggest advantage is achieved with remote client copies. CrystalBridge DTS also supports client copies on all versions of SAP S/4HANA, as well as standard SAP ECC.

Case study: CrystalBridge DTS completes the task in just nine hours

Scenario: Remote client copy – Client transfer using S/4HANA as the source and target.The customer wants to transfer client from the development system to their quality system in order to perform UAT.
Client size: 2 TB HANA memory + ~2TB disk space 
Source and target systems: S/4HANA 1909 FPS 01

At first, SAP standard remote client copy (SCC9) was used as the default solution, however after approximately 27 hours of runtime, the copy process stalled. After opening an SAP incident, recommendation was to follow and apply corrections from SAP notes 2761821, 2868569 and 2163425 to improve the performance. Corrections were applied, and remote client copy was reset and executed from the beginning. After 32 hours it stalled again and the customer was not able to finish the copy.

Due to the project’s tight schedule, the customer then decided on CrystalBridge DTS  to perform a remote client copy. Using default CrystalBridge DTS settings client copy was successfully finished in just under 9 hours.

Summary

Due to the limitations of SAP standard client copy feature in terms of runtime and execution limitation, SNP  offers an alternative and effective way of performing client copies. CrystalBridge DTS offers a new and reliable approach to client copies, delivering significantly shorter runtime and execution improvements. Alongside standard SAP ECC copies, S/4HANA client copies are fully supported too - both remote and local.

Topics

  • S/4HANA