- Overview....Click here...
SAP Clients....Click here...
a client and setting up the client attributes....Click here...
control in transaction SE06....Click here...
Client from SAP....Click here...
COPY Procedures....Click here...
custom PROFILES to copy Clients....Click here...
COPY within a System....Click here...
COPY from one System to another....Click here...
a Client....Click here...
CLIENT Copy....Click here...
a CLIENT....Click here...
golden rules for CLIENT copy....Click here...
method for copying VARIANTS....Click here...
client is organizational and legal entity in the SAP system. All
the business management data is protected here because other clients
can not access them. The main objective of the client is to keep
the data isolated. The data in a client can be only visible within
that client; it can not be displayed or changed from another client.
In a physical SAP system there can be multiple clients. Each of
these clients can have different objective or each client represents
a unique work environment. In a development environment one client
can be used as sandbox client (developers learn how to configuration
using SAP environment), one can be used as prototype client (users
do the customizing according to the companys requirements
and testing) and another one can be used as the master development
and configuration client (where the final configuration is done).
A client has its own set of tables and user data. To know whether
a table is client dependant or independent you can search for a
field MANDT. The client dependant tables always include the client
field MANDT as a part of the primary key. There can
be multiple clients in each of the system of SAP system landscape
as we have already seen in chapter 5. It is better to understand
the customizing process in the CTS pipeline before designing a good
client strategy for the SAP systems. Customizing is a method in
the SAP R/3 system that helps the user to configure the functionality
from SAP, according to the customer requirements. When the SAP objects
are just used by only one client, we define them as client dependant
data. There are some objects as ABAP/4 programs, which are used
by all the clients in a SAP system. Those objects are called client
independent data. The functional changes resulting from customizing
can be client specific (client dependant) or general (client independent).
You must know the fact that client independent customizing can create
problems if the authorizations and the client strategy are not defined
properly. For example if you have three clients in a development
environment then the role of each client should be defined properly.
One of these three clients should be used for client independent
customizing and in other clients, users will not have the authority
to do any client independent configuration.
a standard installation, SAP delivers 000, 001 and 066 clients.
Client 000 is considered to be a SAP reference client and it should
not be changed or deleted at anytime from the system. After a SAP
system is installed, you can create other clients from 000 by using
the client copy procedure. For some important configuration
you have to logon to client 000. For example, if you want to configure
your CTS system then this client must be used. Client 000 also plays
a very important role in upgrade process. Every time you do upgrade
client dependant changes will be automatically upgraded in this
client and later on the changes can be copied to other clients.
The customer uses client 001 as a SAP sample client. After a new
installation both 000 and 001 clients are identical, but after an
upgrade 000 will have additional customizing data. Lot of customer
sites does not use 001 client at all. Client 066 is there for SAP
Early Watch service. This client enables SAP to remotely access
the customer system. SAP provides this service to the customer to
improve the system performance. After Early Watch group goes through
the checking methodology, a system performance summery and recommendations
to improve performance report are provided to the customer. SAP
recommends to go for an Early Watch session before your project
goes live and another one sometime after the go live date. Client
066 should not be changed or deleted from the system. In case this
client was deleted from the system, then you have to follow the
instructions in OSS note 7312 to download the client data from sapserv3
and import this data to create 066 client.
a client and setting up the client attributes
create a client you have to maintain T000 table. From 3.0 onward,
transaction SCC4 can be used to maintain T000 table. Also you can
chose Administration-> Client admin -> Client Maintenance
from the initial screen to do the same. In client table T000, SAP
system displays all the clients available, their names, currency
used and when the client was changed last as shown in Figure 9.1.
If the system is in display mode then you must change it to the
change mode by selecting the display/change icon to create a new
client. When you click display/change button, a warning is displayed
as Warning: the table is client-independent. The New
entries icon should be clicked to create a new client as shown
in Figure 9.2.
Figure 9.1 shows Client overview in SCC4 transaction
In the new client creation screen to define a new client you must
fill all the required entries. The client number and the name are
entered first. Then in the second line the location of the SAP system
Logical system is defined next. SAP uses logical system concept
in ALE (Application Link Enabling), workflow and EDI areas. The
logical system must be unique through out the company and any other
ALE system group can not use it. You must be careful changing the
logical system entry. SAP treats a logical system as a client. You
can use transaction BD54 to create a logical system and then enter
that entry in the logical system box while creating a client.
Next entry standard currency can be defined according
to the country. For example USD can be used as a standard currency
for USA. To enter a category of a client you must know the objective
of that client beforehand. For example if this client will be used
as a customizing client then customizing entry should be used from
the options. In the next category Changes and transports for
client-dependent objects, there are four options. If you want
to use this client as a sandbox client; and you do not want to record
or create a change request every time a change happens to the client
then Changes W/O automatic recording is the right option.
If all the changes to the client should be recorded in a change
request then Automatic recording of changes is the right
option. You must choose this option for your master configuration
client. If No changes allowed is chosen, then
no changes will be allowed to this client. You must chose his option
for clients in the production environment to protect your system.
No transport option is used when you do not want any
user to create a transport from this client.
Figure 9.2 shows the client create screen
The Client-independent object changes category determines
if the client independent data maintenance is allowed in this new
client. You get following four options in this category:
- Changes to Repository and client-ind. customizing allowed
- No changes to client-independent customizing objects
- No changes to Repository objects
- No changes to Repository and client-independent custom. obj.
choose the right option from Client-independent object changes
category, you must know the definition of Clint independent customizing
objects and repository objects. The examples of SAP repository objects
are data dictionary objects, module pools and screens. Client independent
objects apply to all the clients. The factory calendar is an example
of client independent object of customizing. For sandbox client,
where user learns how to do the customizing, you must not allow
the client independent customizing.
Changes to Repository and client-ind. customizing allowed:
Both client independent customizing objects and SAP repository objects
can be maintained. Usually this option is selected in a master-customizing
No changes to client-independent customizing objects:
No change is allowed for client independent customizing objects
but changes to repository objects are allowed. This option can be
used for a sand box client.
No changes to Repository objects: If you
select this option, then no changes are allowed to the Repository
objects but the client independent customizing is allowed. When
you want to protect the repository objects in a client, this is
the right option to use.
No changes to Repository and client-independent custom.
Obj: This option does not allow any changes to client
independent customizing objects and repository objects. You should
use this option for a consolidation and production client where
the security of client independent objects and repository objects
In the restriction category of the Change View Clients:
Details screen, there are four options. You are allowed to
maintain only the following three options as shown in Figure 9.2:
- Protection against overwrite by copying:
If you chose this option,
a client copy can not overwrite the new client. You should chose
this option for a master-customizing client or for an important
client as production.
- Start of CATT processes allowed:
This option determines whether you want to allow the CATT (Computer
Aided Test Tool) process in the client or not. Computer Aided Test
Tool (CATT) is tool provided by SAP to test different functionality
of the SAP system. To run the CATT tool you can execute transaction
SCAT. CATT process changes the database extensively and requires
lot of system resources. So we recommend not to chose this option
if you are in the production environment.
- Protection against SAP upgrade:
chose this option, then this client will be not updated in time
of upgrade. You should use this option for a client that is used
for backup purposes or client 066 (Early Watch client) that is used
by SAP for customers SAP system performance. If you chose
this option for any client, the upgrade will not provide any data
to this client and it can not be used as a regular customizing client.
You need S_CTS_ALL authorization to maintain this option.
control in transaction SE06
You can use the system change option to control the system level
access to different types of users in a SAP project. To use system
change option screen you can chose SE06 and then system change option
or use SE03 and then go to for setting the system category
and chose set system change options. The option you
chose here directly affects ABAP/4 workbench, Workbench Organizer
and the transport system.
You need all access to Workbench Organizer to change the system
change options as shown in Figure 9.3.
There are some TP commands that can be used to control the system
level access. ·
change option in se06 figure9.3
following are the four system change options:
cannot be changed: If
you select this option then no changes of any kind are allowed for
any objects in the SAP system. The SAP customers use this option
in the consolidation and production environment. Using this option
you can control the developers and the customizing people directly
changing any development objects and customizing objects in the
consolidation and production environment. So the users use the transport
method to move the objects from development system to other systems
instead of directly creating or maintaining them in the target systems.
The tp command tp lock_eu <sapsid> can be used
in the operating system level to set the system to "cannot
be changed" and the command tp unlock_eu<sapsid>
puts the system back to where it was when the lock command was executed.
original objects (w. Workbench Organizer): If you go for this option then only original objects those are created
in this system can be changed. If the original object exists in
some other system and you have a copy of that object in this system
then you can not change that object. In special cases you can use
this option for the QA or test system. All the changes are recorded
in Workbench Organizer.
customer objects (w. Workbench Organizer):
This option allows you to edit or repair an object though it is
not the original object of the current system. Any changes to customer
objects are allowed. The changes are controlled and recorded by
the Workbench Organizer. This option does not allow changing the
objects came from SAP originally. You can use this option in a training
objects (w. Workbench Organizer):
With this option you can change or repair any objects in the system.
Now the system is totally open for any changes to all the objects.
With this option also every change is recorded and controlled by
the Workbench Organizer. This option is generally selected in a
development or sandbox environment.
4.0 version the se06 change option looks as following:
Client from SAP
pre-configured client from SAP has pre-configured customizing objects
for a simple organizational structure. The pre-configured settings
of the client help a customer to configure a system quickly. SAP
recommends the customers to install the pre-configured client in
their system if they want to go for a rapid implementation using
ASAP (Accelerated SAP) methodology. In the ASAP chapter we are going
to give you an extensive definition about this methodology. Now
instead of starting from client 001 copy, you can start from a pre-configured
client that will provide more configured features.
SAP provides the transports and help documentation to create a pre-configured
client. The pre-configured client for FI/CO, SD, AM, MM, HR and
PP modules is already available from SAP. According to SAP, customers
that have used the pre-configured client saved 4 to 6 weeks of project
implementation time. The way pre-configured client is designed;
some of the small companies can run the pre-configured client for
production after the out of the box installation.
Following procedure is used to create a pre-configured client:
· A client is created in T000 table
· Copying client 000 to the new client
· Copying the data files and cofiles from SAP to your system
· Adding those change requests to the buffer and then importing
them to the target client
· We recommend to check your number ranges after the import
· Creating a user and assigning SAP_ALL and SAP_NEW profiles
· Run the SCAT transaction for CATT tool to test the pre-configured
client. This tool is a great tool for those users, who want to learn
about SAP functionality and, what a pre-configured client can do
·The pre-configured client comes with non-matric units of mass, area,
length and volume and a sample factory calendar is pre-configured
with the ten US government holidays.
the SAP system is installed, the client copy is a common thing to
do for creating new clients. A client copy can be done from one
system to another or within one system. A client copy can affect
the database and current users in the system; so you need to be
aware of the following important information before scheduling a
the stability of the system, always schedule the client copy in
the nighttime when the users are not working in the system.
avoid data inconsistency you should not keep on working in the source
or target clients when the client copy is going on.
the best performance, always schedule the client copy in the background.
Try to examine the maximum online runtime parameter max_wp_run_time
in the instance profile. You might need to increase this for a large
should have proper authorizations to run the client copy. As a basis
system administrator you should have SAP_ALL profile to complete
a client copy successfully. If you do not want a generic id to run
the client copy; we recommend using SAP*. The internal user SAP*
has all the authorizations needed by the client copy.
check the database resources before executing a client copy. You
can do that by running a "test run" client copy. The test
run will provide all the information about the necessary database
table spaces that you need in the target client.
main memory plays a significant role in the client copy. Make sure
that you have enough memory to finish the client copy without any
problem. When you are planning the hardware requirement for the
SAP installation, it is always better to install memory recommended
by SAP. Version 3.X and 4.X require more memory for memory management
and client copy.
you trying to copy a large productive client, it better to copy
the cluster tables first.
You should look for all the OSS notes that apply to the client copy
in a particular version of SAP. For example according to OSS note
number 34547, SAP_USR client copy parameter that suppose to copy
only user data in the background also copies customizing data in
the background for release 3.0B.
the client copy is locked by another client copy run, then check
the log before deleting the lock entry in SM12 to remove the lock.
2.2 release of SAP R3trans is used for client copy, client export
and client import. You should not do the same in 3.0 or 4.0 release
of SAP. You can use R3trans to remove a client in 3.0 and 4.0 also
and we will see the procedure in the deleting a client
part of this chapter. R3trans can be used also for some other important
jobs as described in chapter 10.
is very important to know that the number ranges have to be reset
in the target client if you are just copying the customizing data.
Though the client copy utility has been improved a lot still we
get problems with number ranges. We recommend checking the OSS notes
about number ranges before dealing with them.
you perform a client copy, it is very important to know the three
levels of data in SAP system and how they affect the client copy.
The client dependent application data is created from the master
and transaction data of the system during the application system
operation. The client dependant customizing data is created during
the development process of a SAP project and this data depend upon
the client dependent application data. The client independent customizing
data applies to the entire client. The client copy procedure copies
the client dependent application data and client dependent customizing
data unless you specify to copy the client independent customizing.
To maintain the consistency you should follow some SAP rules. When
you are copying the customizing data, you should copy the application
data (master and transaction data). If you just want to copy the
customizing data then remember that all the application tables are
reset in the process and this reset process can guarantee the consistency
of the client
custom PROFILES to copy Clients
copy profiles are used to copy specific data from one client to
another. SAP provides some custom profiles to perform a client copy.
The following are the example of profiles provided by SAP.
All data of a client
SAP_APPL: Customizing, master and transaction data
SAP_CUST: Customizing data
SAP_UAPP: Customizing, master&transact.data, user masters
SAP_UCUS: Customizing data, user masters
SAP_USR: Authorizations and user masters
objective of above client copy profiles is defined clearly. What
profile you are going to use; depends on what you want to copy from
one client to another. For example you want to copy the entire data
of a client then you want to choose SAP_ALL as your copy profile.
you can select a profile name from the profile input field possible
entries and then chose Profile -> Display profile from the menu.
You can create a custom profile according to your requirement. To
create a custom profile you need to chose the path Profile->
Create profile from client copy or client export screen.
Here you define the profile name. The name should be according to
the SAP standard; so it should start with either Z or Y.
changed by and last changed on: These fields show the information
about the person who last changed the profile and the time it was
the data selection category we have the following three selections:
masters: If you chose this option then the user master records will
be copied from the source client to the target client.
If you want to copy all customizing data then chose this option.
Data. Initialization. Cust. Data:
This option copies master, transaction
and customizing data from the source client to the target client.
tips: It is very important for you to understand the data selection
procedure before the client copy. In SAP environment it is not possible
to copy selected parts of the application and customizing alone. If you want to copy application data, we recommend doing it in batch
input. With batch input consistency is ensured.
the copy mode category the following options are displayed:
Recreate: This option is grayed out and already selected. This option
allows the system to delete all the tables (not selected in the
client copy process) in the target client and initialize them. You
can use the path Extras -> No initialization to have an option
for not choosing this option. We recommend not doing that; it might
create instability in the target client.
variants: If you want to include variants in the client copy then
chose this option.
transport between 2 systems category there is one option:
Independent data: If you chose this option then the client independent
data will be copied from one client to another. We recommend executing
the client copy remote compare program RSCLICMP, before
choosing this option to do a client copy. This program provides
all the information regarding the differences between the source
and target systems client independent tables.
other options are:
source client: You define the default source client for the client
copy in the profile. You can change the client after choosing this
profile before starting the client copy.
source client user master record: You can enter the client number
from where the user master records will be copied to the target
client. You can also change this like default source client.
You should provide a meaningful description for the profile here.
COPY within a system
or RSCLICOP (SCCL as of 3.1 release)
3.0 SAP uses RSCLICOP program in transaction SCC0 to copy the customizing
environment from one client to another. This will copy
clientdependent tables, match codes, number ranges and resolve
the logical dependencies between tables and programs. RSCLIC01 or
RSCLIC02 were used to copy clients in 2.0 release. These programs
use to create command files and the basis administrator was running
R3trans utility to transport the data files. Those programs are
not supported in 3.0 anymore. For the mass data transfer and large
number of table copy, we recommend you to run the RSCLICOP program
in the background.
Trace information about each client copy run is stored in table
CCCFLOW. Use program RSCCPROT to display information about the client
copy. You can run RDDANATB program in the background to get the
information about the size of all the tables in all the clients.
If you start the RSCLICOP in restart mode then try to check the
checkentries in table CCCFLOW.
copy procedure using SCCL
you are planning to copy the source client to a new client then
you must create a new client in SCC4 or table T000 before starting
the client copy.
to the target client and chose transaction SCCL or use the path
Tools ->Administration->Choose Administration ->Client
admin->Client copy ->Local copy and you will see a initial
client copy screen as shown in Figure 9.6.
current client is your target client so it is already selected for
you in the first line. In the second line select the appropriate
profile you want to use for the client copy. You choose the source
client in the third line. In fourth line you can define the client
from which you want to copy the user master records. The Source
Client User Master does not have to be same as source client.
Then if you want to run the local client copy to get the information
about the storage requirements or a complete table statistics then
select the test run flag. We recommend you to run the
client copy using the test run mode first. In test run
phase, database updates are not performed.
should schedule the client copy in the background after all the
parameters are selected as shown in figure Figure 9.6. You can run
a client copy online if you are just copying the user master records;
because when you copy only user master records very limited data
is copied form a client and it does not take that long to copy those
9.6 local copy transaction sccl
the client copy fails for some reason then you can restart the client
copy in the restart mode after the fixing the problems. In this
case the client copy will start exactly from the same point where
it failed. A pre-analysis phase requires sometime determining the
restart point. SAP recommends to set the restart flag in the Execute
in background screen when you plan to copy a large client.
We recommend to reset the buffers by entering "/SYNC"
in the OK code on all the application servers after executing the
RSCLACOP or SCC0 for the client copy. RSCLICOP compares the contents
of each table in the source client with that in the target client.
COPY from one system to another
copy from one system to another:
SCC1, SCC2, SCC7, SCC8, RSCLIEXP, RSCLIIMP
client export/import and remote client copy procedures are commonly
used to copy a client from one system to another. The client can
be exported from the system using transaction SCC8 and then importing
the client using SCC7 or using the transaction SCC2 for both export
and import process, the second procedure is to do a remote client
copy from one system to another. If you are copying a production
size client we recommend performing the client copy using the first
following are the steps in the whole procedure:
- First the data from the client in the source system is exported
from the database to a transport file on hard disk. Before you transport
a client from the source client database, you need to know exactly
what you want to transport and you use SAP delivered profiles accordingly.
- Then the SAP delivered TP command is used for the import to the
target system client database.
- The post processing procedure is run in the target client to successfully
complete the client import.
have to be very careful when copying the client independent data,
because client-dependent customizing objects are dependent on entries
in client-independent tables. SAP recommends that you should not
copy the client independent tables if they are not yet modified
in the target system. If the customizing is being done in a system
regularly then you have to be very careful taking the client independent
customizing to that system; otherwise you might overwrite the whole
client independent customizing settings and the system will become
inconsistent. We recommend to consult the customizing team of a
project before copying the client independent customizing tables.
transport clients from one system to another, go to System Administration
then choose Tools -> Administration -> Client admin->Client
transport -> Client export or transaction SCC8. In the client
transport screen you can select a copy profile that matches your
requirements and the target system in your CTS pipeline as shown
in figure 9.7. Then you can execute the client export in the background
or online. Before the client export starts, a popup screen shows
all the information about the command files that will be created
after the client export is done. After the process starts.
You can watch the export process in client copy log using transaction
9.7 showing transaction SCC8
the client export procedure is completed, if you chose the client
independent data then three transports are created in /usr/sap/trans/cofiles
or there will be two transports:
for the client-independent data ( if selected). For example if the
client export is done from development client 100 then the file
will look like DEVKO0001.
for the client-specific data. For example DEVKT0001
for the SAPscript objects as Texts and forms. For example DEVKX0001
data export is performed automatically. The output of the export
includes the name of the COMMFILE that has to be imported. The following
data files will be created in /usr/sap/trans/data directory using
the same example given above:
client dependent data: /usr/sap/trans/data/RT00001.DEV
client independent customizing data: /usr/sap/trans/data/RO00001.DEV
SAPscript data of a client: /usr/sap/trans/data/SX00011.DEV
Make sure that all the cofiles and the datafiles exist in the data
and cofile directories before starting the import phase.
add all the command files to the buffer by using the TP command
in /usr/sap/trans/bin directory as following:
addtobuffer <cofile name> <target sid name>
Using the above example cofile: tp addtobuffer devkt00001 qas (if
qas is our target system)
tp addtobuffer devko00001 qas
tp addtobuffer devkx00001 qas
logon as <sid>adm to the target system and then use then import
the transports as following:
import devkt00001 qas client100 u148 For the client dependent
tp import devko00001 qas client100 u148 For client independent
the above example QAS is the target system and 100 is the target
you import a client from another system, you must perform post-processing,
activities in order to adapt the runtime environment to the current
state of the data. To execute post-processing, choose Tools ->
Administration- >Client admin ->Client transport->client
import or transaction SCC7. Transaction SCC7 will take you to the
client import post-processing screen . In that screen the transport
from the last tp import is proposed. Please check the transport
number and if every thing is according to the order then press enter
and that will take care of the post processing activities. You can
also use SCC2 to execute the same process as in transaction SCC7.
During this process, the SAPscript texts are imported and application
reports are generated. If there are inconsistencies, you need
to repeat the import after checking the log.
you get any problem importing the SAPscript objects then use the
RSTXR3TR program in the target client to import those. In this screen
you can enter the transport request for the SAPscript object. According
to the above example devkx00001. In the second line you need to
enter the path for the SAPscript data file as following:
file for the SAPscript objects>
/usr/sap/trans/SX00001.DEV (using the above example)
can choose the import option from the mode option. Then
you can continue to execute the program and it will successfully
complete the import of SAPscript objects to the target client.
to release 3.0, RSCLIEXP program can be used to create the command
files. The tp command is used to do the import as we have seen before
and the RSCLIIMP program is executed for the post-processing activities
and the consistency of data.
the transport procedure in 4.0
4.0 after the client is exported from the source system using transaction
SCC8 as we have seen in the client export section, the following
transport files are created.
For the client-independent data (if the copy profile selected includes
client independent data:
For the client-specific data.
For the Texts and forms.
all the above transports get released from the source system, the
data is exported to the data files of /usr/sap/trans/data directory
automatically. The cofiles are also created in the /usr/sap/trans/cofiles
the command files need to be added to the buffer for the import
using the format from the cofiles as following:
to the target system as <sid>adm
cd /usr/sap/trans/bin - Change to the transport directory
- tp addtobuffer <command file-name> <target-sys-id>
- Adds to the buffer
you are transporting to a new client then the new client should
be created in the target system. Then you can start the import into the target system as shown in
the following UNIX example:
import <target-sys-id> client<target-client> from /usr/sap/trans/bin
the tp import process completes successfully, start
transaction SCC2 and then execute the import into the target client.
This process imports all the SAPscript objects and generates all
the programs. After the client is imported successfully, you should
perform the post-processing activities by using the following path:
->Administration->Client admin->Client transport->Post-process
the post processing is done, we recommend doing table compare between
the source client and the target client to check all the client
dependent and independent tables for consistency.
of a remote client copy:
client copy is done using the RFC connection between two systems.
You might get errors if you do not have all the proper authorization
you need including user administration authorization.
A remote copy requires as much memory as needed by the largest table
in the system.
4.0, remote copy can not handle large volume of data. Remote client
copy reads the entire table from the source system and then copies
that to the target system using RFC connection. For big tables as
BSEG, it takes more time then the RFC wait time; so it might not
copy the big table at all. For the same RFC wait time constraint,
large quantity of texts can not be copied and remote client copy
might terminate without any error. You are not going to see this
problem in 4.0 release, because the tables are copied in blocks
by RFC. You should check the memory parameters for memory and MAX_wprun_time
for run time before starting the remote client copy. Try to add
the big tables to the exception list by executing RSCCEXPT report.
In 4.0 an inconsistency check is performed automatically during
the remote client copy; if any inconsistency is there then the system
returns an error.
recommend avoiding big client copies using remote client copy procedure
until release 4.0.
In the beginning of a development project upto 3.1I release you
can use remote client copy for the smaller clients; when the client
gets real big it is better to run client export/ import procedure
client copy procedure:
you perform a client copy, the RFC destination for the source system
needs to be defined using transaction SM59. In transaction SM59
screen chose R/3 connections under RFC destinations.
Now you click on the create button to create a RFC connection as
shown in Figure 9.9.
9.9 picture of creating a RFC destination
the RFC connection for the source system is created, you are ready
to perform a remote client copy.
You can chose SCC9 or the menu path Tools ->Administration->Client
admin->Client copy ->Remote copy.
line shows the target client, which is the current client as shown
in Figure 9.10. Now you select a copy profile according your
requirements. We have already seen how to create a profile and what
is their objective. In the fourth line enter the source client (from
where you are copying). If click the enter button the fifth
line Source Client User Master will be filled with the
same number as source client. You can change it if you want to.
Enter the source system name or RFC destination name that you created
in SM59. You can execute the remote client copy in the test mode
by selecting the test run flag. After you are done with all
the selection you can click on the Execute in backgrd.
button to start the remote client copy procedure as a background
9.10 to show the remote client copy screen
need to perform two steps to delete a client. First you need to
delete the complete client from database and then delete it from
client maintenance table T000.
delete a client from a SAP system:
log on to the client to be deleted with the proper authorization
to delete a client.
Then choose path Tools ->Administration->Client admin->Special
functions->Delete client or transaction SCC5 and you are going
to see a delete client screen as shown in figure 9.11. In this screen
you are going to find two entries; test run and also delete from
you want to run a client delete process to find out information
about all the tables that will be deleted then test run is the right
option to use. If you do not want to copy another client to this
client and get rid of this client forever then delete from
T000 is the right option to use. You can delete the client
in SCC5 by executing it online or in the background. You can choose
either one of these options and in the verification popup screen
you can check all the parameters for client deletion. After the
client deletion process starts you can use SCC3 log entries to check
the client deletion process.
9.11 to show the client delete screen of SCC5
all the SAP releases so far you can use R3trans to delete a client.
We have seen significant timesaving in this way of deleting a client.
If you use the R3trans command in the operating system level to
delete a client then the first step is to create the command file
in /usr/sap/trans/bin (it does not have to be /use/sap/trans/bin
as long as you provide the right path in the OS level) with the
Client = 100
the above example the command file name = del100 and the client
we want to delete = 100 are used
in /usr/sap/trans/bin directory run the following command to delete
w <log file for the deletion> -u 1 <path name
and the command file>
our example here you run: R3trans -w del100.log
u 1 del100
can VI to the del100.log to anytime to the progress in the deletion
For the database performance, we recommend to do database reorganization
after you delete a production size client from the system.
To check the contents of the log:
Tools ->Administration ->Choose Administration ->Client
admin->Copy logs then Select a client by double clicking on it
and select a copy process by double-clicking on it. The transaction
for the log selection is SCC3 transaction. You also can run the
program RSCCPROT to get the same result.
can select one of the client copy entry from Client copy log
analysis second screen, following three buttons are provided
as shown in figure 9.13.
9.13 for the client copy log screen
you select a Log button from the Client copy log
analysis third screen, then not only you get the general information
about the client copy but also the following information for each
of the table copied in the process.
Number of entries in the source client
Number of inserts necessary in the current client
Number of updates
Number of deletes
Additional space required by the copied table in bytes
following is an example of what you will see in a log display screen.
above example shows the class C. The class represents
the delivery class. Through the delivery class you can know the
kind of data the table has or what environment the table belongs
to. For example, all the tables shown in the above display belongs
to the customizing environment or they have customizing data. The
following are the examples of the delivery classes and their definitions.
Application table includes the master and transaction data
|| Customizing table
|| Table for storing
|| Customizing table.
It is protected against SAP Update
|| Control table
|| System table.
They are only maintained by SAP
|| System table.
Contents transportable via separate TR objects
table information, all the additional storage required in Kbytes,
the run time for the client copy and the end of processing time
are also shown as following example in the client copy log analysis.
- Copied tables: 5,671
- Tables deleted: 0
- Storage required (Kbytes): 260,444
- Program ran successfully
- Runtime (seconds): 10,123
- End of processing: 13:37:24
can click on the Monitor button and watch the progress
of the client copy real time.
The Refresh button always refreshes the screen to show
you the up to date information.
System log button takes you to the system log screen
to show you all the system messages.
next button Resource analysis is a very important utility
to show you all the data base resources you need to run the client
copy in the table space level. In the resource analysis utility
you can get realistic picture of deletes and inserts calculation
for the database. Memory requirements can also be found out
by this utility.
You should always check SM21 (the system log) for all the client
Golden rules for CLIENT Copies
- Master data can not be copied without copying transactional data
and transactional data can not be copied without copying master
- Application data (transactional and master) should not be copied
without copying configuration data.
- Client copy requires a valid client as the destination client. Make
sure that the client exists in T000 table and you can logon to that
- The transport system and the transport management system of 4.0
are the only proper tool to be use to keep multiple systems in sync
by transporting development and customizing changes to another instance.
- When you copy a client from one system to another, client-independent
tables should only be copied if they are not yet modified in the
- We recommend the users to read all the OSS notes regarding client
copy that applies to their SAP release. It is always better to schedule
the client copy job in the background for the night run when normal
work is not taking place.
- Always check the database space before performing a client copy.
- To avoid data inconsistencies all the users working in the source
and target clients should logoff from the system.
- RSCLICHK program should be run in the target system remotely before
doing a client export. This program will give information about
the missing definitions from the data dictionary in the target.
After executing this program and getting successful results you
can ensure that the client copy will have no problems. In case some
tables are different; you can use SE11 to compare and adjust the
table structure in both the system before the client copy. A remote
test client copy also can be executed to know the differences between
source client and target client.
- If you are not in release 2.2 then do not use R3trans to copy a
method for copying VARIANTS
VARI, VARID and VARIT tables contain all the variants in the SAP
system. Those variants can be copied in the client copy time using
an appropriate client copy profile. If you just want to copy the
variants then R3trans can be used to copy those very quickly.
copy the variants from one client to another in a system using R3trans,
follow the following procedure:
create a control file with the following contains:
source client = <source client number>
target client = < target client number>
select * from VARI
select * from VARIT
select * from VARID
second step is to logon as <sid>adm and use the controls file
with R3trans as shown in the client export and import section of
this chapter. This procedure will copy all the variants from the
source client to the target client as defined in the control file.
copy all the variants between clients between two different systems:
create a control file for R3trans with the following contents to
create a data file:
client = <source client>
file = <the path for the data file and the file name>
select * from VARI
select * from VARIT
select * from VARID
second step is to logon as <sid>adm in the source system and
use R3trans as shown before to execute the control file. The process
will create a data file as defined in the control file. The third
step is to define a import control file for R3trans with the following
client = <target client>
file = <the path for the data file and the file name>
the control file is created, logon as <sid>admin the target
system and execute R3trans command with the control file to import
all the variants to the target system.
Important client management tips
recommend deleting the large cluster tables first from a client
using R3trans client remove command before going for the deletion
of entire client. To increase the client copy performance it is
also better to copy the cluster tables first using the R3trans command.
Then use the RSCCEXPT report to exclude all the cluster tables before
doing the client copy. To get a list of cluster tables use transaction
SE85, then chose other objects -> select pooled/cluster tables.
The following control files are for both the above examples:
copy the cluster tables:
source client = xxx
target client = YYY
select * from BSEG
select * from
delete the cluster table before deleting the whole client:
client = XXX
select * from BSEG
and YYY represent the client numbers)
to chapter 10 to understand how to execute a R3trans command.
each database, the rollback segments needs to be extended so that
the largest table in the system can be copied without any problem.
In release it only applies to client transports or copies and deleting
the tables. In release 4.0 it only applies to transports.
does not support a non-numeric client.
you get a message The client copy is locked by another run
and you want to kill the current process to start a new client copy
then call transaction SM12 and check the entry RSCLICOP and then
delete it. Make sure to check if any clientcopy job is running in
the background before deleting the lock. If a job is still running,
you should wait till it finishes because you can not start another
client copy run.
the client export is done, the command file might not be created
for the SAPscript objects in /usr/sap/trans/cofiles directory, you
only find the data file in /usr/sap/trans/data directory. Sometimes
the SAPscript objects can be locked properly and the transport request
does not get released. To release the SAPscript change request,
logon to the source client and execute SE01. Then enter the transport
number and try to release it from there. If there is a lock problem
then solve it and then release the request.
from 4.0 to 3.0:
have to be very careful while doing the transport of a logical database
in 4.0. In release 4.0 the buffer of the logical database is changed.
Always run RSLDB400 after the import of a logical database.
Before transporting the repository objects from release 4.0 to 3.1
you need to know that the names of the repository objects in release
4.0 are extended. Always check the current version of R3trans; you
might need for your system to transport objects from 4.0 to 3.1
releases. If your system has SAP release other than 3.1I; you can
not transport SAPscript objects from 4.0 to 3.0. The internal buffer
is also changed in release 4.0, so GUI screens can not be transported
from 4.0 to 3.0.