Large Production Client Copy and Prepartion
DAS
Symptom
--------------
You want to copy a large production client.(This note replaces note
67205 as of WAS 6.10.)
The Cause and Prerequisite section discusses whether it is useful or
permissable to copy a production client.
1. Since a production client contains a very large amount of data, the
copying process may be very time consuming.
2. Users frequently want to copy only master data, to reduce the amount
of data.
Reason and Prerequisites
----------------------------------------
Copying a production client is only useful if you want to set up a new
test system from a production client.
To copy a production client, the client copying process must access a
large amount of data selectively.This automatically leads to long
runtimes.
Therefore, a database copy is usually preferable to copying the
client.See the 'R/3 Homogenous System Copy' guide for more information.
You will find it in on the separate 'Installation Guides' CD or on the
SAP Service Marketplace at:
'http://service.sap.com/instguides'
The application component for system copies is:
BC-INS
All tools for the homogeneous system copy are freely available.The
"Heterogenous System Copy Guide" is part of the migration service and
must be purchased separately. (Refer to note 89188)
Note:
A copy of a production client created by client copy must never be
directly used for production.For example, change documents and
archiving information are not copied.See note 24853 for information on
further restrictions.
The relocation of a production client with the client copy always
requires the support of the "Conversion Services".If necessary, contact
the Support team for the XX-SER-CS components.
In general, the problem is greatly simplified if the client number
remains unchanged (this means, for example, copying the 100 client of
system A to the 100 client of system B).
For the recovery of a client at the same location, SAP provides the
SAP_RECO copying profile.See note 31496 for more information.
Solution
---------------
1. A production client contains a large amount of data.The client copy
must access this data selectively.The database interface limits the
throughput to approximately 500MB per hour and process.This means a
runtime of 1 - 2 hours for a production preparation client and an even
longer runtime - up to several weeks - for production clients.
Note 24853 describes the available tools of the client
copy and its functions. For more information specific to the remote
client copy, see note 557132.
To keep the runtime as short as possible, note the
following points:
a) Lock the source and target clients
Ensure that all work in the source and target
clients is stopped before you start the copying process.New logons to
the target client are automatically prevented (except for SAP* and DDIC
users).For the source client, you can choose if you want to lock new
logons (see note 446485 - "SRC_LOCK" option).However, ideally you
should lock all activities in the entire source and target systems
(including background processes).
Use the LOCKSYS command to lock the entire
system against new logons (see also the documentation of the tp
transport control program).You must then execute the copy with the DDIC
user (if necessary, the RFC destination must also use this user).
To ensure that all activities are actually
locked, restart all relevant servers (you should, however, notify the
relevant users beforehand, for example, by sending a system message).
a) Use parallel processes
As of Release 4.6, parallel processes are
available for local copying (SCCL transaction), remote copying (SCC9),
and client deletion (SCC5) ('Parallel processes' button). (See note
541311). As of Release 6.10, the parallel processes for performance and
logging are improved further.
Set up an RFC server group with transaction
RZ12.For remote copying, you should also assign a logon group in the
source system to the RFC target system, using transaction SM59.Both
transactions can be called directly via the transactions of the client
copy.This means that you can distribute the processes in both systems
to several application servers.
Use two processes per database server CPU.Ensure
that the relevant application servers have a sufficientnumber of free
dialog processes.To use four processes on a server, for example, it
must have at least six free dialog processes, as the RFC server group
administration always reserves two dialog processes for other system
activities.
For remote copying, we even recommend that you
use three processes per target database CPU.Parallel processes are
especially useful for remote copying, as more different resources can
be used simultaneously:
Read the source database
Compress the data on an application server of the source system
Send the data via the network
Decompress and convert (if necessary) the data on an application server
of the target system
Write and delete (if necessary) the data in the target database.
The copying phase starts after the tool has
completed its analysis of the system. During the copying phase, you can
monitor the activities of the parallel processes, for example with
transaction SM66. However, not all processes are visible at all times
(for example, if a process is waiting for a lock).
a) Reducte the dataset by archiving
Archive as much data as possible in the source
client before copying, to reduce the dataset.
a) Reorganize the database and update statistics
We urgently recommend that, before copying, you
defragment or reorganize the database (when using remote coping, do
this also for the source database) and update the statistics.SAP
provides the SAPDBA tool for this.See the relevant documentation for
your database for information on how to improve the performance of the
database for selective mass data accesses.
Unorganized tables and obsolete statistics can
have a very significant effect on runtime. This applies to the deletion
of data as well as copying.
Update the statistics in the target client after
every copying process, as the previous statistics are generally made
unusable by moving large datasets.
Since the data must be accessed with "ORDER BY
PRIMARY KEY" in the case of a remote copy in the source system, it may
be necessary to increase the memory space for sorting in the database.
In some databases, for example in the PSAPTEMP area. A reorganization
of the relevant tables is often useful also, however, and improves
performance at the same time. You can use a test run to check in
advance whether this problem applies in your case.
a) Archive log/logging the database and indexes
All databases have a logging mechanism to allow
a 'Point in time recovery' to be executed.This function is very
important and security-relevant.However, it also impedes performance
and uses memory space.Before copying a large client, you should always
perform a full backup.If you have a complete backup and you are sure
that no logging is required for the time being (that is, that no other
activities except the client copy are executed on the system), it may
be useful to deactivate logging.This, however, must be decided by your
customer.In particular, do not forget to reactivate logging after the
copying.
The system responds in a similar way with the
temporary deletion of secondary indexes that are not flagged as UNIQUE.
In the case of individual large tables, the performance of the target
database may improve significantly if indexes are deleted before
copying starts and are not recreated until the table has been copied
successfully. The customer is fully responsible for this step also.
a) Specific client copy options
If necessary, the standard prioritizes stability
over runtime optimization.However, use the specific options described
in note 446485 to optimize the copy for the local environment.
a) Advance deletion of the target client
If necessary, you can delete the target client
in advance with transaction SCC5. You cannot shorten the overall
runtime in this way, but the actual copying process, and therefore the
period during which the source client is used, will be shortened.
There is no perfect deletion algorithm that
guarantees stability and performance for all tables on all
databases.You can therefore choose between different deletion
algorithms.See the previous paragraph, "Specific client copy options",
or note 446485 for more information.
a) Advance deletion of large and critical tables
If individual critical tables are very demanding
on the deletion algorithm, you may use one of the special reports in
note 365304.
a) Network throughput
All data is transferred in the network via the
following route:
>From the database to the application server.
For remote copying, the data to be copied is compressed on the
application server of the source system.
>From the application server to the target database.
The only exception is the deletion of
data.Usually, all key fields are transferred to allow block-by-block
deletion.This may be further reduced by using the KEY_DELETE or
LOCK_SYS options (see note 446485).
This data throughput should not pose any
problems to a modern network.However, if you want to execute remote
copying between two systems that are located in different network
domains, you may have to take the necessary measures.Ideally, the net
data throughput is > 100GB per hour.
A remote copy using a WANnetwork is possible.
For example, with an individual 2-Mbit line, you can realistically copy
approximately 30 to 40 GB per day if the copy is homogeneous (that is,
the same code page and endianess; if the data has to be converted,
cluster tables, for example, must be copied in table form as they
cannot be transferred in compressed form). However, tuning measures are
may be required at the SAP gateway and in the TCP/IP (for example,
buffer settings and window sizes) of the operating systems in question
in order to receive a high data throughput. (These measures are not
discussed in this note because they are very system-specific). A
simulation of the remote copy with parallel processes is the ideal way
to test the changed settings for effectiveness under realistic
conditions. Too many parallel processes may overload a network and
result in network performance problems. If you use two 2-Mbit lines,
you should start the tests with 6 to 8 processes.
a) Time Out
Coyping a large client should be executed in the
background.Nevertheless, dialog processes are used for the parallel
processes and the access to a remote system.Usually, this is a
non-critical process since the access is executed
block-by-block.CWITH_CURS, DWITH_CURS, KEY_DELETE, LARGEBLOCK, and
LOCK_SYS, and, under certain circumstances, also SINGLECOPY), or if the
source database is not in a perfect state, you should increase the
following parameter on all application servers: rdisp/max_wprun_time
The MAX_WPRUN option automatically executes this
for the target system servers (for the duration of the copying
process).
In the source system of a remote copy, you
should always increase the parameter temporarily. A value of 2400
should be sufficient in most cases. Use transaction RZ11 to do this.
Display the parameter rdisp/max_wprun_time and, on the display screen,
choose "Change Value".
a) Simulating the copying process and memory space requirements in the
database
Perform relevant test runs before the actual
copy.The test run of the client copy is a first indicator.If you only
want to determine the dataset to be copied, choose the "Resource
analysis" after having started the test run.However, if you choose
"Simulation", all the steps are executed as for a real copy, from the
reading to the sending of the data.Only the deletion and writing of the
data in the target client is left out.This means that the runtime is
about half of the actually required time (the worse the state of the
source database, the longer the simulation takes in comparison to the
real copying process).
For both test run types, you can then execute a
database area analysis with transaction SCC3 (provided, your database
has database areas).In addition, the total of all data to be copied and
deleted is listed, in KB, at the end of the log file.
You can also determine the size and the storage
requirement of your clients with reports RSTABLESIZE or RSSPACECHECK
(see also note 118823).
Before starting the copying process, ensure that
there is sufficient space in the target database.If the copying of
individual tables is terminated due to database problems, the main
process will try again to copy these tables, after the parallel copying
phase.
a) Client transport
In some cases, instead of using remote copying,
you may continue using the client transport (transaction SCC8 for the
export, STMS for the import, and SCC7 for the postprocessing in the
target client).However, this will cause a considerably longer total
runtime, since no parallel processes are available and the transporting
of texts can last a very long time. Also, the data must be first copied
to the file system.See note 70547 and the relevant R3trans
documentation for more information.
1. Unfortunately, it is not possible to only copy master data to
achieve a data reduction, as many tables contain both master and
transaction data. Also, the difference between master and transaction
data is not clearly defined and needs to be defined in each production
environment, depending on the Customizing. See notes 24853 and 19574
for more information.
amit shokeen
for a CRM Database, specially the post installation
doc .
Thanks
Amit
____________________________________________________________________________________
Do you Yahoo!?
Everyone is raving about the all-new Yahoo! Mail beta.
http://new.mail.yahoo.com
amit shokeen
amit shokeen
BRBACKUP command. Can someone list all the files like
SAPDATA1-N
amit
____________________________________________________________________________________
Have a burning question?
Go to www.Answers.yahoo.com and get answers from real people who know.
