The utility report RSCLICOP is an ABAP report, which copies the entireCustomizing environment from a source client to the target client. Thisinvolves:
- The copying of all client-dependent tables from a source client (to be
specified) to the current logon client.
- The execution of certain exit programs of the application, by means of
which logical dependencies between tables copied on the one hand andobjects generated on the other (e.g. ABAP programs) are eliminated.
Furthermore there are application-logical special functions for theconsistent basic setting of the new client. Example: Resetting ofnumber range statuses in the entire SAP application.
- Determining and copying the matchcodes that belong to the tables that
have been copied.
The usual client copy procedure up to Release 2.0, with RSCLIC01 orRSCLIC02 and R3trans as the physical copy tool, only included the firstfunctionality listed above. In addition, online functionality waslimited to the creation of a command file. You had to initiate physicalcopying by calling R3trans at UNIX level.
We recommend that you no longer use RSCLIC01/-02. As we have alreadysaid, its entire copy functionality is contained in RSCLICOP.Furthermore, there are additional essential functions integrated inRSCLICOP for maintaining consistency. In addition to a well laid outcopy log, RSCLICOP offers support for system administration, asexplained later in this documentation.
Copying all client-dependent tables means copying well over 2000tables, a data volume of between 50 and 100 Megabytes. We thereforeadvise you not to run this report online. It is better to start it asbackground processing. You can do this either via the menu function'Execute in background' in the report request screen, or you can createa variant for the copy scenario you require and schedule the report forbackground processing.
Estimation of time taken by an online run: A client copy run online(powerful computer, low load) with the option "without HR tables" tookalmost 3 hours to set up around 3000 tables for a new client.
When executing online, also note that, at the end of the run, logmessages are output by some of the exit programs mentioned above. Youcan basically ignore them (they are suppressed in Release 3.0).Activate the "Back" function each time ("arrow to the left" icon) untilyou have completed entire processing.2. What are the requirements that must be fulfilled?
Copying is performed in the client to be set up. This client mustalready be known to the system via client table T000, for you to beable to log on for the first time. You usually log on to the new clientunder Super User SAP* and perform the client copy here. You can, if youwant, also copy the user masters of the source client, provided thatyou are authorized to do so by your user master. For more information,refer to the following section, as well as the documentation for theparameter "copy user master records also".
Because of possible damage resulting from improper use of the clientcopy tool in a system (client), authorization protection was set upbased on the following three authorizations.
As a basic requirement, the user performing the client copy must firsthave the authorizations to maintain client-independent tables(authorization S_TABU_CLI) and the contents of table CCCFLOW(authorization S_TABU_DIS). SAP* has these authorizations.
The first authorization was introduced with Release 2.1A. Only personsauthorized to make changes to table contents in all clients may copythe complete set of table contents from a source client to the currentclient. From Release 2.1A, this authorization is required by everyonewanting to maintain client-independent tables.
The second authorization required is for maintenance of table CCCFLOW.This table contains trace information on every client copy runperformed (display list with report RSCCPROT).
If you want to copy user master records from the source client, youmust also be authorized to maintain all user groups. User SAP* also hasthis authorization. An indivdual user will need an authorizationcorresponding to that of an "authorization administrator" andrepresented by the profile S_USER_ALL (see also the parameterdocumentation).
For a normal standard client copy, the current client must not containany application data. If the client existed beforehand, you must ensurethat all application data is first deleted. R3trans, for example,offers this function with ist 'client remove' function (see R3transdocumentation). For RSCLICOP "normal standard client copy" meansexecution mode 'A' (third parameter; A = "all", i.e. the entire dataenvironment of the source client).
The reason for this requirement is as follows: At the end of the clientcopy, number ranges statuses are reset in all applications. Thecontinued presence of application data can cause terminations in latertransactions due to "duplicate key" situations. What to do if you do not want to work under SAP*
If you do not want to work under SAP*, you must of course first create'proper' user masters. Required for this are the authorizations (=characteristics of the authorization objects) and profiles from thesource client, unless you want to set them individually in the newclient.
For this, there is report RSCLACOP ("Client copy for authorizations").This report lets you choose whether you only want to copy profiles andauthorizations from the source client, or the actual user masters aswell.
After running RSCLACOP for the authorization environment, we recommendthat you reset the buffer. Enter '/SYNC' in the OK Code on all otherapplication servers, from which the new client will be accessed. 3. Which tables are selected, and how is the copy performed ?
Tables are slected solely on the basis of delivery classes, as definedby the SAP applications department. Whether a table belongs to theCustomizing environment is determined by its class. Roughly speaking,all classes belong to it with the exceptions of L ("empty": Should besupplied empty in a new system environment ), A ("application table")und W (system table written internally, technical contents only). Foran explanation of the remaining classes relevant to Customizing, referto point 9 "What is a Customizing-relevant table?" at the end of thisdocumentation. How the copy is performed
For performance reasons, when a table is copied, the entire contents ofthe source client are first loaded into main memory, and then the tablecontents of the target client are set up using the efficient arrayinsert. This method allows tables of up to several Megabytes in size tobe copied efficiently. However, if a table is clearly more than 10 MBin size, you can expect problems (at least on small systems). You can,by the way, count the table entries using report RDDANATB: Here, youshould restrict the table name generically as far as possible (due toruntime).
If the table already exists in the logon client, the table comparisononly takes into account the entries that are different in both tables.The efficient array update and array delete are also here for thedatabase. In each case, the table has the same status as in the sourceclient after copying.
If, for any reason, the table has already been copied, this isrecognized during the comparison and no (unnecessary) DB update isperformed. You can easily recognize these situations in the log: Tableentries are identified, but no insert, update or delete was performed(i.e. all entries are identical with those in the source client).
This functionality can also be used for a subsequent client comparison,in which RSCLICOP is run in test mode (i.e. without a DB update) forthe client that has just been set up. 4. What are the log contents there for?
In addition to general details on the environment, table statistics arerecorded in the log. For each table, the following information isgiven:
- Delivery class
- Development class
- Number of entries it has in the source client
- Number of inserts required in the current client
- Number of updates (as above)
- Number of deletes (as above)
- Additional space required (in Bytes) for the table copied. The
additional memory is determined from the number of inserts that occur(multiplied by the length of an entry).
Finally some useful summary information is output, from which theadditional storage requirement can be derived. In particular, you aregiven the entire additional storage requirement of the client (inKilobytes), so that you can plan storage space if necessary. As before,the total number of inserts is taken into account. (To get an overviewof the table sizes in all clients, use report RDDANATB; Caution: Youcan expect long runtimes.)5. What to do if a run terminates
A very large set of data is moved during the client copy run, whichplaces great demands on the time limits and memory resources of thehost, and can frequently lead to terminations on machines with limitedcapacities. To reduce the load on computer capacities as far aspossible, and to enable online running, Commit is set after each tableto spare the size of the DB rollback segments. If there is a successionof many very small tables, Commit is withheld until a suitablethreshold value.
Despite these cautionary measures, RSCLICOP is prepared from the outsetas a long-running program for the restart. While running it sets "checkpoints" at suitable intervals, which allow a fast and precise restart.
In restart mode, RSCLICOP continues a terminated client copy from theplace where the termination occurred. For this purpose RSCLICOP writes"check points", which are stored as table entries in table CCCFLOW.Thus, table CCCFLOW has the following functions:
- Status details on the active run. This means that the run can be
monitored whether running online or in the background.
- Records for system administration. There are records for all the runs
performed. You can get a printout with report RSCCPROT.
- Restart info: The fields 'Status', 'Phase' und 'Table' identify the
point in processing where the restart is to begin.
Note that the next time you call RSCLICOP online after a terminatedrun, restart mode is automatically suggested. This is possible as thetrace table CCCFLOW is already analyzed before the parameter entryscreen. If this restart should also fail, a special note on there-termination appears in the log, pointing out what might be thepersistent source of error. You should eliminate this before your nextattempt.Troubleshooting tool: RSCCPROT
Report RSCCPROT offers a troubleshooting service. It documents thecheck point that was last written and gives an up-to-date list on thestatus of the copy. Here, the table that was last processed or the exitprogram that was last called (e.g. for post-handling generated ABAPprograms) are output. Cumulated statistics are also run. From here, youcan branch to the client copy log with the "Log" key. There are threelevels of detail for looking through the copy log.
RSCCPROT also offers a monitor function for a client copy that isrunning. In this way you can observe the progress of the copy run. Inthe RSCCPROT display, the status of an active copy run is documented as'P - processing ...'. If the run has terminated, there is the additionof 'terminated'.
Here we recommend that you take a look in the system log (transactionSM21) to find out the cause.
Then restart RSCLICOP in restart mode. If you call RSCLICOP online,restart mode is automatically suggested, together with theparameterization of the terminated run, and the restart can run asdescribed above. A pre-analysis phase of around 2 minutes is requiredto determine the point of restart. 6. What is the purpose of the test run?
Database updates are not performed during the test run. However, thelogic contained in the RSCLICOP client copy is processed completely(without DB update), and complete table statistics are output. Asdescribed above, RSCLICOP compares the contents of each table in thesource client with that in the target client.
Using the resulting statistics, you can find out which tables differ intheir contents from the source client, i.e. were changed. As the numberof non-identical entries is also shown, you can get an overview of theextent to which the table in the current client was changed.
Finally, a test run BEFORE the production run can be used to determinethe additional space requirement for the new client. This is determinedduring the run and is shown at the end of the log (in Kilobytes). 7. In what way can application data also be copied?
Selection of tables other than Customizing tables (this includesapplication tables) is via the two parameters:
- "also user masters..."
- "also application data ..."
Can you copy application-relevant data in addition to Customizing data?
When you choose user masters, all the user authorizations created inthe source client are copied to the current client. If you do not usethis service, you have to create the users in the current client.Authorizations (characteristics of authorization objects) are copied ineach case, as this data is part of the Customizing environment and isincluded in a normal standard table copy.
It makes sense to copy application data during the client copy, if theapplication data contained in the source environment contains thefollowing properties:
- quality (useful test data)
- quantity (data sets are not too large),
and it is to be set up as the basis in the target client.
This can considerably simplify the currently arduous task of creating arepresentative test environment.
In this case, you must initialize the remaining data for compatibilityreasons with number ranges.
Note: If you want to make a complete change from one client to another,RSCLICOP is not at all suitable for copying the application data of anentire production system.
Reason: For performance reasons, when a table is copied, the entirecontents of the source client are loaded into main memory, in order toset up (from there) the target client with the efficient array insert.For volumes of data typical of a production client, this is of courseinconceivable, as main memories of the many Megabyte category are notavailable (even on powerful machines).
It is not possible to specifically select individual master datacomponent fields for copying e.g. cost center hierarchies in CO. Thiswill not be possible until Release 3.0.8. Specific (post) transporting of individual tables
In addition to RSCLICOP, two extra reports are available: RSCLTCOP("single table COPy") und RSCLCCOP ("client copy based on a commandfile, e.g. correction number"). Basically these reports work the sameway as RSCLICOP, but differ in interface functionality. Also, they donot produce any trace entries in table CCCFLOW described above. RSCLTCOP:
This report contains a "Tables" parameter, in which you entergenerically (e.g. also sorted) the names of the tables you wish tocopy. RSCLCCOP:
A special variant is data selection via a given command file (entry"C"). Example: The file via which you have recorded your Customizingactivities (see action point 'Transport' in your Customizingmaintenance menu). This lets you specify table entries maintained inthe Customizing client for transfer to another client. RSCLACOP
Copying of authorization data (profiles, authorizations, user masters)from the source client. To use this function, an authorizationcorresponding to the profile S_USER_ALL ("authorization administrator")is required. For information on using this function, refer to point 2above. 9. What is a 'Customizing-relevant table?'
As mentioned above, a table is selected on the basis of its deliveryclass. The significance of the delivery class is now described ingreater detail.
The delivery class determines the extent to which the contents of atable wholly or partly belong to the customer. Following on from thisis how the table prevents the overwriting of customer data in thecontext of an SAP Put, i.e. which of the following alternatives apply:
|