Académique Documents
Professionnel Documents
Culture Documents
Page 1 10/27/2011
TABLE OF CONTENTS
1. INTRODUCTION.................................................................................................................................4
1.1. DOCUMENT OBJECTIVES...........................................................................................................................4
1.2. SCOPE....................................................................................................................................................4
1.3. LIMITATIONS...........................................................................................................................................4
1.4. PRE-REQUISITES.......................................................................................................................................4
2. WHY DATA ARCHIVING..................................................................................................................4
2.1. IMPROVED SYSTEM PERFORMANCE..............................................................................................................4
2.2. INCREASED SYSTEM AVAILABILITY.............................................................................................................4
2.3. COMPLIANCE WITH RETENTION POLICIES.....................................................................................................5
2.4. EFFICIENT USE OF RESOURCES..................................................................................................................5
2.5. EASIER DISASTER RECOVERY....................................................................................................................5
2.6. LEGAL COMPLIANCE................................................................................................................................5
2.7. UPGRADE COMPATIBILITY..........................................................................................................................5
2.8. MOST RELIABLE METHOD FOR DATA RETIREMENT..........................................................................................5
3. CONSIDERATIONS IN ARCHIVING DATA...................................................................................6
3.1. DATABASE SIZE AND GROWTH....................................................................................................................6
3.2. CORPORATE DATA RETENTION POLICY........................................................................................................6
3.3. DATA MANAGEMENT STRATEGY................................................................................................................6
3.4. MAINTENANCE ISSUES..............................................................................................................................6
3.5. SUPPLEMENTARY SOLUTIONS......................................................................................................................7
3.6. INTEGRITY OF DATA.................................................................................................................................7
3.7. LEGAL AND TAX REQUIREMENTS................................................................................................................7
3.8. PROJECT COST CONSIDERATIONS...............................................................................................................8
4. THE RIGHT MOMENT.......................................................................................................................8
4.1. EARLY ARCHIVING..................................................................................................................................8
4.2. LATE ARCHIVING....................................................................................................................................9
4.3. THE RIGHT MOMENT...............................................................................................................................9
5. ARCHIVING PROJECT – WHAT DOES IT TAKE?.....................................................................10
5.1. BUILDING THE PROJECT TEAM.................................................................................................................10
5.2. PROJECT TASKS AND TIME LINES ...........................................................................................................11
5.3. RESOURCE REQUIREMENTS.......................................................................................................................12
5.4. IMPLEMENTATION COSTS........................................................................................................................13
5.5. MAINTENANCE COSTS............................................................................................................................13
5.6. SAVINGS AND COST REDUCTION................................................................................................................13
14
6. CRITICAL SUCCESS FACTORS.....................................................................................................14
Page 2 10/27/2011
6.1. EXPERIENCED PROJECT TEAM..................................................................................................................14
6.2. INVOLVING ALL EFFECTED PEOPLE.............................................................................................................14
6.3. COMMUNICATION AND CHANGE MANAGEMENT..........................................................................................15
6.4. TOP MANAGEMENT COMMITMENT............................................................................................................15
6.5. PROJECT MANAGEMENT EXPERTISE..........................................................................................................15
6.6. RIGHT RESIDENCE AND RETENTION TIMES..................................................................................................15
6.7. CORRECT SEQUENCE OF OBJECTS..............................................................................................................15
7. LIMITATIONS OF DATA ARCHIVING.........................................................................................15
7.1. DATA ARCHIVING IS COMPONENT SPECIFIC................................................................................................15
7.2. NOT SUITABLE FOR REMOVING ORGANIZATIONAL UNITS................................................................................16
8. GLOSSARY.........................................................................................................................................16
Page 3 10/27/2011
1. Introduction
1.1. Document Objectives
The process of decision making involved in selecting the right Data archiving solution
can get complex with the multitude of variables effecting the decision as well as the
options available. This document is intended to assist in analyzing and evaluating
different issues involved in selecting an archiving solution for SAP R/3 Data. It is also
intended to assist in understanding Key challenges involved in Data Archiving projects.
1.2. Scope
This document discusses the main drivers in deciding to go for SAP data archiving. An
attempt is made to highlight various considerations for and against Data Archiving. It
also highlights the benefits of archiving on the one hand and the costs involved in
implementing it and the limitations of SAP data archiving.
1.3. Limitations
Every organization operates in a unique environment and hence the considerations
would also be different. It is not possible to set a standard cost benefit equation that
would be applicable to all situations. However, the issues discussed in the document
could help as a guideline to develop one.
Data Archiving in the context of SAP R/3 system is only addressed in this document.
Technical issues and solutions related SAP data archiving are not covered in the
document.
1.4. Pre-requisites
Basic understanding of SAP R/3 system, it’s functioning, components and architecture is
essential to understand the issues discussed in document. It would also be useful for the
reader to have awareness of the SAP Data Archiving.
Page 4 10/27/2011
Reduced database size would make it easier to maintain the database. The stop and re-
start time would be less and the maintenance windows could be smaller.
This is mainly due to the operations that require the application system to be shut down,
or the need to deny end user access to certain areas temporarily. These delays could be
worse when upgrading to a newer software release or when recovering data after a
system crash.
Certain data like Financial Accounting documents need to be retained for a long time to
comply with legal requirements. This could be easily achieved without effecting system
performance by archiving the data and storing it outside SAP system.
Less data would mean less programming, less testing and not having to worry about
getting every bit of computer horsepower working together to get it moved as fast as
possible.
Page 5 10/27/2011
system and is supported by SAP. Standard SAP system consists of archiving objects to
remove data from almost every application area, especially those with high growth rates.
SAP also ensures integration of data retrieval with standard business transactions in
many cases. This helps to accomplish the goals with least or even no development
work.
Inefficiencies in software code may not show up in smaller databases, but my cause
huge problems in large SAP databases, where you are trying to squeeze every
performance efficiency possible.
Performance issues and performance tuning activities take up significantly more time if
the database size is huge.
The requirement for data may vary from management reporting to Legal requirement to
keep the data. Different options are available to suit these varying requirements like
Data warehouse, Near-line storage systems etc., and a comprehensive data
management strategy helps to address these in totality.
The more the data, the longer it takes to stop and restart the database. Consequently
the down time would increase in proportion to the growth in database size.
Large tables like COEP, BSIS are difficult to be reorganized because they cannot be
exported/imported in the allowed maintenance windows. This causes slower response
on the system because the tables cannot be reorganized.
Page 6 10/27/2011
There is more maintenance involved if the database volume is large. For example, you
may have to work with many disk packs instead of a few during any kind of file system
maintenance.
The volume of SAP data directly relates to the amount of time it takes to refresh
production test environments. Additionally, it takes much longer to apply new
functionality to the database.
Steady growth of database would require frequent upgrade in system resources like
servers, networks etc. It would be hard to move to a different hardware platform, since a
different hardware platform means you have to export the database and import it. Even
with faster hardware it would still take multiple days to move.
Storing Archived data could be done using SAP Content Management Service (CMS),
HSM systems etc. Archive link interface facilitates storing of archived data in external
storage systems. Storage solutions provided by IBM’s Commonstore are highly
compatible with SAP, also satisfy the legal requirements for storing archived data.
Retrieval of archived data is another area where many supplementary solutions are
available. Solutions are available from vendors like PBS software, which highly integrate
the archived data with the SAP standard retrieval transactions. Other solutions like
CDART enhance the functionality provided by SAP, especially in data retrieval.
Using SAP Data Archiving, important business objects such as accounting documents
and material master records can be selectively removed from the database in such a
way that the user does not have to worry about the underlying physical table design.
Page 7 10/27/2011
Generally auditing or controlling department helps to identify the legal requirements of
the archived data from the legal point of view. Country-specific considerations and
additional requirements for external audits must also be taken into account.
Each and every organization has unique dynamics, external and internal, and it is not
pragmatic to apply a common yardstick to all situations. Various components affecting
the cost of an Archiving project is explained in Point 5.
Even before a system or a process is live, the cumulative data quantities should be
estimated for the future. Conversely, unnecessary problems and costs arise if archiving
is only carried out to resolve performance and administrative bottlenecks.
Ideally, Data Archiving should be considered in the early stage of the SAP R/3
implementation during the sizing phase. Data Archiving is primarily a preventive tool for
keeping the database healthy and fit. It cannot be expected to return a database to high
performance state after all other resources are exhausted.
The employee responsible for the application or process knows the business processes
and is familiar with the data objects that are linked with those processes in R/3. In almost
all cases, it is possible to estimate the number of documents and quantity of
accompanying data. Together with knowledge of the existing system, the decision to
implement data archiving can therefore be made at an early stage and the necessary
steps implemented, such as setting up a plan for regular archiving.
Page 8 10/27/2011
4.2. Late Archiving
In this scenario, the aim is to stabilize and reduce database volumes. This situation
occurs when performance or administration problems arise due to large data volumes. If
you are already experiencing system bottlenecks, you will experience the following
additional problems when archiving data:
⇒ Longer runtimes for the archiving programs
⇒ Additional system load caused by archiving
Data archiving requires more than just the physical removal of data from the database. It
is necessary to involve all of the groups involved in carrying out a joint analysis and
creating a requirements catalog.
In the first instance, this involves gathering information on the size and growth rate of database
tables. A second step involves identifying the archiving objects that are assigned to these tables.
Next, the data objects are then checked for archival status and to determine what requirements
are to be placed on the archived data.
Designing the archive involves incorporating the requirements that have been identified during
the analysis phase in a uniform archiving concept and setting up a concrete archiving plan.
During implementation phase, the data objects that are no longer required are removed from the
database according to the previously created implementation plan.
• Could be beneficial to monitor the growth for a while after implementation and start
archiving
• Slower system response time makes all online users less efficient
Page 9 10/27/2011
First, from a business point of view , there are many archiving objects that can be used
as soon as the initial implementation is completed e.g. WORKITEM, IDOC etc Second ,
application areas or tables can grow very quickly and reach a significant size in a very
short time, even if the database grows moderately.
It is usually the case that within 1-2 years from the time of R/3 system going live, the
data required online in the R/3 system nearly stagnates. This is primarily because most
of the data stored in the system on closed business transactions are not required to be
accessed except in exceptional circumstances.
The following Chart highlights the volume of data created by the R/3 system which is not
required to be maintained online. This is based on the assumption that:
1400
1200
1000
Size in GB
800
600
Not Needed
400 Online
200
Needed Online
0
1 2 3 4 5 6 7
Year
Within 3 years from going live about 50 % of the data is generally not required online
and by the sixth year 3 out of four records is found to be achievable. The equation might
vary based on addition of functionalities implemented, change in volume of business and
specific requirement for online access to data.
Page 10 10/27/2011
which the data objects are embedded in order to understand the consequences of
archiving. As some application objects are used in cross-application process chains, the
persons responsible for individual applications should be involved in the archiving
project.
The exact composition of the groups will vary according to the size and the internal
organization of the enterprise. The following groups are possible participants in archiving
projects.
• Database administration
• R/3 System administration / BASIS
• Finance and Controlling
• Internal auditing department / External auditing
• Information management and retention team
• Persons responsible for the application
• External service providers, such as consultancies
• SAP Remote Archiving Service
Page 11 10/27/2011
• Execute archiving
• Post processing
• Database re-organization
• Project close
It is assumed that the organization has only the main SAP modules implemented and
the business complexity is average.
Page 12 10/27/2011
Stake holders ( Business blue - Business specific knowledge
to be available print - Data retrieval needs
through project Realization - SAP User experience
on part time Go Live - Legal and tax requirements
basis )
Considering the importance of data in today’s business , Data Archiving projects in most
cases considered as part of a enterprise wide Data Management Strategy. Corporate
Information management and retention policy also plays an important role in deciding
Page 13 10/27/2011
archiving of Data.
In a financial Cost Benefit analysis , the following are the key benefits accruing from data
archiving projects.
Data Archiving team has to have the right combination of SAP application, technical and
data archiving knowledge in addition to the business functional knowledge.
Understanding of the multitude of issues involved becomes critical in understanding
dependencies of data, retention times, archive triggers and deciding implementation
plan.
Page 14 10/27/2011
6.3. Communication and Change Management
Data Archiving projects effects almost every department in an organization, especially
with complex objects in CO like CO_COSTCTR. With far reaching implications, it is
important to give due priority to change management and communication aspects.
Deciding of retention times for data, introduction of new user interfaces to access
archived data are some areas where the change management and communication skill
of the project team would be put to test.
Another factor that adds importance to the commitment of top management is the fact
that, often, the stakeholders effected by an archiving project does not find anything in it
motivating them to give their commitment.
Page 15 10/27/2011
7.2. Not suitable for removing organizational units
Data archiving is not suitable for deleting organizational units from the system. This
operation could be requested if a plant or a company division is sold and the
corresponding data was no longer required to be maintained. Data archiving cannot
simply remove specific sub-areas from a system, because the archiving objects rarely
contain the exact data that needs to be removed.
8. Glossary
SAP Data Archiving
SAP Data Archiving is the process in which business objects such as accounting
documents and material master records are selectively removed from the database in
such a way that the user does not have to worry about the underlying physical table
design.
Archiving object
Set of interdependent business data that is periodically extracted from the current
system and archived according to individual criteria. E.g. FI_DOCUMNT (Financial
Accounting Document)
Optical archiving
Electronic storage and management of documents such as original documents, outgoing
documents, print lists in an external storage system that is usually based on optical
media (CDs, WORMS, and so on).
Reorganization
Reorganization refers to the restructuring of database tables with the aim of using
memory space efficiently.
Residence period
Period that must elapse before application data can be archived. The residence period
can be based on various application-specific data, such as creation data, posting period,
goods issue date. The period can be specified in days, weeks, months or years.
Retention period
Total period of time that data is held in the database including in an Archive. Data that
pass the retention time is considered expired and hence destroyed.
Restore
Rewriting the backup copy to the database to recreate the original sate of the database
after a system termination.
SAP ArchiveLink
Data interface that is embedded in the Basis component and that controls
communication with an external storage system. Enables access to stored documents
Page 16 10/27/2011
from the SAP application.
Page 17 10/27/2011