You want to use parallel processes for a client copy.

1. How do I use parallel processes?

2. How many parallel processes should I use?

3. Several clients must be copied into a system.Is it possible to run two copies in parallel?How do I get the shortest runtimes?

4. Why are no parallel processes used or why are less parallel processes used than required?

5. How can I terminate a copy with parallel processes?

6. Why are some processes in the process overview (transaction SM50) or in the Systemwide Work Process Overview (transaction SM66) not active or not displayed?

7. How many processes are used on the servers and which process has copied which table?

8. The copy was scheduled in the background.Why does the client copy use dialog processes?

9. The copy was scheduled on a specific server.Why are also processes active on other servers?

10. Why does a change of the RFC server group not affect a current copy?

11. Which data throughput can I can expect?

12. Do the settings for the parallel processes of the client copy also apply to the client transport?

1. You can select an existing RFC server group and the maximum number of processes (not counting the main process) via the "Parameter for parallel processes" button or the "Go to -> Parallel processes" menu option.

From there, you can also go to the RFC server group maintenance (transaction:Create an entry with the same name for each application server to be used.For more information, refer to the documentation (SAP Library) of the SAP Web Application Server under:

Computing Center Management System (BC-CCM) -> Background processing -> Parallel processing of jobs with asynchronous RFC -> Define RFC groups for parallel processing jobs

2. Two processes per available database CPU is a good guide value.

For a remote copy, we even recommend that you use three processes per target database CPU.Parallel processes are especially useful with remote copies as you can use more different resources (source/target database, source/target application server and network) simultaneously.This applies in particular if a conversion is required due to different character sets (code pages) or system formats (Little or Big Endian) where CPU consumption on the application server increases considerably.

3. You cannot use two copies from the same source client simultaneously. This may cause problems in the address management.

You can use two copies from different source clients simultaneously. However, we do not recommend this as the processes may lock each other.

Instead of executing several copies simultaneously, you should preferably schedule the copies one after the other and use parallel processes.

To avoid disorganization in the database, you should, if necessary, delete all target clients in advance.You should then reorganize the database and update the statistics.The clients are then structured with ascending client number.

We recommend that you proceed, for example, as follows:

1. Schedule the first copy in the clients with the smallest client number with a start of 10 minutes.

2. Determine the name of the background job via the SM37 transaction.

3. Schedule the second copy as successor of the first job and so on.

4. There are several possible causes:

• Parallel processes are only used during the actual copying phase.They are not used, however, during the analysis and postprocessing phases.

• The resource management only assigns a limited number of processes to the client copy.For more information, refer to the documentation (SAP Library) of the SAP Web Application Server in the "Automatic protection against capacity overload of resources" section of the following document:

Computing Center Management System (BC-CCM) -> Background processing -> Parallel processing of jobs with asynchronous RFC

• Towards the end of the copying phase, the number the processes is reduced as the worklist is divided but individual processes are still copying very large tables.

To avoid this scenario, a "SINGLECOPY" copy function was introduced as of WAS 6.10. Refer to note 446485 for more information.

5. The processes monitor each other and restart terminated processes. You can, therefore, not simply terminate the client copy by terminating the processes. You must inform the client copy in advance that you want to terminate the copy.

To terminate the copy, use the 'Cancel copy' button in the SCC3 transaction of the system log display.The processes auto-terminate once they have finished the current task or the copying of the current table.After issuing the Cancel command via the log display, you can also terminate the processes manually (for example, via the process overview (transaction:

6. The relevant processes try to set a lock entry for a common resource (for example, for the log header in the CCCFLOW table or for the "CCLOG" file log).

If the first attempt fails because the resource is already used by another process, the system will repeat the action in intervals of one second until the relevant resource is released.While the system is waiting for the resources, the processes are not displayed.You can display the relevant lock entries via the lock management (transaction:

7. you can display it, for example, with the SE16 transaction. The PROCESS field contains the application server and the number of the process. The same information is also displayed in the file log of the copy at the beginning of the copying phase.

The information which table was copied by which process (STATUS = 'P') or which tables are contained in the worklist of the process (STATUS = 'A') is listed in the CCSELTAB table.

To monitor all current actions, you should preferably use the global work process overview (transaction:

8. Only the main process of the client copy can use a background process.The parallel processes are controlled via a RFC server group.RFC processes, however, are always dialog processes.

9. The servers specified in the RFC server group are only used for the additional parallel processes.They are not affected by the scheduling of the main process on a specific server.

10. The RFC server group is only analyzed once at the beginning of the copying phase.Changes, therefore, are only activated in a new copy or after a RESTART. You must, therefore, terminate the current copy after step 5 and execute a RESTART if you want to change the distribution of the processes.

11. If the target client is empty and the source database in good shape (updated statistics, little disorganization), you can expect a throughput of approximately 500MB to 1GB per hour and process on a modern database.That is, approximately 4GB to 8GB with 4 CPUs and 8 processes.

12. No. The client export (transaction:SCC8) only creates a transport request which then is exported by the tools of the tp/R3trans transport programs.The settings for the parallel processes of the client copy do not affect this process nor the postprocessing in the target client (transaction: