Client copy in S/4HANA: SCCLN, SCC9N, SCC1N

Old and new transactions at a glance

The new tools are not a reworked user interface but a new development on a common architecture. SAP delivered them step by step: most transactions with SAP_BASIS 7.54 (S/4HANA 1909), further functions with SAP_BASIS 7.55 (S/4HANA 2020). The table shows which transaction replaces which and from which level it is available.

Task	Previously	New	From SAP_BASIS
Local copy	`SCCL`	`SCCLN`	7.54 SP00
Remote copy	`SCC9`	`SCC9N`	7.54 SP01
Delete client	`SCC5`	`SCC5N`	7.54 SP00
Client export	`SCC8`	`SCC8N`	7.54 SP02
Import post-processing	`SCC7`	`SCC7N`	7.54 SP02
Copy by transport request	`SCC1`	`SCC1N`	7.55 SP01
Logs (redesigned)	`SCC3`	`SCC3`	7.54 SP01
Determine client size	none	`SCC_CLIENT_SIZE`	7.54 SP00
Compare clients	none	`SCC_COMPARE`	7.54 SP03

Levels according to an overview by an SAP product expert in the SAP Community. Which transactions are available in your system depends on the support package level.

The old transactions will not disappear overnight. SAP Help, for example, still describes how to post-process a client exported with SCC8 using SCC7. As of SAP_BASIS 7.58, i.e. S/4HANA 2023, however, SAP classifies the old copy tools as deprecated. You should therefore base new procedures, runbooks and automation on the N transactions. SAP Note 2962811 bundles general information on the new tools. What each transaction does in principle is described in the overview of client copy transactions.

What is new in SCCLN and SCC9N

Start from a third client: The copy no longer has to be started in the target client. SAP recommends an uninvolved client, for example 000. Logging on as SAP* in the empty target client and restarting the system for this purpose are no longer necessary.
Client lock: The target client is always locked during the copy, the source client by default. The lock applies to SAP GUI and HTTP; only RFC access remains possible. The tool intercepts background jobs in the locked source client. However, users who are already logged on are not logged off automatically.
Optimised for SAP HANA: In a local copy, the data stays in the database instead of passing through the application server. Based on internal tests, SAP states that local copies are up to ten times faster and remote copies up to five times faster.
Splitting large tables: Very large tables are split into packages and copied in parallel. This speeds up the copy and prevents memory limits in HANA and ABAP from being exceeded. As a guideline, SAP recommends two parallel processes per database CPU.
Skipping empty and unchanged tables: An optimiser leaves out tables that are empty in all clients and tables that have not changed since the last copy between the same clients.
Tolerating errors: If required, the copy continues to the end despite a failed exit or a failed table. The exits run in isolation, and whatever fails is recorded in the log.
Test mode and task list: A test run shows the scope and problems in advance. The copy is started directly or as a task list in the background, including via STC01.
New authorisations: Copy runs use the object S_CLNT_CPY; exits that run in another system via RFC use S_CLNT_EXI. Check your Basis roles for these objects.

You start SCC9N in the target system, in a client other than the target client. The tool fetches the data from the source system via RFC and compares the table definitions beforehand. If they differ, for example because of different release or support package levels, SCC9N excludes the affected tables and copies the rest. With the option for incompatible tables, they can be copied anyway. In that case, the tool accepts data loss, for example if a field is missing in the target. You should therefore start a remote copy in test mode first. Which settings actually shorten the runtime is described in the article Speeding up a client copy.

SCC1N: copy by transport request

SCC1N replaces SCC1 and has been available since Feature Pack 01 of S/4HANA 2020 (SAP_BASIS 7.55 SP01). The transaction copies table contents recorded in transport requests between clients of the same system, typically Customizing from the Customizing client to one or more test clients. A lot has changed compared with SCC1:

Several target clients in one run, started from any client
Several requests at once, selected by request, type, transport target, user, CTS project and export or import date
Local requests that have not been released can also be copied, for example to check Customizing in a test client before release
Can be scheduled as a variant in the background: the stored date of the last execution prevents requests from the previous day from being copied again
Every run is recorded in the log in SCC3

Caution. Entries in the target client are overwritten or deleted according to the keys in the transport request. Before the first real run, use test mode to check what SCC1N would change.

SCC8N, SCC7N and snapshots

With the new tools, a client transport runs in three steps: export with SCC8N, import of the transport requests via STMS, post-processing with SCC7N. If required, SCC8N can trigger the post-processing automatically. The export itself continues to run asynchronously, even after SCC8N has finished. Do not start any other copy tool during this time.

Snapshots were added with SAP_BASIS 7.55. Instead of writing files to the transport directory, SCC8N stores the client as a snapshot in the database of the source system. SCC7N fetches it into the target system via RFC. According to SAP, this is faster than using transport requests in most cases. Snapshots are also suitable for freezing a test client after data preparation and restoring it later. Because they are stored in the database, you should delete old snapshots regularly.

Log, size, comparison: new auxiliary tools

The copy log has moved from files to database tables. SCC3 displays it in tabs: running processes, a client overview, a timeline of all actions and one tab each for local copies, remote copies, deletions, exports, imports, copies by transport and comparisons. In the details, you see table statistics, exit messages and the status of each parallel package. How to read such a log and classify terminations is shown in the article SCC3 and common client copy errors.

Two tools are completely new. SCC_CLIENT_SIZE estimates before a copy how large a client or a table is and how much space the target needs. The result is an approximation, as HANA compression is not taken into account. SCC_COMPARE compares clients or tables, locally or via RFC, by checksum or record by record. This helps, for example, to find differences in Customizing after a remote copy.

What has stayed the same

Nothing has changed in the fundamentals. The scope of a copy is still controlled by copy profiles such as SAP_ALL, SAP_CUST or SAP_USER (more in the section Copy profiles). With all profiles except SAP_USER, the tool deletes Customizing and application data in the target client before copying. According to SAP, this is technically unavoidable. The follow-up tasks after a copy from production also remain the same.

Above all, the new tools still have no concept of a time period. A profile selects types of data, not years. If you copy application data, you get the complete history. SAP itself states that a client copy can take several hours to days, depending on the volume of application data. Faster technology shortens this time, but the data volume stays the same.

New tools, same data volume

SCCLN, SCC9N and SCC1N make the client copy faster, more stable and easier to trace. They do not change the data volume: every copy with application data brings the complete history into the target system and therefore into the HANA main memory of QA, test or sandbox.

Instead, the Data Refresh Operator copies a time slice, for example the last 90 days, plus all dependent objects from earlier years. DRO 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. 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
–75%: HANA RAM in non-production

Runtime: in practice, three to five times faster than a full copy – depending on the system, time frame and exclusions, considerably more is possible. A practical value, not a guarantee. HANA RAM: guideline values from reference scenarios. The actual effects depend on system size, history and refresh cycles.

Important for planning: the new SAP tools are available from S/4HANA 1909, and DRO runs on SAP S/4HANA from release 2023. On S/4HANA 1909 to 2022, SCCLN and SCC9N remain the way to go, with the full history. From 2023, you can choose. DRO replaces the client copy, not the system copy.

Sources

SAP Help: New Client Copy Tool (What’s New in ABAP Platform 1909)
SAP Community: New Client Copy Tool (Dominik Ofenloch, SAP)
SAP Help: Local Copy: Copying Clients Within a System (SCCLN)
SAP Help: Copying table data of a transport request (SCC1N)
SAP Help: Copy Profiles (with a note on the old tools as of SAP_BASIS 758)
SAP Learning: Client Copy and Client Transport Tools

New client copy tools from S/4HANA 1909: SCCLN, SCC9N and SCC1N