Client copy issues in sap & who needs take care about that issues

General problem
When running the client copies in I1M, MM1 & S1M in the weekends, there were a lot of issues, which
caused the copies not to finish before Monday morning. In the next paragraphs short summary of the
encountered issues and how they were solved. The over-all coordination in case of these problems is with
the SAP Landscape Team. They will get in contact with the involved parties and make sure actions are
followed up. It’s important to make people aware of the importance of the issues. When getting closer to
Go-Live the urgency of the issues gets higher, since they can have a big impact on it. When having issues
always raise a Remedy ticket or TPR. This helps making people aware of the issues and the importance
of them.
Data load activities
When data loads are running during the weekend, they take up a lot of background processes and disk
space. This decreases the system performance and slows down the client copies. This could also cause
locks on tables, which can stop a client copy or can cause errors during the copy.
It has been agreed with the data managers that during the weekend there are no data loads running and
there are as little people in the system as possible.
Action for: MI-RMG / Data Managers
Truncation of tables
There are a number of tables – mostly containing log information - that are growing very rapidly and take
a long time to clear out and fill again. This can increase the runtime of the client copy with a couple of
hours.
One of the actions assigned to the Basis team is to truncate – empty – these tables every week before
the client copies start. Currently the following tables are being truncated weekly:
IDOCREL
SRRELROLES
SWELOG
SWELTS
BDCP
BDCPS
SWW_CONTOB
Action for: SAP Basis Team
SAPARCH
When client copies are running, redo logs are created and stored in SAPARCH. The same happens with
the backup logs. During the weekend SAPARCH regularly filled up causing the client copies to stop and
the system to become inaccessible.
A script running during the weekend regularly deletes the redo logs of the client copies. Also the backups
are stopped during the weekend, which gives more space in the file system. The Basis team also
monitors SAPARCH preventing that it fills up and stops the client copies.
Action for: SAP Basis Team
Outstanding IDocs
When running data loads IDocs are created and stored in the system. This increases the size of the client
copy and therefore also the runtime for the client copy on that client. The IDocs have a retention period of
about a month.
Agreements have been made with the Archiving Team (X-function) that the systems are being cleared out
on a monthly basis.
Action for: Archiving team (X-Function)
Backups
During the week backups are running in the different systems. This takes up a lot of system resources
and also tends to fill-up SAPARCH. Since the logs of the backups are removed from SAPARCH to
prevent it from filling up, the backups are not use full during the weekend.
The backups are stopped during the weekends, which will help on the system resources and will help
solving the problems with SAPARCH.
Action for: SAP Basis Team
Table space sizes
Client copies have often stopped because the table they were filling ran out of space. This locks the
refresh, which won’t start until the space has been extended.
It has been agreed that the table space sizes are increased when the client copies are scheduled making
sure that this won’t cause the refresh to stop.
Action for: SAP Basis Team
Multiple copies running
Client copies were originally scheduled to start at a specific time. This means that if the previous client
copy hasn’t finished yet, multiple client copies are running at the same time on the system. This has
severe impact on the system performance and can cause a table to be locked which stops the client
copies.
The copies are now scheduled to start after the previous copy. This may cause that not all copies finish
during the weekend, but it does decrease the runtime of the refresh.
Action for: SAP Basis Team
IDocs Jobs / Link with production system
During the week send & zload jobs are running to send IDocs from one system to the other if necessary.
These jobs used to run every ten minutes and shouldn’t take any time if there are no IDocs to process.
Normally there is an ALE link active from MP1 to MM1; from MM1 to I1M & from MM1 to S1M to make
sure the M-Systems have the latest Master Data. The link uses the zsend & zload jobs to get the data in
and out of the system.
During the weekend the link between MP1 and MM1 is deactivated to prevent IDocs being sent to MM1,
which would take a lot of system resources. This means that in principle the zsend & zload jobs should
not be processing anything. However, in practice it has turned out the jobs still take some time to finish.
Therefore it has been arranged that the zsend & zload jobs are rescheduled – also during the week – to
run every hour instead of every 10 minutes. This reduces the system resources required.
Action for: ICC
Change Pointer table BDCPV
Table BDCPV gets really big dependent on the number of message types set with Activate flags on and
the amount of data base changes that take place.
There are a number of ways to deal with the table and to prevent the contents from being copied client to
client. One option is to run transaction BD22 over the table to delete processed change pointer entries
and / or unprocessed entries – that are not required – for specific message types. A batch job could be set
up to do this; just need to make sure the settings are correct. Another option is to ensure that when the
master client is built, the message types are reviewed (BD50) and checked to see if the Activate flag is
on.
Action for: Data Manager / ICC
Other actions
Some other things that can be checked when copies take too long to finish are the Oracle parameters. In
the past the following parameters have been changed:
SHARED_POOL_SIZE
DB_BLOCK_BUFFERS
Action for: SAP Basis Team
Also it can be checked on which cluster a system is located. If systems with client copies are on the same
cluster, they can affect each other's system performance. It’s preferred that systems with multiple client
copies are located on different, relatively quiet clusters.
Action for: SAP Basis Team

If the problem remains over a longer period, the priority of the different clients has to be estimated during
the week. Then the most important ones are scheduled as the first copies, which increase the chances of
the copy to finish during the weekend. It also prevents that it’s always the same clients that get refreshed,
while others are never refreshed. Also it’s possible to schedule client copies during the week for the
smaller clients in the system. When clients are no longer in use, they could be deleted, which gives more
space in the system. This can be confirmed by the MI-RMG team and the data managers.
Action for: SAP Landscape Team

Another option is to lock out all the users while the client copies are running. Downside is that certain jobs
won’t run, which will give a backlog in the job schedule on Monday morning. This could give performance
issues. However, if users are not able to access the system, the run time of the copies will decrease. This
option hasn’t been used before and should only be used as an ultimate solution.