Speed up SAP client copy: performance & runtime

What determines the runtime of a client copy

The basic article explains in the section Why client copies take so long that copies grow with the history. This article looks at the individual factors. The duration of a client copy results from two variables: how much data is moved and how fast the system and database can move it.

Factor	Why it matters	Lever
Data volume	Every row is read and written. The work grows with every year of history in the source.	Copy less: profile, exclusions, clean-up
Largest tables	A few very large tables, in S/4HANA for example the Universal Journal ACDOCA, determine when the run ends.	Split large tables and copy them in parallel
Processes	Parallel processes are dialog processes from an RFC server group. If there are no free processes, the copy waits.	Choose a suitable number and server group
Database	The CPU, main memory and write performance of the database set the upper limit for throughput.	Avoid other load, monitor the run
Copy method	In a local copy, the data stays in the database. In a remote copy, every row travels over the network via RFC.	Copy locally wherever possible
Target client	A target client that already contains data is emptied before copying, table by table.	Use an empty client or delete it beforehand

You should know the scope before you adjust any parameters. SAP recommends a test run before copying. Its log shows which tables are affected and with how much data. As of SAP_BASIS 7.54, transaction SCC_CLIENT_SIZE also estimates the size of a client from the number of rows and the table size.

Where the time goes

The new copy tools that SAP introduced with SAP_BASIS 7.54 (S/4HANA 1909) work in four phases. The article New client copy tools from S/4HANA 1909 shows which transactions belong to them.

Initialisation. The list of relevant tables is built and the clients are locked.
Analysis. Exits determine which tables are emptied, copied or skipped. Very large tables are split into packages.
Deletion and copying. First, the tables in the target client are emptied, then the source data is inserted. This phase grows directly with the data volume.
Post-processing. Exits adjust data in the target, the locks are released and the log is written.

The tool recognises tables that are empty in all clients from the statistics of the HANA database and skips them. If you copy repeatedly between the same clients, it also leaves out tables that have not changed since the last run. This helps above all when you repeat a cancelled run. The new tools do not offer a classic restart at the point of termination.

Important for planning: the entire runtime is downtime. The target client is locked, and according to SAP, nobody should work in the source client during the copy either, as this can cause inconsistencies. For a copy from production, this is a strong argument for short runs.

Parallel client copy: setting up processes correctly

The most important lever in the tool itself is parallelisation. The parameters for parallel processes determine the maximum number of processes the copy uses and which RFC server group they come from. You maintain the server group in RZ12. Local and remote copies use parallel processes, as does deleting a client.

Number: As a guideline, SAP Help recommends two processes per available database CPU. The number of application servers is not limited.
Plan for dialog processes: The parallel processes are always dialog processes, even if the main run starts in the background. The servers in the group therefore need enough free dialog work processes. The automatic protection against resource overload can limit the number further.
Check the runtime limit: Dialog processes have a maximum runtime. For large copies, SAP recommends increasing this limit, for remote copies in the source system too. Check in RZ11 which profile parameter controls it in your kernel release.
Split large tables: The new tools split very large tables into packages using their own WHERE conditions and copy these packages in parallel. This speeds up the run and prevents memory limits in SAP HANA or in the ABAP server from being exceeded. As of SAP_BASIS 7.56, splitting is permanently activated.
Exclusive locks: With this option, the copy locks each table exclusively in the database while it is being copied. This saves memory and time, but blocks the table for all other access.

The copy evaluates the server group only once, at the start of the copy phase. Changes during the run only take effect at the next start. You can see whether the setting works during the run: the progress in SCC3, the work processes in SM50 and long-running SQL statements in DB02 or in the SAP HANA cockpit. How to read logs and deal with terminations is shown in the article SCC3 and common client copy errors.

Local, remote or export: which is faster

Locally, the data stays in the database. The new local copy (SCCLN) transfers it directly from the source to the target client via INSERT from SELECT, without a detour through the application server. According to internal SAP tests, it is around ten times faster than the old tool.

Remotely (SCC9N), the target system fetches the data from the source via RFC. Every row passes through the application servers and the network, so bandwidth and latency between the systems count too. Beforehand, the tool compares the table definitions of both systems and leaves out incompatible tables. According to SAP, the new remote copy is up to five times faster than the old one. Nevertheless, it is the normal case for a QA refresh from production, because a local copy only works within one system.

Export and import (SCC8N, SCC7N) split the copy into two runs with files in between. This saves no work, but decouples the source and target systems. As of SAP_BASIS 7.55, there are also client snapshots, which are stored directly in the database. According to SAP, they are generally twice as fast as an export to transport requests.

Further levers

Empty target client: A target client that already contains data is emptied before copying, and that costs time in the copy window. SAP therefore recommends copying into a newly created client instead of overwriting an existing one. Alternatively, delete the old target client beforehand with SCC5N, which also works in parallel. This does not eliminate the work, but moves it ahead of the actual window. A new client number has consequences, for example for logical systems and interfaces. This belongs in the planning.
Clean up technical tables: IDocs, work items or change pointers often grow unnoticed in production and travel along with every copy. Whatever is cleaned up there regularly no longer has to be moved by any copy. The article Cleaning up technical tables shows how.
Quiet in the system: Users and jobs in other clients also delay the copy, for example through locks. SAP advises protecting the source and target clients with a system message (SM02) and checking the logons in SM04.
Apply corrections: SAP bundles performance recommendations in KBA 2163425, for large production clients in SAP Note 489690, for SAP HANA in SAP Note 2555451 and for remote copies in S/4HANA in KBA 2953662. Many corrections only apply to certain SAP_BASIS levels.

Selective client copy: what the standard can do

A copy also gets faster if it transfers less. The standard client copy offers three ways to do this, each with a clear limit:

Reduced profile: If you do not need application data, for example for a Customizing or training client, you copy only a fraction with SAP_CUST or SAP_UCUS. This does not help with a QA refresh, because there the application data is the whole point. More on copy profiles in the basic article.
Exclude tables: In the expert settings of the client copy, you can exclude individual tables that are not needed in the target. SAP Note 446485 describes the details. Be careful with application data: anything that is missing leaves gaps in document chains.
Individual transport requests only: With SCC1 or SCC1N, you transfer the content of individual transport requests between clients of the same system, for example new Customizing into a test client. This is not intended for application data.

What the standard cannot do is select application data by business criteria. You cannot set a time period, a company code or a selection of business objects in any copy profile. If you need application data, you copy the client’s complete history. A partial copy by time period needs an additional tool that resolves the dependencies between documents. Otherwise, preceding documents, master data or open items are missing in the target, and tests fail because of data gaps rather than program errors.

Why the data volume decides in the end

All levers affect two things: how fast data is moved and how much work surrounds it. Parallelisation distributes the work across more processes. It does not reduce the data volume. Every row still has to be read, transferred and written, and in a target that already contains data, deleted beforehand.

The database sets the limit. The guideline of two processes per database CPU already shows this: once CPU, memory and write performance are fully utilised, additional processes no longer help. From this point on, the runtime grows with the volume again, and the volume grows with every year of history in production.

Then there is what follows the copy. The BDLS run searches the entire copied history, and in the target system that history occupies main memory, almost as much as in production. A faster copy of the same data volume therefore only solves part of the problem.

Copy less instead of copying faster

The biggest lever is reducing the data volume itself. In production, this is done through archiving and housekeeping. For the copy, the question is which data is really needed in the target. This is where the Data Refresh Operator comes in.

Time slice instead of history: DRO copies a time period, for example the last 90 days, plus all dependent objects from earlier years. It copies business objects rather than date ranges: dependencies are resolved iteratively across the object graph until the fixpoint – the verifiable point at which no new objects are added. The remaining years stay in production.
Export from the first find: The export starts as soon as DRO has found an object. Parallel workers process the work packages.
Pause and resume: Runs can be paused at the level of atomic work packages and resumed later, for example when a maintenance window ends.
Exclusion lists: Tables that nobody needs in the target can be excluded, down to table level.
No BDLS afterwards: DRO knows the fields that contain logical system names and replaces the values during the import, before they are written to the database.

3–5×: faster than a full copy, in practice

A practical value, not a guarantee: in practice, three to five times faster than a full copy – depending on the system, time frame and exclusions, considerably more is possible. DRO runs on SAP S/4HANA from release 2023.

Smaller target systems also need less main memory. How much less is shown on the page Reducing HANA memory in QA, test and sandbox. DRO replaces the client copy, not the system copy.

Sources

SAP Help: Using Parallel Processes (client copy, SAP NetWeaver 7.3)
SAP Help: Client Copier: resource requirements, runtime and system load (SAP NetWeaver 7.3)
SAP Help: Local Copy: Copying Clients Within a System (expert settings)
SAP Community: New Client Copy Tool (SAP blog on the new copy tools)
SAP Community: How to Achieve Best Performance for Client Copies for SAP S/4HANA Projects (SAP blog)
SAP KBA 2163425: Recommendations for client copy performance improvement (SAP Support Portal, login required)

Speed up an SAP client copy: performance, runtime and selective copies