New Client Copy Tool
With SAP_BASIS 7.54 (SAP S/4HANA 1909), SAP delivers new client management tools based on new common architecture. They are a complete redesign of the previous client copy (transactions SCCL, SCC9, SCC5, …). The new tools replace the old client copy and also offer new functions. They are optimized for increased performance, process automation and stability. The log of the client copy has also been completely revised and is now much more meaningful and easier to read, so that troubleshooting is much easier.
There are also new tools to compare clients and to determine the size of clients. With SAP_BASIS 7.55, the client export and client import have been expanded to include the option of exporting / importing so-called “snapshots”.
In this blog I’ll will introduce you to the following tools:
- New Local Client Copy
- New Remote Client Copy
- New Client Export and Import using Transports or Snapshots
- New Client Size Estimation Tool
- New Client Comparison
Why a new Client Copy Tool?
The client copy tool was originally developed in the 1990s. Since then, it has been further developed and maintained, but more and more fundamental problems came to light, especially with regard to new cloud processes, which required a new solution.
Therefore, at the end of 2017, the development of a new client copy tool began. With SAP_BASIS 7.54 (S/4HANA 1909), the new tool was delivered to customers for the first time in 2019. With SAP_BASIS 7.55 (S/4HANA 2020) the client export and the client import were also converted to the new architecture. With SAP_BASIS 7.55 Service Pack 1, transaction SCC1 is finally moved to the new architecture.
Compared to the old Client Copy Tool, the number of code statements went from over 25,000 to less than half with a significantly expanded range of functions such as the comparison tool. The new Client Copy Tool today has a unit test code coverage of over 94% over the entire coding.
The new tool solves conceptual problems of the old client copy and is characterized by increased stability compared to its predecessor.
Execution from a third Client. It is no longer necessary to start the client copy in the target client. Instead, this can now be started in a neutral third client (usually client 000). This increases efficiency and ensures that no users romp around in the target client during the client copy. The use of the user SAP * and restart of the application server to enable the user is no longer necessary.
HANA Optimization. The new tool is optimized for use with HANA. Our tests showed that the new Local Client Copy is about 10x faster than the old tool. The new Remote Copy was up to 5 times faster than the old tool in our tests. Instead of first loading the data onto the application server for a local copy, the data remains on the database during a local client copy by using an INSERT FROM SELECT statement.
Client Copy Optimizer. The new Client Copy Tool has implemented an optimizer for empty and unchanged tables. At the beginning of each client copy, the tool reads the HANA database statistics. It then checks whether a table in the database is completely empty in all clients. If this is the case, this table can be skipped in the delete and copy phase. The optimizer also checks whether a table has been changed since the last client copy on the database. If a table has not changed since the last client copy and the last client copy had the same source and target clients, this table can also be excluded from the delete and copy phase. This optimization is particularly useful for regular copies of test clients or in the event of an aborted client copy.
Handling of very large tables. In order to be able to deal with very large database tables, the Client Copy was enhanced to include a splitter algorithm. This splits very large database tables by generating WHERE conditions, which can then be copied by different processes in parallel. This ensures that the allocation limit in HANA and ABAP is not exceeded during the copy process. Furthermore, this algorithm increases the performance, since very large tables can be copied by several processes at the same time.
Class-based Exit Framework. Exits are now based on class interfaces and now run in an isolated environment. By using interfaces, there is now a clear interface between the Client Copy Tool and the exits. Running in an isolated environment ensures that a broken exit cannot crash the entire Client Copy Tool. With SAP_BASIS 756 exits are executed in parallel processes.
Old exits are still supported and executed via a wrapper exit. If you have an old exit, please contact SAP to receive support in implementing the new exit framework. You can find more information about exits in the client copy section.
Renovated Log. Finally, the client copy log (transaction SCC3) was completely revised and replaced by a clearer solution. The logs are shown in tabs. In addition to the well-known “Client View”, there is now a “Timeline View” and a view for each copy mode (local copy, remote copy, etc.). Different columns show the exit status, the table copy status and a general message status. This makes it possible to assess the success of a client copy at a glance. With SAP_BASIS 756, SCC3 supports the display of the client size based on the data collected by the Client Size Estimation Tool and the Client Copy Tool.
Tasklist Support. All of the new copy processes presented here now offer execution via task lists. The task lists can either be started from the corresponding transaction or directly using transaction STC01.
SAP delivers various client tools:
- Local Client Copy for a copy within the same system
- Remote Client Copy for a copy from another system to the local system
- Client Deletion for the deletion of a client
- Client Export and Client Import for the export and import of clients in transport requests or client snapshots (new feature)
- Copy from Transports (SCC1N) for copying Customizing Objects within the same system.
There are two types of client copies:
- Local Client Copy
The local client copy takes place within a system. The local client copy is started via transaction SCCLN.
- Remote Client Copy
The remote client copy copies data from an external system to another client in the target system using RFC. The process is always started from the target system. The remote client copy is started via transaction SCC9N.
Differences between Local and Remote Client Copy
The process flow of the local and remote client copy is basically the same. However, there are some special features to consider with the remote copy that do not occur with a local copy:
- Often the DDIC table definitions differ between the source and target systems due to different releases. Before each remote copy, the Client Copy Tool compares the DDIC table definitions and rules out incompatible tables. A table is e.g. incompatible if a field in the target system that is available in the source system is missing or has a shorter data type.
- While exits run in the analysis phase of a local copy in the target system and target client, the same phase is executed in the source client for a remote copy in the source system.
Client Copy Phases
The new client copy runs in four phases:
- Initialization Phase
In the first phase the tool initializes the list of all relevant tables, the client lock objects, the exit handler and many other smaller objects.
- Analysis Phase
In the second phase, all client copy exits are executed. Exits can exclude certain tables from the copy, request emptying or even explicitly include tables into the list of tables to be copied.
After all exits finished, the finalized list of tables to be deleted and copied is saved in the database. If the option to split tables is activated, very large database tables are analyzed for processing in parallel processes and broken down into smaller work packages.
- Delete and Copy Phase
The actual deletion and copying process takes place in this phase. First, all tables in the target client are deleted. The data is then copied from the source client to the target client. After all tables have been finished the source client gets unlocked.
- Post Processing Phase
Finally, the postprocessing exits run. Typically, these convert data or generate objects that are dependent on the data.
The New Client Copy has the following new features:
- Split Large Tables
- Copy Individual Tables
- Options to tolerate failed Exits and Tables
- Simultaneous execution of several client copies in the same system (from SAP_BASIS 756)
For more details please check section “Processing Options” in this blog.
The new client deletion is started via transaction SCC5N. It has the same phases as the client copy. The client can be deleted directly from the client list (accessible via transaction SCC4) using the “Delete from System Table T000” setting. In contrast to the old client deletion, the transaction must be started from another client and no longer from the client to be deleted.
Client Export and Import
The client export and client import process have also been completely revised. The basic idea of this process is to freeze a client on an “external” data carrier so that it can then be imported into another or several target systems. Exports enable a client to be frozen at a specific point in time.
The old Client Copy Tool previously only allowed exports using transport requests. With SAP_BASIS 755 there is now a further option for exporting to “Client Table Snapshots”. These are saved in the database of the exporting system and can be imported into the import system via an RFC connection. Compared to transport requests, the snapshots offer increased performance and greater flexibility in usability. The list of all snapshots can be viewed in transaction SCC3.
Please note: Exports that were carried out with the old tool are not compatible with the new tool and vice versa.
Copy Data from Transports
The transaction SCC1 was revised as the last client tool. The new transaction is released for customers from 2020 SP01.
Please note that the transaction was already delivered with SP00 but is not yet functional.
With the help of SCC1N it is possible to copy customizing objects recorded in transport requests to several target clients. This can be a local transport request or an imported transport request from another system.
In contrast to transaction SCC1, SCC1N can be executed in any client. The log has been completely revised analogous to the client copy log. Based on the feedback from internal customers, additional selection parameters were added.
Transaction SCC1N is a further development of the old transaction SCC1 and the old report RSCC_SCC1_BATCH. As a result, compared to the old SCC1, a large number of new parameters are available. If you want to copy transport requests that have not been released with SCC1N as in SCC1, proceed as follows:
- In the “Export / Import Time of the Transport Request” group, select the “Local Import / Update Date” radio button.
- If it is a mandatory field, enter a date that is far in the past in the “Export / Import Date” field.
You can find further information about SCC1N in my SCC1N blog post.
A new product is delivered with the comparison tool. It allows the comparison of clients, client table snapshots or client templates in any combination. The Comparison Tool can be used to compare customizing or entire clients. The comparison tool is started using transaction SCC_COMPARE.
The Comparison Tool offers three comparison modes:
- Checksum Comparison. In this mode, the comparison tool selects the data of both comparison objects, creates a checksum and finally compares the checksums. In the case of different checksums, differences were found between the two objects. The checksum comparison is the fastest method for comparing two objects, but it does not offer any possibility to compare the data.
- Detailed Comparison. In this mode the comparison tool selects the data of both comparison objects and compares them line by line. The data records are divided into the following categories:
- Data that only exist in comparison object 1,
- Data that only exist in comparison object 2,
- Data with an identical key but different non-key field values and
- Data records that are completely identical.
- Store as Template Container. Like the Detailed Comparison. However, the comparison result is saved in a template container.
Note: Please note that the Comparison Tool is not designed to compare very large database tables and drill down into these tables. We only recommend a checksum comparison for these tables.
The Comparison Tool offers the selection of several data sources for selecting the tables to be compared:
- Profile. Please note that SAP does not deliver a comparison tool.
- Individual table list. You can compare any tables with one another. With a remote comparison, even client-independent tables can be compared with one another.
- Run Id. Tables from a previously executed client copy.
After a successful comparison run, you can view the result on the next screen or on tab “Comparison” of transaction SCC3. You can see the result of the comparison on the “Compared Tables” tab. By double-clicking on the table name, you can drill down to the compared data and check the differences in detail.
Client Size Estimation
The Client Size Estimation Tool allows you to estimate the size of individual tables or an entire client. The tool calculates the client’s disk size using the following formula:
Table Size = Table Disk Size on the database / Total Number of table rows * Number of rows in the examined client
The actual data in the client is not considered here. HANA internal compression is not considered here as well. In the case of tables with fields of dynamic length, the algorithm can therefore only offer an orientation value.
The Client Size Estimation Tool is started using transaction SCC_CLIENT_SIZE.
As of SAP_BASIS 756, the Client Size Estimation Tool runs automatically with every client copy. The size of all clients can then be checked in transaction SCC3.
Client Copy Log
The protocol transaction SCC3 was completely renovated. The transaction is now completely tab-based. Logs are now stored in the database instead of the file system.
While a client copy is running you will always find a summary of the current status of the client copy on the first tab. This shows you information about the current running process, the source and target clients and the progress of deletion and copying.
Otherwise you will find an overview of all clients in the system on the first tab. With a double click you can select a client in order to have a closer look at all processes carried out in this client. With this click you will automatically be directed to the second tab.
The so-called “Timeline View” is new. On this tab you can see all the processes carried out by the tool in descending chronological order.
This is followed by several tabs with detailed views for the local client copy, the remote client copy, client deletions, client export, client import, transport request copies, client comparison and finally the client table snapshots and client template containers.
A double click takes you from the overview list to the detailed view of a log. On the first tab “Log Header” you can see a general overview of the current mode, the selected profile, the clients concerned, the exit status and the process status.
Here is an overview of the most important tabs:
- Log Header. Overview of the current mode, the selected profile, the clients concerned, the exit status and the process status.
- Options. List of the settings made on the selection screen.
- Table statistics. Overview of the number of emptied and copied tables and the number of deleted and copied data records. In addition, you can see the number of skipped tables on the tab because they were either empty on the database or were already copied from a previous client copy.
- General Messages. General messages returned by the Client Copy Tool.
- Exit Messages. Messages issued by exits.
- Processed tables. Overview of all tables processed by the Client Copy Tool. The current progress of the copying process during a client copy can also be tracked on this tab.
- Included/Excluded Tables. List of all tables integrated or excluded by the Client Copy Tool or by exits. If a table was copied or not copied, you can find out the reason here. In the case of remote copies, you will also see all tables on this tab that cannot be copied due to incompatible DDIC structures.
- Disk Space. Estimation of the deleted and copied data volume (see also under Client Size Estimation Tool).
- Runtime. Exact listing of the runtime of the individual client copy phases. This tab is particularly useful for performance analysis.
- Exit Execution. List of all executed exit methods. Each exit returns a status of its successful execution. The runtime of each exit is logged on this tab.
- Exit Definition. List of exit definitions as they were valid at the time the process was executed.
- Segmenter. List of tables examined by the segmenter for their division into intervals. The tab provides more information about the runtime of the segmenter and the number of intervals generated.
- Packages. Tables are always processed in blocks in packets. At the end of the processing of a packet, a COMMIT WORK takes place. Depending on the size of the tables in a package, it can contain between one and a thousand tables. Packages are the basis of parallelization because a package of tables is always locked and processed by a parallel process. On this tab you can see the list of all packages and their current processing status.
The transaction SCC3_ADMIN was published with SAP_BASIS 755 SP01. In contrast to SCC3, SCC3_ADMIN offers further functions for deleting logs, snapshots and containers.
Deletion of old Logs
Especially in systems with many recurring client copies, I recommend regular cleaning up of the log tables, as the log tables can become very large.
Since several data records are written to the database for each table copied by the Client Copy Tool, we recommend deleting old logs that are no longer required at regular intervals. With SAP_BASIS 755, transaction SCC3 has been expanded to include a delete function for client copy logs. For this purpose, a delete button has been integrated into the table on the “Timeline View” tab.
With release SAP_BASIS 755 Service Pack 1, this function is moved to transaction SCC3_ADMIN. This ensures that transaction SCC3 remains a read-only transaction.
Using the Log Cleanup Tool is more convenient than deleting individual logs. This can be called up in SCC3_ADMIN via the menu item “Goto” -> “Log Cleanup”. The tool enables the deletion of logs older than <n> days, whereby a minimum number of the last logs can be kept per client. The Log Cleanup Tool can also be started from the SAP_CLIENT_LOG_CLEANUP task list.
Deletion of Snapshots/Container
Snaphots and containers can be deleted on the “Client Table Snapshot” or “Client Template Container” tab using the corresponding toolbar button. There is also the SAP_CLIENT_CONTAINER_DELETE task list for the regular deletion of old objects. This can be started using transaction STC01.
Client Table Snapshots
With SAP_BASIS 755, SAP delivers client table snapshots and client template containers for the first time. Client table snapshots are local objects that are stored in tables of delivery class “L” (temporary data).
What are snapshots?
Snapshots are based on the Remote Client Copy table copying algorithm and allow any database table to be backed up. A snapshot can have any name and store any number of tables. The data of each individual table is stored as a serialized RAWSTRING in several database tables.
With the help of a checksum on the serialized data, the data of each table is stored centrally once across all snapshots. With a regular backup of an entire client, only the delta between two backups would take up additional storage space, since an identical checksum would only save the same data once under the same key (checksum) with two or more snapshots.
Snapshots are especially relevant for client export and client import. You can export an entire client or individual database tables to a snapshot using the Client Export Tool (SCC8N). Until now, the Client Export Tool could only export into Transport Requests.
In contrast to the transport request, snapshots have several advantages. This makes them easier to use because they are stored in the system’s database and not in the application server’s file system. Containers can be imported into other systems via an RFC connection (similar to Remote Client Copy). Containers are saved with optimized storage space. In addition, creating and importing a snapshot takes less than half the time than using transport requests.
This makes containers particularly suitable as an alternative to client export and import with transport requests and for freezing test clients that can be restored over and over again.
With the help of the comparison tool it is possible to compare the data of a snapshot with the current data in the client.
The Client Copy Tools come with multiple processing options:
- Test Mode. The program logic of the client copy is completely performed, without writing or deleting in the database, so the behavior of a client copy is simulated. A complete log is created (display with transaction SCC3).
- Lock Source Client. Locks the Source Client while performing a Client Copy.
In case this option is enabled the client copy tool locks the source client for users. Users still logged on will not be thrown out of the client but logon to the client is no longer possible. To ensure data consistency we strongly recommend to keep this option always enabled.
- Tolerate Failed Exits. Ignore failed Client Copy Application Exits while performing a client copy.
In case this option is enabled failed exits will not cancel the client copy process.
- Tolerate Failed Tables. Ignores Table Deletion-/Copy Errors.
In case this option is enabled failed table deletion-/copy-operations will not cancel the client copy process. All other tables will be processed.
- Use Exclusive Locks. Use of exclusive database table locks.
In case this option is enabled the client copy tool sets an exclusive lock on each table being copied. This reduces the memory footprint in the database and speeds up the database operation. As long as the table is locked exclusively any other tool cannot update the database table. Therefore, we recommend disabling this option in case the system is still used by other users while performing the client copy.
- Split Large Tables. Split Large Tables while performing a client copy.
In case this option is enabled the client copy splits up large tables into smaller units for performing the copy-operation in parallel processes. This avoids that the database runs out of memory and enables the client copy tool to perform copy-operations in parallel processes.
It is recommended to enable this option by default.
This option is permanently activated as of SAP_BASIS 756 and is therefore no longer available on the selection screen.
- Copy Incompatible Tables (RFC). Copies tables from remote systems, even if their structure is not identical.
Tables having different structures will be copied even in case of data loss. This applies for example for tables in case at least one column is only available in the source system but not in the target system. All incompatible Tables which will be copied anyhow are documented in the client copy protocol.
- If this option is disabled: Below is the rule list for a table to be marked “INCOMPATIBLE” by the client copy tool.
- The table must be present in both source and target system.
- If the table exists in both systems, then the key fields should be the same.
- The field list in both systems should be the same, however the position of the fields can be different.
- The data type of all the fields must be the same.
- The length of the fields must not be shorter in the target system. It can be greater or same length.
- If this option is enabled: The tables not falling in the below rule list will be marked “INCOMPATIBLE” and will be skipped/excluded from copy.
- The table must be present in both source and target system.
- If the table exists in both systems, then the key fields should be the same.
- The field list can differ. That is, missing fields are ignored, and matching field data will be copied
- The data type of the matching fields must be the same
- The length of the fields must not be shorter in the target system. It can be greater or same length.
- Automated Import Postprocessing. Executes the import post-processing (transaction SCC7N) automatically immediately after an exported client got imported. If activated, you no longer need to manually call transaction SCC7N after importing an exported client. This option is only available for Client Export to a Transport Request.
- Release Transport Requests on Client Export. Releases the transport requests at the end of the export process. The exported Transport Requests will be released immediately as part of the client export process.This option is only available for Client Export to a Transport Request.
- Use Mode Vector/All Languages. Use Export Option LSM-Mode = Vector and export all languages on transport release.This option is only available for Client Export to a Transport Request.
Overview of Transaction Codes and Tasklists
|Process/Tasks||Old Transaction||New Transaction||Tasklist||Released with|
|Local Client Copy||SCCL||SCCLN||SAP_CLIENT_COPY_LOCAL||SAP_BASIS 754 SP00|
|Remote Client Copy||SCC9||SCC9N||SAP_CLIENT_COPY_REMOTE||SAP_BASIS 754 SP01|
|Client Deletion||SCC5||SCC5N||SAP_CLIENT_DELETION||SAP_BASIS 754 SP00|
|Client Export||SCC8||SCC8N||SAP_CLIENT_EXPORT||SAP_BASIS 754 SP02|
|Client Import||SCC7||SCC7N||SAP_CLIENT_IMPORT_POSTPROCESSING||SAP_BASIS 754 SP02|
|Client Copy Log||SCC3||SCC3||n/a||SAP_BASIS 754 SP01|
|Client Copy – Special Selection||SCC1||SCC1N||SAP_CLIENT_COPY_BY_TRANSPORT||SAP_BASIS 755 SP01|
|Comparison Tool||N/A||SCC_COMPARE||SAP_CLIENT_COMPARISON||SAP_BASIS 754 SP03|
|Client Size Determination||N/A||SCC_CLIENT_SIZE||–||SAP_BASIS 754 SP00|
New Authorization Checks
Please note that with the new Client Copy Tool, new authorization objects have also been introduced. See the main note 2962811 for more information.
Client Copy Main Note: 2962811
SAP Help Portal: Client Copy and Transport
Very Informative Blog ! Thanks for sharing.
Nice, thanks or sharing!
Great job, thanks for sharing
Nice document .
Thanks for your blog entry. Actually there is something about client copies that I never managed to clarify: Will every copy profile (except SAP_USER) empty all of the target client before the import/copy starts?
To find answers I checked some 2020 SAP course material and the describing picture explains, that client itself consists of “application data”, “client dependent customizing” and “user master data”. Also I can find the statement: “user master data is only deleted in the target system if a profile with user master data is copied.” So here is the first exception.
In a official SAP administration book I can read “Except SAP_USER: before the copy process starts, customizing and application data in the target client will be deleted.” Just to make sure: I guess they refer to client dependent customizing? To my understanding most of the clients content will actually be deleted because the only thing left here is “user master data”. What do you say?
This topic is of interest to me, since a customer came up and asked if there is a way to copy only customizing to from one client to another withour overwriting anything else.
Thanks and regards
unfortunately we don't have any profile available which copies only RAW-data customizing. In case you use SAP_CUST profile all application data will be deleted. Of course only client-dependent data will be cleared by the profile.
thanks again for your quick reply 🙂 Sorry for asking this again: First, I understand that no repository or client independent customizing will be deleted while doing a client copy. But what about the data that is contained in the client. To cite it from the SAP course material:
As far as I understand from the information in the book there is only these three parts?
These three objects are the most important objects copied by the client copy tool.
But there are even some more. Explaining them all would be a separate blog post (Maybe that's a good idea). Please check out database table CCPROF to see a overview of all profiles and attributes controlled by the profiles.
A great article. Thanks Dominik Ofenloch
One question. Is new tcode SCC_CLIENT_SIZE different from old age program RSSPACECHECK in determining the client's size?
Thank you very much for your feedback!
Transaction SCC_CLIENT_SIZE is the successor of RSSPACECHECK. It is much faster as it uses the parallelization of the client copy tool.
Very informative blog with things explained so well!!
Thanks for this blog, very useful!
I can't find much information on SCC1N anywhere and hope you can clarify. When we import source customizing transport in the target DEV unit test client using SCC1N, it seems to create a new Copy Transport to do the job. The copy transport is also released and added automatically to the QAS import queue making it all very confusing. Is this the intended mechanism of the new SCC1N transaction?
thank you very much for your feedback!
About SCC1N: This transaction is already available with 755 SP00 but it is not recommended to use it in this release as it still comes with some issues you identified. Therefore, I haven't added details about that transaction to this blog yet. With SAP_BASIS 755 SP01 coming next year it will be generally available without any issues. Then I'll extend this blog with a new section explaining SCC1N in detail as well.
Thank you so much Dominik for taking the time to reply!
SCC1N now has been added.
Thank you. Are there any plans to release SAP Notes to correct SSC1N in 2020 SPS 00 please? We are doing a greenfield implementation and it is unlikely we will be upgrading to SPS 01 anytime soon.
Unfortunately not. Actually the tool has been completely refactored with SP01 and these changes are too complex for a note.
Good day Dominik Ofenloch , and hope you’re well.
We are using S/4HANA 2020 FPS01 with SAP_BASIS 755 0001.
However, the SCC1N tool seems to be not working as expected such as the objects were not copied over although SCC1N showed successfully completed.
There are some issues where the SCC1N unable to find the transport request. We have implemented the SAP NOTE 3026947 but the issue still persist.
May I know if you aware similar issues were reported by other customers or is it not recommended to use SCC1N in SAP_BASIS 755 0001 ?
I'm currently processing a similar issue from another customer. Please open an incident on component BC-CTS-CCO and provide details. We'll then come back to you asap.
We thank you for this information and its importance in the administration of the Client sap
Greetings and thanks
Thanks for the blog. Recently we have performed the client copy using new tool. We got several errors with post processing steps. Is there is any way that we can restart option in SCCLN (continue from the step where it got cancelled) . I didn't see much info on that one in restart option in new tool.
One more question do we need to run the BDLS after client copy. Can you please clarity on this one too because we can see some task in post processing related to BDLS in new tool (SCCLN)
in Post Processing only Exits are running. Please open an incident on the according exit components.
About restart-option: With the new tool this option is no longer available. Instead the new tool offers an optimizer which skips unchanged database tables. This ensures that a restart will be always faster than the failed run.
Providing a general restart option is unfortunately not possible. This would be risky as after cancellation the 1) source and target client gets unlocked and 2) we don't know whether the failed exit can be simply "restarted".
About BDLS. Please open an incident to discuss your request with development team.
apart from “empty” checks for activity “display” with authority objects S_TC, S_TABU_RFC and S_TRANSPORT I cannot see any “REAL” authority check e.g. with target client in SCC1N. But that would be necessary for us to regulate which user can execute which activities.
Otherwise thanks for the informations about this new tool.
unfortunately this is a gap. In comparison to old SCC1N the new tool can be executed in any client for any other client. Unfortunately we missed extending the authorization framework. We already have new auth checks in backlog and we'll them in the next releases.
First of all: thank you for designing and developing this new client tool group. You added features and functionalities I missed since long time ago.
I met a bit disturbing behavior in the new SCC3: on the 'Active Remote Process' tab there are 13 entries, with red sign at the Processing Status.
25.06.21 Dynamic List Display 1
| Option |Value |
| Mode |Local Copy |
| Run Id |ACTIVE_RFC |
| Test Mode |Off |
| Profile | |
| Profile Description| |
| Source Client | |
| Target Client | |
| Runtime |0 seconds |
| Processing Status | |
| Created By | |
| Created On |00.00.0000 00:00:00 CET|
| Changed By | |
| Changed On |00.00.0000 00:00:00 CET|
I can't find any reference to this. Can you please tell me how can I remove it?
Thanks in advance:
It seems a cancelled remote copy log record hasn't been cleanup properly in the source system. Please check table CCCFLOWV2 for the record having timestamp ACTIVE_RFC or open an incident on BC-CTS-CCO.
We also have these entries in our S4/HANA 2020 FPS systems (freshly installed with S/4HANA FPS 01 or upgraded from S4/HANA 1909 -> S/4HANA FPS 01) ,
I checked CCCFLOWV2 in these systems and found only older timestamps and in 1 system table CCCFLOWV2 was empty. For me it looks like these entries in SCC3 are "normal" and I ignore them.
I have tried the new Copy Transaction SCCLN in S4/HANA 2020 FPS00 but we had errors in user exits: authorization errors, missing RFCs etc. so meanwhile we have continued to use the old transaction SCCL.
these record belong to remote client copies started in other systems. They should not be there in case there is no active client copy running or it was never started.
Also in case of the user authorization problems with new tool:
I kindly ask you to open incidents on BC-CTS-CCO. Even when this is just a minor issue. Your reported problems will help us fixing the these issues and provide solutions to other customers facing same problem.
We haven't used remote clientcopy in most of the systems.
In our newest SAP system XXX, which I built up freshly shortly with sapinst+SUM (sapinst with stackfile)
I could imagine that the entry was already included in the database export files from SAP, which is implemented, when installing S/4HANA FPS01
(SUM uses S4CORE105_INST_EXPORT_<nr>.zip files and then SUM is doing a restore of a hana database backup at SAP as one could see in sapinst.logs and
Maybe you sapinst collegues know from which internal SAP-system the backup was done...
I would think that the SCC3 entry is ignorable....
BTW: There are also some entries in hana database which are not optimal in the database export from SAP and have to be corrected manually from each customer (2116157 - FAQ: SAP HANA Consistency Checks and Corruptions - SAP ONE Support Launchpad after installation with DB Backup from SAP ('check_table_container_no_load'
Regarding the new authorizations I have contacted our security guys to check note 2962811 and add all authorizations to be prepared. But sometimes clientcopies are time critical, so sometimes we don't have time to test new functionalities, wait for customer message answer etc. But I am sure we'll try the new SCCLN some day again...
The entry in SCC3 can be ignored for sure. It points to a bug in transaction SCC3. Fixing this shouldn't be a big deal. A further remote diagnosis is hardly possible. Therefore I would like to encourage anyone raising incidents on BC-CTS-CCO
Good blog. Is it possible to use this tool to reduce a data-set while doing a remote client copy? i.e. a full copy from a production sized system to a lower sized non-prod system while retaining only the Customizing and Master data (And i'm referring to the application master data and not user master data)
Please check whether different client copy profiles as SAP_CUST fit to your requirement.
Nice blog Dominik,
I have an S4H 1909 FP2, SAP_BASIS 754 SP02
I've exported a client via SCC8N to a container. Then I've imported successfully in a remote system via the SCC7N, indeed there is a good performance improvement compared against the old tools.
But I haven't found information how to monitor or delete a container.
Is there any HANA view or ABAP t-code for this purpose?
Also, as per SAP note 2962811 the "snapshot" feature was released on 755 SP00 (S4H 2020), so I'm not sure if the container option in my 754 system is the same "snapshot" mentioned here. Could you clarify?
please check in transaction SCC3 for a delete toolbar button. In case it is not available this feature might not yet be available in your release. In newer releases you can delete containers using transaction SCC3 or SCC3_ADMIN (newest release).
But you can easily delete the containers manually by clearing the database tables CCTABCONTAINER, CCTABCONTHEADER, CCTABCONTSLDATA and CCTABCONTSLICE.
These tables can be completely truncated as they are used for storing containers only.
I had access to an S4H 2020 FP2 SAP_BASIS 755 SP2 and neither SCC3 nor SCC3_ADMIN has a button/option, I will check when have access to new releases.
In the meantime I'm going to proceed manually truncating the tables as per your advice.
For want of acheiving security, the good and easy features of SAP are getting washed away.
SCCLN logs are either not detailed or like finding a missing treasure. Please when SAP develops new functionality , why cant they keep simple and maintian the structure.
Second example , Often you see help links, showing "page not found " error.
Third example: the documentation is lacking , making us to go to SAP notes or raise an incident.
please feel free to provide me detailed feedback on what can be improved in the new client copy tool and log. I'm open for feedback and I'm giving my best to make the new client copy tool the best client copy tool SAP ever had.
I have tried doing client copy on newly installed system S/4 HANA 2020 from 000 to say 100 client using sccln and execute as a task list. It's sad to say it fails 100% in next few seconds and unfortunately doesnot say anything in the logs of the sccln scree, we need to use old school way of using Scc3 to find issue with MDG_TR_WA, FINB_TR DEST etc.
Now is this tool mature enough to addess the basics of the above settings, if yes , could you be generous to please shed some light as to how to address this using SCCLN tool itself?
Also appreciate if you can share a blog or update sap help manual on how it is done with this tool on S4HANA 2020?
I forgot to say new client created has restriction to use DDIC manually created to avoid landing auth issues , saying SAP_ALL is not active, sorry to say it got complex due to the security feature and we forced to check KBA or raise incidents.
I'm not aware of any DDIC restrictions when using the client copy tool.
In case the tool fails within a few seconds most probably this is related to exits. Details should be provided in SCC3. The client copy tasklist doesn't show all information as this would simply blow up the tasklist log with thousands of messages. Remote Support on this blog is hardly possible. Please open an incident on BC-CTS-CCO and share details.
Thanks for your understanding.
Thank you for the detailed blog.
We started using SCC1N t-code to copy customizing changes from one client to another. While doing so we see that it creates a new transport, copies objects from the source system, and then imports them into the target client. This is a big change to the old way. In the old way, it was not creating new transport.
Are you aware if there is a way by which we can skip new transport creation and get objects copies to another client as it was happening with the old tool?
I assume you're still on 2020 Service Pack 0 or lower. The new transaction SCC1N is released for customers from 2020 SP01. With SP01 we stopped creating the transport requests and copy the objects immediately.
you mention in the section local vs remote client copy:
"Often the DDIC table definitions differ between the source and target systems due to different releases. Before each remote copy, the Client Copy Tool compares the DDIC table definitions and rules out incompatible tables."
I wonder if this new tool allows the client copy between different SAP releases. The classic tools did not. And of course I'm well aware of the issues between different releases, so that in fact I never wondered that such copies were not possible. But now I do wonder .... In fact I'm in the need to client copy between different systems, namely from S4HANA 2020 to S4HANA 2021 (so pretty closely related systems but of course different). The options are now to install a new 2020 and do the client copy and subsequently an upgrade to 2021. Or - theoretically less work - install a new 2021 and do the client copy from 2020 to the new 2021. Would be great. But rather than "experimenting" I'd like to get your take on that.
Thank you for your insights 🙂
you are right. Officially we do not recommend and we do not support cross-release client copies. Nevertheless, in the past many customers performed such cross-release-client-copies. For sandbox systems this can be acceptable. But I do not recommend it.
The correct approach is installing a second 2020 machine, performing the remote client copy and then you can update the target system to 2021 release.
Especially when performing client copies from 2020 to 2021 using new tool it might get tricky: Many new exits were released with 2021 but not available in 2020. Furthermore, the client copy tool interfaces slightly changed from 2020 to 2021 release which might prevent client copies.
How to restrict the client export from 000 client. In our case a developer selected the TR but missed to update the client and executed the TR import using SCC1N. Data from 000 client was copied causing inconsistency.
TR is not present in 000 client, how the data movement happen?
Is there a way to restrict the 000 client copy. In old tool SCC1, we can restrict by changing the client setting in SCC4, but that restriction is not working in SCC1N. Could you please suggest how to avoid this?
as of today SCC1N has the following checks implemented:
1) Target Client must not be 000
2) Client Role must not be a protected role (Production/SAP Reference).
Therefore, from my point of view running SCC1N on client 000 shouldn't be possible at all.
Maybe you can share further details with me what happened to understand your scenario better.
Thanks and Best regards,
In SCC1N if source client is by mistake put as 000 it is wiping all the customization data. We have two place to maintain source client . In second source client field if 000 is mentioned it is leading to loss of all customization data.
We tested various option and found :-
Client protection setting in SCC4 works for SCC1 but not SCC1N.
There is no authorization object to prevent source client selection in SCC1N or SCC1
How can we ensure that in SCC1N people don't select 000 as source client.
once we restrict the client setting to mode 2 (protected), SCC1 import from source client 000 is disabled. But in t-code SCC1N this solution is not working. A developer by mistake selected 000 client instead of 200 and that cause company code data inconsistency in Dev environment. Not a major issue as this can be resolved with re-import. I want to know how to restrict import from client 000 to other productive clients for t-code SCC1N
I see the problem with client 000. But to be honest I'm not sure whether I can restrict running SCC1N using client 000 as source for all customers. But Girwar Meena identified a bug in the new tool for which we'll provide a note. I'll add a comment here as soon as the note is available.
Thank you Dominik Ofenloch . Appreciate your effort. SCC1N is great tool, I do not want to limit the tool usage because of 000 client import risk. Thank you for looking into this.
we were creating a client copy within a S/4-system some days ago using SCCLN as a tasklist-Job. Unfortunately the client copy was cancelled a couple times because of the table ACDOCA. After checking the work process traces we found the reason: "max run time exceeded" (see attached screenshot).
This is new to me. A client copy running as a background job can be cancelled because of max runtime? How come? And due to which circumstances will the rumtime be exceeded?
The first working approach to finalize the copy was to start another run after business time. Unfortunately this did not help us for further copies. In this case we raised the three different runtime parameters (see note 2918906) to a higher value.
I am still surprised that this parameter seems to be necessary for a client copy.
I assume that you are still on lower releases and/or service packs. In newer releases setting the max runtime parameter is no longer required.
thank you! Is there any note that has information on that topic? Is this an error/bug? And do we really need to raise the SPS or is there a single note we can apply?
Our current release is:
if target-client is under usage of CUA, (ZBV)
should it be disconnected from CUA first, before executing client-copy?
in old SCC9 you could choose
client in CUA and do not copy user data.
we tried to run SCC9N (remote copy) but got abord because of low memory, but systems are configured in same size
sandbox-system 1,0 TB RAM-size for HDB, => copy to dev.system also 1,0 TB RAM-size for HDB,
but remote-client-copy died because of low-of-memory ???
how much more RAM has to be assigned to the target-system ?
unfortunately I cannot provide remote support to such complex topics as system sizing in this blog. Please open an incident to get support.
we increased the RAM size of the target system to 1,8 TB,
in RAM peak-usage we could see up to 1,315 TB used during client-copy
total disk usage is 1,017 TB, but peak used RAM in client copy is 1,315 TB
one table (with shared objects) could not be copied because of locked user or locked client during client-copy,
so logon with user SAPSYS failed
Category Installation error
Runtime Errors SYSTEM_SHMCONSTR_LOGON_FAILED
SCC9N - has obviously a bug,
user data (SU01) is damaged after remote client copy,
trying to delete a user in SU01 causing in a DUMP and abort.
(e.g. in S/4Hana-2020-03) maybe in other version also?
there is a solution to this issue in sapnote 2293227, run that report as appended https://launchpad.support.sap.com/#/notes/2293227
report fix that issue => Z_OSSNOTE_2293227_ADRVP_USR21
Please report problems related to user-addresses to support component BC-SRV-ADR.
Testing of export to container is about 4 times faster than export to transport and container size is half of transport size.
But still looking for information how to monitor or delete a container in case of release lower than 755.
SCC3_ADMIN is not available for 754. I will be nice to have program or function to delete container, rather than truncating tables.
Thank you very much for your great feedback.
In SAP_BASIS 754 you can use the following report to delete containers. It has been created upon your request and it is delivered with SAP Note 3314622 and will be part of future service packs as well (RS_SCCR_CONTAINER_CLEANUP). In higher releases please use transaction SCC3_ADMIN for container deletion.
than you very much for prompt resolution. It feels much better cleaning up with repot.
I have the clients 000 and 111 in our Q-system:
I created the new client 2222 (SCCLN ) with the option Use-Profile SAP_USER from 111 to new client 222
After that I'll do one a Remote Client Copy from our P-System to then new client 222 in Q-System with the option Use-Profile SAP_APPX.
Everything is green and there are no errors in the logs.
If I do a SU01 on the user I get a error that says the "Company address" is inconsistent and the table USCOMPANY is empty in client 222.
What am I doing wrong here and why is the table empty?
SAP_BASIS 756 0003 SAPK-75603INSAPBASIS SAP Basis Component.
I still have one more question:
Will there be a consistent copy at some point in the future without source tenants being blocked?
Could you please answer these questions. Thank you very much!
If I understood you correct you used first 1) SAP_USER and then 2) SAP_APPX? This will overwrite the users in the target client. In case addresses are getting corrupt this must be addressed to the address management team. Please open an incident on the address component.
Consistent Client Copies require that the Source Client remains unchanged during copyphase to avoid that data gets only copied partially. To avoid this a lock in the source client is required.
I did tests today with Client Export and SAP_USER:
1.) Transport was created (Client Export and SAP_USER)
2.) Remote copy with SAP_APPX performed.
3:) Import transport from 1.)
after that still SU01 inconsistent
Is it normal that this field in TR empty is see attachment marked red?
Your execution order is correct. The inconsistency in USCOMPANY should not be. This must be analysed by address team. Regarding the Transport request I cannot answer your question as I am no transport expert. Client export to transport simply writes all tables to the Transport request piecelist and triggers then an export. That's all I do and know here.
it is a normal behavior when I exported the User with SCC8N (SAP_USER).
After that I did the remote client copy with SCC9N
and then with the imports SCC7N I get this error see attachment.
after import the User Transport Request you have to run SCC7N immediately. SCC9N will overwrite the imported tables.
we are running SCC9N and after this we import the user with SCC7N and now we get the error you see above.
I cannot provide full support on a blog post. Please open an incident on BC-CTS-CCO.