You can use the client copy to create, for example the following clients:
· new clients from the SAP reference client 000 during initial installation of an SAP system.
· training clients
· demo clients
· test clients
· production clients
The source client can be in the same or another system.
You can copy selected parts of an existing client into another client, e.g. the user master data with the copy profile SAP_USER, with the client copy tools.
You are strongly advised to use the profile SAP_CUST to copy client 000 to create your first client because the consistency of the application data in the SAP delivery client is not guaranteed.
You are no longer required to transport clients before you can copy them between systems. You can make a remote copy instead. SAP will continue to support the transport function.
You can create a new client in the client maintenance (transaction SCC4). You need a user with sufficient authorization in the target client, for the client copy.
The newly-created client contains the initial benutzer SAP* with the password PASS, which you can use to copy a client.
The user SAP* is inactive by default in a new client. To activate the user SAP*, set the profile parameter login/no_automatic_user_sapstar to 0, and restart the application server.
You do not need to delete an existing client before the copy.
Copying clients requires a large amount of system resources. To avoid premature termination due to bottlenecks, you should ensure that enough resources are available by considering the following points:
· Database storage space
Perform a test run before copying a client. The total of copied and deleted data in kB is at the end of the log file.
For ORACLE, INFORMIX, ADABAS and DB2/CS databases, you can check the test run log to see whether there is sufficient database space available.
Storage requirements can only be estimated, because space already allocated, but not yet used, is not taken into account. A client without application data needs approximately 500 MB in the database. In most databases, space made free by deleting data is only available after a reorganization.
For pool tables, the estimate is very imprecise, because their extent size is very large. You must assume that a new extent is required for each pool table, which must be added to the estimate.
Copying a client can take several hours or even days. Users or background processes in clients other than the source or target clients, can make the time longer. For example, locks in a third client in the same system can obstruct the processing of individual objects. You can technically work in the system while client copy is running, but you are strongly advised not to do so, or only in exceptional cases.
You may have to increase the standard timeout value for these processes if you are working in the foreground with slow databases, large clients or clients with a lot of users:
i. To increase the default timeout value, call the transaction Maintain Profile Parameters (RZ 11).
ii. Specify the profile parameter rdisp/max_wprun_time.
iii. Choose Display.
iv. Choose Change Value.
v. Specify a new value for the profile parameter.
We recommend a value of 2000 seconds.
If you use parallel processes, dialog processes are used even if the job is scheduled in the background. The standard timeout value is usually sufficient. If the database is loaded by additional processes, it can be advisable to increase the profile parameter.
· System load
Copying or transporting a client can take a long time because large amounts of data are moved. One or more dialog processes are occupied for this time. The database interface is heavily loaded.
· You must ensure that no users logon to the system during the copy. For technical reasons, only the target client is locked. If, e.g. the lock is not reset after a copy is cancelled, you can reset it by calling the transaction SCC3 in any client.
Users who are in the target client before the start of the copy cannot be locked automatically, so you must ensure that they leave the system.
· The source and target clients should both be additionally protected by a system message (SM02). Monitor compliance in both clients (e.g. in SM04)
· You should not work in the source client either during the copy.
· You cannot access archived data in the target client if the target client number is not the same as the source client number.
· Change documents (tables CDHDR, PCDHDR, CDPOS and PCDPOS): User administration change documents and generic logs (application log tables BAL*) are not copied.