A Guide to SAP System Refreshes

ABSOFT WHITE PAPER

2 | A Guide to SAP System Refreshes
Contents

Executive Summary 4

Traditional Client Copy Refresh Method -

Better the devil you know? 5

The Search for an Alternative Approach

System Copy Method 7

Archival of Production Data 8

SAP Infrastructure Investment 9

Specialist System Refresh Products 10

Contact Us 11

A Guide to SAP System Refreshes | 3

 Executive Summary
What is an SAP system refresh?
The majority of SAP landscapes consist
of three or more separate systems:
Development, Quality Assurance (test
system) and Production (live system).
Each system contains one or more clients.
A client is a self contained logical unit
within a system. Each client contains its
own separate data set.
In a typical SAP system the production
data set is periodically copied onto the
Development and Quality Assurance
systems in order to allow full testing of
customising and development changes
that are made to the live SAP system.
This is known as a system refresh. The
frequency of these refreshes is determined
by business and test team requirements
but typically several refreshes are
performed over the course of a year.
4 | A Guide to SAP System Refreshes
Meeting statutory audit requirements
With the increasing pressure on companies
to deliver procedures that comply with
Sarbanes-Oxley and other audit
requirements, system refreshes are no
longer a “nice to have” for many SAP
customers. It is becoming mandatory for
companies to maintain an up-to-date quality
assurance environment in order to meet
statutory audit needs.
Using real, meaningful data for testing,
development and training
Aside from regulatory compliance, there are
many additional benefits of carrying out
regular SAP system refreshes.
The main benefit of replicating live data into
a quality assurance or development system
is that it provides an isolated environment,
away from the main business operations
where developers and test teams can test
any system enhancements or bug-fixes in
conditions as close to those in Production
as possible.
Other benefits include:
• The ability to test new authorisations or
security parameters using copies of live
users without affecting the live user data.
• Training for new employees and processes
can be carried out away from the live
system using real meaningful data.
• SAP patch upgrades (Support Packages)
can be tested in full using a copy of the
live system to reduce or remove any errors
that might not have been identified in the
Development environment.
Various options exist for performing a
system refresh. The majority of companies
will be aware of the traditional method of
Client Copies from their initial
implementation experience. Some will
continue to use this method as their
operational requirements allow it, while
others quickly identify that there are more
effective and appropriate methods of
obtaining a copy of their Production
environment.
The purpose of this white paper is to outline
the options available, to identify the
advantages and disadvantages of each and
to summarise which path may be most
suitable for customers in the long term.
Traditional Client Copy Refresh Method -
Better the devil you know?

Traditionally many SAP customers have

used the standard SAP client copy method
QAS PRD
of system refresh. As the name suggests,
this involves the transfer of data from one
system to another at a client level.
100 – Config 450 - Production
Sufficient storage permitting, this method
allows for many copies of the Production
client (PRD) to be copied back to multiple
clients within a single Quality Assurance

250 – Integration
system (QAS). This allows project and
support teams to test with isolated sets of
Production data within the same system.
This is illustrated in Fig. 1 to the right.

Can you afford to be locked out of your 321 – Project 1

live system for a weekend?

The main problem with the traditional

321 – Project 2
method of system refresh is that it requires
downtime on the live system in order to be
carried out successfully. This causes
disruption to business operations, which
gets worse as time progresses and the Fig. 1
amount of data on the system grows.

SAP client copies work by copying all client

specific data from source to target client. Client copy Tip I -
The client copy job itself is reasonably REDUCING SYSTEM DOWN TIME
It is possible to adjust a client copy
straightforward in its operation. In essence,

strategy by performing a client delete

there is a list of tables whose contents need

in the target system prior to each

to be copied, and a specified number of

copy. It can be seen from the graph

processes to work with. Each process

where this strategy was changed as it

copies data from source to target one table

reduces the overall downtime in the

at a time. When the process finishes copying

Production system. The overall result

data for one table it moves on to the next in

however is that this only delays the

the list. In an SAP ERP 6.00 system there are

inevitable where it becomes

approximately 70,000 tables.

impossible to carry out a refresh

within the allocated Production
Many of the 70,000 tables that are included

downtime window.
in the copy job are related. For example, if
a user were to create a new purchase
order, many tables may be updated to
record the information in the database.
However, the client copy job makes no
allowances for relationships between the
various tables. So, to ensure consistency
of the data, no updates should be made to
the source client whilst the copy is running.
In practical terms this means no users can
be logged onto the Production client whilst
a client copy is in progress. In order to
minimise disruption to the business, client
refreshes are always performed during
weekend outages at pre-arranged outage
windows.

Figure 2 on page 6 shows how the client

copy times can increase in a typical system
of 200 users.

A Guide to SAP System Refreshes | 5


20:00:00
15:00:00
Runtime (Hrs)
10:00:00
05:00:00
00:00:00
Jan 07
Client copy Tip II -
REDUCING CLIENT COPY TIME
The number of processes you can
define for the copy is limited by the
hardware of both source and target
host. Through experimentation and
experience it is possible to optimise
this, for example by applying the rule
that two processes per CPU or core
are possible.
6 | A Guide to SAP System Refreshes
Client Copy Times
Feb 07 Mar 07 Apr 07 May 07 Jun 07 Jul 07 Aug 07 Sep 07
Increasingly long runtimes present the
following problems to all SAP customers:
1. Insufficient Time to Re-run a Failed Copy
In the event of a client copy failure it may be
necessary to reset and restart the copy
procedure. This would entail deleting the
data already copied and restarting the copy
from the beginning. As refresh times
increase, it becomes more difficult to reset
and rerun a failed client copy over a single
outage weekend. If the copy cannot be
completed it leaves the target client in an
inconsistent state rendering it useless until a
further refresh is completed.
A failed client refresh would have a
detrimental effect on the users of that client.
In the case of an integration testing client,
support users would be unable to perform
user acceptance testing. In the case of a
project specific client, there may be no
alternative clients available forcing the
potentially costly suspension of project
activities until a refresh could be completed.
In order to perform a subsequent refresh to
repair the client an additional outage of
Production would be required. If the initial
failure occurs on the weekend before month-
end begins it may be two or three weeks
until another outage can be scheduled.
Oct 07 Nov 07 Dec 07 Jan 08 Feb 08 Mar 08
Fig. 2
2. Greater Likelihood of
Communication Failure
The client copy process is based on SAP’s
remote function call technology. This
essentially requires the target system to log
onto the source system at an SAP level over a
network connection. Although failures with this
technology are rare they are not unknown.
Network outages, SAP kernel bugs and
general hardware failures can all cause these
connections to fail. Unfortunately the longer
the client copy runs, the greater the likelihood
of a failure of this nature being encountered.
3. Availability of Production
Outage Windows
As the runtime increases the Production
outage requirements are going to expand. It
will be necessary to either start the copy
sooner each weekend or allow it to run for
longer impacting live users.
Looking further ahead, perhaps 2 or 3 years
from the present it is possible to predict
future copy times which will clearly show that
a single weekend outage window isn’t
sufficient. Beyond this point, the business
would need to agree on an extended outage
of Production which would impact on the
Monday to Friday working week. This is
unlikely to be an acceptable solution.
The Search for an Alternative Approach
System Copy Method

As discussed, the traditional method client

copy will become impractical for most Client Copy
customers in the long term and for many

QAS PRD
SAP customers it is never a viable option
because of the large amount of data held
on their production system. So, what are

100 – Config 450 - Production

the alternatives?

System Copy Method

An SAP system copy is a widely used

250 – Integration
solution for refreshing Quality Assurance
systems with Production system data. In
fact, it is the most commonly used refresh
method for medium to large size SAP

321 – Project 1
customers. The process involves taking the
latest online Production system backup
and restoring this onto the Quality
Assurance system hardware. For most

321 – Project 2
databases that SAP runs on a small
amount of pre and post processing is
required.

As the refresh can be performed using a

System Copy
normal online backup no Production
system outage is required. System
refreshes of this type can normally be
QAS PRD
completed within less than a day including
all pre and post-processing actions.

100 – Config 450 - Production

The fundamental difference between a
system copy and a client copy is that the
whole source system database, client
structure and all, is restored onto the target
system. This difference is illustrated in
Figure 3 on the right. Fig. 3

As can be seen in Figure 3 a system copy

overwrites the entire system. If the source
system has one client and the existing
target system has four clients then after a
system copy is performed the target system
will have a single client which is an exact
copy of the source client. There are
therefore advantages and disadvantages to
this method:
Advantages
• Fast compared to the traditional client
refresh method. Restore time is likely to
be around half or less that of a client copy
depending on backup hardware available.
• In terms of man effort this is comparable
to the current client refresh method.
• No Production system outages are
required as the refresh can be performed
using the existing Production system
online full backups.
• This is a well tested method with proven
support from SAP’s own backup and
restore tools.
Disadvantages
• A system copy from Production back to
Quality Assurance will provide support
and project teams with only a single
integration client. This may not be a
suitable proposition for some customers.
It has always been preferred to set up
separate clients within the Quality
Assurance system for project testing.
A Quality Assurance system outage is
required whilst the refresh is in progress.
• Refreshes are performed at a system
level so this approach does not provide a
solution for refreshing any unit test
clients in the Development system.

A Guide to SAP System Refreshes | 7

 Archival of Production Data
This isn’t a refresh method as such but a
way to improve the traditional client copy
approach. SAP Archiving is a method of
removing old data from the database,
storing it at an offline location and making
it available for retrieval at a later date.
SAP’s data archiving solution complies
with statutory data retention rules and
ensures that the data is both consistently
removed from the database and available
for access in the future.
Archival of data is based on logical
business data types called archiving
objects; examples of archiving objects are
Purchasing Documents and Credit
Memo’s. These objects allow the archiving
administrators to work easily with SAP’s
complex data model since they are
shielded from the underlying raw tables.
Each object has a number of automated
methods which, amongst other tasks,
control whether certain data is written to
archive, read from archive or deleted from
the database.
8 | A Guide to SAP System Refreshes
Archiving is a three stage process:
1. The administrators determine which data
is to be archived for the chosen archiving
objects. The data is then copied from the
database and written into external archive
files.
2. The archiving programs test to see if they
can read the data back out of the archive
files. If this is successful the data is
deleted from the database.
3. The archive files are saved on another
server, separate from the SAP database.
Depending on industry financial regulations,
many SAP customers only consider data
archiving for systems which contain more
than six years worth of data.
In the context of a system refresh, document
data archiving could potentially be used to
reduce the amount of data stored in a
Production client. A reduced dataset would
lead to reduced runtimes for any test client
refreshes.
Advantages
• A reduced production dataset allows
Quality Assurance and Development client
refreshes to be completed faster.
Disadvantages
• Complex to set up, requiring input from the
business as well as support, functional and
technical consultants.
• As this is a complex solution it’s likely to
be expensive in terms of man hours.
• There may be legal requirements to retain
data for six years.
• Without detailed investigation it is difficult
to estimate how much data could be
archived. It is therefore difficult to estimate
how much client refresh times may be
reduced by.
• Data archiving would need to be a periodic
process as the volume of data in the
Production system is always growing.
SAP Infrastructure Investment
Many SAP customers will choose to update
their infrastructure and hardware over the
lifetime of their SAP systems in order to
benefit from the enhanced performance of
modern servers and processors. This
investment can make it possible to speed
up existing client or system copy methods.
Client copy and system copy times are
physically limited by a number of factors
such as:
• Speed and number of processors on
both source and target server.
• Amount of installed memory on both
source and target server.
• Speed, number and configuration of hard
disks on both source and target servers.
• Speed of network interface between
source and target servers.
In order to fully determine where bottlenecks
currently exist, the Production and Quality
Assurance systems need to be closely
monitored whilst a client refresh is in
progress. Where bottlenecks are identified,
targeted configuration or hardware upgrades
can be investigated with a view to improving
overall performance. Hardware vendors can
also provide modern disk technologies to
allow “snapshots” of live data to be taken
and replicated which would combine part of
the system copy method with a hardware
investment.
Advantages
• Has the potential to reduce current client
copy times.
Disadvantages
• Any gains in terms of reduced client
refresh times are likely to be short term as
copy times are always increasing. It is
impossible to estimate how much time can
be gained using this option until the
investment has been made and the
benefits measured.
• Depending on where bottlenecks currently
exist this may be an expensive option. For
maximum benefit bottlenecks should be
addressed on the Development, Quality
Assurance and Production.
A Guide to SAP System Refreshes | 9
 Specialist System Refresh Products

There are a variety of products on the Gamma InfoShuttle Advantages

market now that are specifically designed
to solve the problems that SAP customers
face, which do not require the Quality
Assurance or Development systems to be
refreshed.
InfoShuttle is a third-party SAP certified
solution which offers a systematic method
of building test or training scenarios with
current data from a Production system.
Transferring relational sets of data,
InfoShuttle generates the building blocks
for Production-like systems. As this can be
performed on a selective basis, InfoShuttle
dramatically reduces the time taken to
build useful Production-like environments.
It is this selective nature of InfoShuttle that
offers benefits over the current whole client
refresh strategy.
InfoShuttle requires no dedicated hardware
as it essentially runs inside the SAP
system.
InfoShuttle uses built-in mechanisms to
select, check, move and synchronise data
between environments through a standard
SAP interface via its own SAP transactions.
InfoShuttle transfers are performed using
selective hierarchical sets of master and
transactional data, which automatically
detect and include related objects. As a
• Allows support and project teams to build
their own reduced size test data sets.
There is no requirement to involve
technical support to perform refresh
activities.
• Offers a solution to copy data back to
both Quality Assurance and
Development system clients.
• Allows specific Production data to be
copied back to Quality Assurance or
Development clients so it can be
investigated by support staff.
• Allows specific Production problems to
be investigated in non-Productive
environments without impacting on the
testing activities of other support
analysts.
• Offers additional flexibility and features
over the alternatives discussed here,
such as the ability to perform data
transfers to non-SAP R/3 systems via
XML files.

Disadvantages
result, setting up the transfer can be done
by the analyst who needs the data: i.e. the
functional analyst, developer or user
acceptance tester. InfoShuttle requires no • As a software-based solution, Infoshuttle
Production downtime from a business user is a more expensive solution than
perspective. hardware-based options. The benefits
accrued, however, are likely to be
There is no requirement for the support proportionately greater due to the
and project users to be experienced with flexibility that the tool offers.
the technical aspects of SAP’s data transfer
technologies. Data can be moved easily by
knowing key elements, like Sales Order
Number, Customer Number or Material
Number. Since the amount of data defined
within a data sub-set is smaller than the
complete database, it requires less disk
space in the target system, which reduces
storage requirements in the non-
Production environments.

For non-standard data objects or

relationships, such as enhancements or
Z-tables, InfoShuttle provides tools that
facilitate the creation of custom transfer
objects. The linking, done through drag
and drop, generates ABAP code that
retrieves the Z- table entries from the
source and directly updates or creates the
same Z- table entries in the target system.

10 | A Guide to SAP System Refreshes

AP Test Data Migration Server (TDMS)
SAP’s Test Data Migration Server (TDMS)
product allows customers to extract
transactional data from a Production
system whilst retaining the master and
customising data of the target test system.
The transactional data can be configured
to extract all data within a given date range.
The TDMS requires its own separate SAP
instance. It is based on a Web Application
Server 6.40 platform and therefore requires
its own hardware with a minimum 4 Central
Processing Units, 4GB of Random Access
Memory and 20GB hard disk storage for
the database. The TDMS instance does not
store the data in its own database, rather it
uses its memory to filter and pre-process
the data prior to copying it to the target
client.
In order to make use of TDMS you would
need to order the basic TDMS service
offering from SAP’s consulting services.
This offering consists of an initial one day
scoping workshop, a ten day project to set
up the TDMS server and a final day’s
workshop where the operation of the
TDMS server is reviewed.
Advantages
FINDING A
• Enables reduced dataset transfers to
refresh the target clients.
SOLUTION THAT FITS
It is clear that there are several options
• Caters for individual client refresh giving
available that will address the challenges
a solution that supports multiple test
posed by system refreshes. Some of these
clients in both the Quality Assurance and
options are low cost alternatives that come
Development systems.
with their own set of disadvantages, and
Disadvantages
some require additional investment but
offer increased flexibility.
• Requires its own dedicated hardware.
In terms of the most complete solution,
InfoShuttle offers the best features as a
• Transactional data can only be selected
toolset. Of course, these advanced
by date range. There is no option to
features do carry a cost, however they
select data by object type such as
would allow support and project users to
Purchase Order.
pull back the sub-sets of data they require
to facilitate their testing. The current
• The product is geared towards system
segregated client model would remain in
administrators with a technical
place and no additional hardware would
background and would likely not be
need to be procured or managed. As the
suitable for general use by support
support and project teams would be
analysts.
managing their own test data it would
remove the need to involve technical
• Requires the use of SAP’s dedicated
support. This would lead to a faster
consulting group who will charge for the
turnaround of both support and project
initial system setup.
activities as analysts would have access to
the data they needed whenever it was
• This is likely to be an expensive offering
required.
once consulting, hardware and licensing
costs are factored in.
For SAP customers who do not want to
invest in additional software, the system
copy method may be the best solution as it
is fully supported, reliable and faster than a
client copy or the continual archiving of
data.
However, individual SAP customers must
weigh up the costs and benefits of all the
options outlined in this paper and choose
the one they feel best fits their business
requirements.
Absoft has over twelve years experience of
working with SAP customers to implement
and optimise their SAP system landscapes.
Since each SAP system is different and
comes with its own unique set of
challenges, Absoft works in partnership
with its customers in order to fully
understand their system landscape and
plan maintenance and refresh strategies
that will provide the best solutions for both
the IT department and the business now
and into the future.
To find out more about how Absoft work’s
with SAP customers visit
http://www.absoft.co.uk/
workingwithabsoft
A Guide to SAP System Refreshes | 11
50 087 696 (07/12)
©2008 SAP AG. All rights reserved. SAP R/3, mySAP,
mySAP.com, SAP TDMS, and other SAP products and
services mentioned herein as well as their respective
logos are trademarks or registered trademarks of SAP AG
in Germany and in several other countries all over the
world. All other product and service names mentioned are
the trademarks of their respective companies. Data
contained in this document serves informational purposes
only. National product specifications may vary.

These materials are subject to change without notice.

These materials are provided by Absoft for informational
purposes only, without representation or warranty of any
kind, and Absoft shall not be liable for errors or omissions
with respect to the materials. The only warranties for SAP
Group products and services are those that are set forth
in the express warranty statements accompanying such
products and services, if any. Nothing herein should be
construed as constituting an additional warranty.

Unlocking Business
Potential with SAP®
Software Solutions

Absoft Limited Tel: +44 (0) 1224 707088

Davidson House, Campus 1 Fax: +44 (0) 1224 707099

Web: www.absoft.co.uk
Aberdeen Science & Technology Park E-Mail: info@absoft.co.uk
Bridge of Don, Aberdeen, AB22 8GT