SAP SCC3: analysing client copy errors

What SCC3 shows

Transaction SCC3 (copy logs) lists the runs of the client tools with their status and log. What it looks like depends on which tools you use for copying:

Classic tools (up to SAP_BASIS 7.53): SCC3 shows the copies for which the logon client was the target. For each run, there is a summary with copy type, profile, status, user, the tables with copy problems and statistics. “Details” adds runtimes and record counts per table and the exit programs used; the file log shows the original log in the file system.
New tools (as of SAP_BASIS 7.54): The log is stored in database tables instead of files. The start screen has tabs: “Active Processes” for running copies, the “Client Overview”, a “Timeline View” of all actions and one tab each for local copies, remote copies, deletions, exports, imports, copies by transport and comparisons.

You can download the new log to your computer, for example to document the refresh. What else has changed with SCCLN, SCC9N and SCC1N is shown in the article New client copy tools in S/4HANA. You will find an overview of all transactions in the basic article SAP client copy.

Reading an SCC3 log: status, tables, messages

With the new tools, double-clicking a run opens the detailed log. Go through it in this order:

Header and status. Execution mode, profile, source and target client, exit status and overall status. Here you can see whether the run finished cleanly, finished with errors or did not finish at all. Check the mode as well: a test run does not write any data.
Options. All settings from the selection screen, such as profile, parallel processes, locks and tolerated errors. You need this information if you repeat the run with the same settings.
Table statistics. Number of emptied, deleted and copied tables and records. Skipped tables are not an error: the tool deliberately leaves out tables that are empty or have not changed since the last copy.
Messages. The general messages of the copy tool and, separately, the messages of the application exits. An error in an exit comes from the application concerned, not from the copy tool.
Tables and packages. The list of processed tables shows the progress during the run. Another list shows which tables were included or excluded by logic or exits. Large tables are split into packages, and you can see which package is in which process.

Not every warning is a problem. What matters are the overall status, failed tables and exits with an error status. If failed tables or exits were tolerated in the options, the copy runs to the end despite errors. The affected tables are then listed in the log, and you have to deal with them specifically. You should therefore check the list of failed tables even after an apparently successful run.

Common client copy errors and their causes

A client copy moves large volumes of data and puts a heavy load on the database, processes and memory. Many terminations and warnings have one of these causes:

Symptom	Typical cause	What to do
Write errors in the target client	Usually a lack of space in the database, less often simultaneous work in the target client	Look for the cause in the system log (SM21), free up space, repeat the copy. There is no need to delete the target client beforehand.
Termination with a short dump due to memory	Very large tables exceed memory limits in ABAP or HANA	Analyse the dump in ST22. Have large tables split so that they are copied in smaller packages.
Termination in an exit	Error in an application’s exit program, not in the copy tool	Check the exit messages in SCC3 and the dump in ST22; with the classic tools, use report RSCCPROT. Search for SAP Notes on the affected application.
Tables missing after the remote copy	Different table structures in source and target, usually due to different release or support package levels. Incompatible tables are excluded and the copy continues.	Start the remote copy in test mode first and check the log. Align the levels. The option for incompatible tables accepts data loss.
Remote copy cannot access the source system	Faulty RFC destination or incomplete authorisations of the RFC user in the source client	Test the destination in SM59. The RFC user needs S_TABU_RFC and, for exits in the source system, S_CLNT_EXI as well.
Run slows down or hangs	Locks held by users or jobs, including from a third client in the same system, or too few free processes	Check in SM50 and SM66 what the processes are working on. Inform users with a system message (SM02) and check in SM04 that nobody is logged on.
Termination when started in the foreground	Runtime limit for dialog processes. Parallel processes use dialog processes even when the copy is started in the background.	Start in the background or as a task list. If necessary, increase the timeout with a profile parameter, as described in SAP Help.
SCC3 shows “cancelled”, but the export is running	The client export runs asynchronously via the transport tools. Depending on the release, SCC3 shows no status or an incorrect status during this time.	Check the export log of request <SID>KT<no.> in SE01. Do not start any other copy tool until the export has finished.

Further transactions for error analysis

SCC3 shows what the copy tool knows. For unclear terminations, SAP recommends checking these places as well:

SM21 (system log): Database errors, space problems, cancelled processes. According to SAP, messages stating that synchronous matchcode maintenance has been completely deactivated or that the TABL/TABLP buffer has been reset are not errors but part of the copy.
ST22 (dump analysis): Runtime errors in copy processes and exits.
SM37 (job overview): Status and job log of the copy job. If the copy runs as a task list, STC02 also shows the status of the task list run.
SM50 and SM66: which processes are currently working on what, on one or on all application servers.
SP01 or SP02: spool output of the copy job.
SE01: logs of the export requests in a client transport.

SAP collects further information on error analysis in SAP Note 22514. With the classic tools, the view V_CCCFLOW is also useful: among other things, it contains the runtime, the status, the number of copied tables and the table currently being copied.

Client copy cancelled: restart instead of a new start

If a copy terminates for technical reasons, for example due to a database shutdown, you do not have to start from scratch. SAP provides a restart with the same settings. All exits run again. Tables that have already been copied are skipped if they are unchanged. A table that was only partially copied is not continued: the copy initialises it and copies it again in full.

The classic tools automatically suggest restart mode the next time the transaction is called and take over the parameters. Alternatively, the run can be started again completely. With the new tools, the optimiser that skips unchanged tables also helps. This is how to proceed:

Fix the cause. Analyse the system log, dumps and job log and, above all, resolve database problems. Otherwise the restart will terminate at the same point again.
Check running processes. Under the active processes in SCC3 and in SM50 and SM66, make sure that nothing from the old run is still working.
Choose a restart or a new start. If the termination was not long ago, a restart with the same settings is the intended method. If work has been done in the source client in the meantime, consider a complete new start.
Check the result. After the run, check the overall status, failed tables and exit messages in SCC3. With the classic tools, tables with copy problems can be copied again selectively using the function for recopying errors.

The shorter a copy runs, the smaller the time window in which something can go wrong. How to shorten the runtime is shown in the article Speeding up a client copy.

Preventing errors: checklist before the start

Start a test run: the log shows the scope, the space required in MB and, for remote copies, incompatible tables. The space requirement is only an estimate.
With the new tools, estimate the client size beforehand with SCC_CLIENT_SIZE
For remote copies, compare the release and support package levels of source and target
With the new tools, start the copy from an uninvolved client, in the background or as a task list
Lock the source and target clients, set a system message in SM02 and check in SM04 who is still logged on
Plan parallel processes realistically: resource management may allocate fewer processes to the copy than configured
Never use the same client as the source of several copies or client transports at the same time

Work packages instead of starting from scratch

After a termination, the standard client copy resumes table by table. The table in progress is copied again, the exits run again, and the analysis is spread across SCC3, SM21, ST22 and SM37. With large tables and the full history, this can cost a lot of time in the downtime window.

The Data Refresh Operator splits export and import into atomic work packages. A run can be paused and resumed at this level. SHA-256 checksums and a manifest document the export, a simulation shows the scope in advance, and an audit trail records what happened. Because DRO only copies a time slice plus all dependent objects, the data volume is smaller from the outset.

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.

DRO replaces the client copy, not the system copy. Where the standard tools reach their limits is shown in the section Limits of the standard client copy.

Sources

SAP Help: Copy logs (SCC3, ABAP Platform)
SAP Help: Restarting Client Copy
SAP Help: Error Handling when copying and transporting clients (SAP NetWeaver 7.3)
SAP Learning: Client Copy and Client Transport Tools
SAP Community: New Client Copy Tool (Dominik Ofenloch, SAP)
SAP Note 22514: CC-INFO: Error analysis for client copy (SAP Support Portal, login required)

SCC3: reading client copy logs and fixing common errors