The use of SAP systems by many users — thousands in some
cases — leads to the creation of enormous volumes of data. At times,
data volumes can even fall in the terabytes range. In order to guarantee
efficient use of storage devices, CPU, memory, and other resources, and,
more important, to ensure acceptable levels of system availability and
throughput, data archiving is performed to relocate data objects from
the online database to external storage media, all the while enabling
read access to that relocated or “archived” data.1
The archiving decisions involved in the planning process are not black-and-white
technical decisions. An “old” document from the perspective
of the technical team may not be an “old” document in the
eyes of a user who can’t bear to see that document relocated from
the online system to an archive file.
Decisions like this require tradeoffs,
because once data is archived, it cannot be changed. Technical teams must
therefore be prudent about the data objects they choose to archive. Just
because it’s technically feasible to archive an object doesn’t
mean it’s wise to do so.
Also, don’t let the technical ease
with which data can be archived lull you into a false sense of security
— it’s not enough to use SAP analysis tools2
to locate large or fast-growing tables, run transaction DB15 to identify
the archiving objects, and then run the archiving programs. This is not
a sound archive plan! These actions only touch the surface of the broader
technical issues involved (see Figure 1), including:
|What is the best storage medium for archive files?
||When making this decision, take into account the existing hardware
environment, scalability, integration into existing storage media,
|Is a content management system (CMS) in use? Is it necessary to
integrate the archiving project with any “imaging” projects?
||Investigate whether a content management system (CMS) should be
used for storing archive files and for storing scanned-image documents.
If yes, store archive files together with scanned documents, print
lists, etc. in the CMS (for central storage of files, easy administration,
|How can the required access time be realized?
||For fast access (within a few seconds), configure the AS infostructures
and choose appropriate storage media (for example, magnetic disks,
network equipment, etc.).
|| Examples of Technical Considerations When Planning for Archiving
- Which data objects are “old” (i.e., rarely accessed in
display mode) and can be relocated
- The business processes that require access to the data objects you
plan to archive (even though we’re talking about data objects
belonging to closed business processes,3
this is still a key consideration)
- Whether there are previous or subsequent documents referenced by
the data objects to be archived
- How the archived data is to be accessed
While such user-focused technical considerations
are critical, they must also be accompanied by careful consideration of
business, legal, and auditing requirements for your archiving planning.
For examples of some of these issues, see Figure 2.
When considered together, these facets of
your planning can make or break an archiving
|Is it necessary to reconstruct the business process context for
the affected data objects?
If yes, configure the Archive Information Server (AS) for all
involved archiving objects.
If no, configure the AS only for the relevant archiving objects.
|What search criteria are needed?
||Ask end users which search fields are required for accessing archived
data objects, and define archive information structures (infostructures*)
using those search fields.
|What data (fields) must be accessed?
Evaluate whether this information is displayed in business views.
If not, show end users that the information can still be accessed
through technical views within the AS.
If neither is possible, modify existing business views by copying
them into the customer namespace.
|Is reusability a requirement? Will it be necessary to create a new
document based on a template in the archive? (Note that only very
few objects support the “create with reference” functionality.)
||If yes, archive only data objects for which this requirement can
be ruled out by setting a high residence time (the length of time
data stays resident in the online system before it can be archived).
|Will it be necessary to carry out statistical analysis on the archived
If yes, carry out the analysis before archiving, while data is
still in the database.
If BW is in use, transfer data prior to archiving.**
|Legal and Auditing Considerations
|Do internal auditing or controlling departments require access to
archived legacy data?
||If yes, investigate which fields are affected and demonstrate the
possibilities for accessing this information (business views, technical
views, AS archive information structures).
|Which fields and what information must remain accessible for reasons
of product liability?
||Evaluate whether these fields should act as search criteria. If
yes, include the fields in the AS infostructure. Configure the infostructure
with the appropriate fields for emergency cases in order to activate
and fill them.
|What country-specific regulations require data to be stored accessibly?
(In this scenario, accuracy, completeness, and consistency play an
||Legal requirements vary from country to country, so it's best to
ask and incorporate the information from the subsidiaries in the affected
* A database table that contains a
pointer to the position of an archived data object in the archive
** At present, SAP provides extractors to enable
the BW to process archived data. The relevant functions for loading
archived OLTP data into the BW will be generally available soon,
enabling archived data to be loaded into the BW at a later point
in time (for example, if a BW is implemented and used sometime in
|| Examples of Legal, Auditing, and Business Decisions When Planning
1 This article
is excerpted from Rolf Gersbacher’s
full article “Adequately Account for
Business Requirements and Avoid
Archiving Anarchy” in the January/February
2003 issue of SAP
Professional Journal, and reprinted here with permission of the author
and publisher. For more information on ordering single copies, visit www.SAPpro.com.
2 SAP has developed the Document Relationship Browser
(DRB) and the Archive Information System (AS) to provide users with read
access to archived data.
3 A business
process is considered “closed” when
the last business transaction has taken place.
Rolf Gersbacher joined SAP in 1994,
where he was engaged in the implementation
of business process reengineering projects
using workflow technology. Since 1998 he
has been a member of SAP’s Performance,
Benchmark and Data Archiving (PBA) department,
where he is responsible for conducting
extensive analysis and has co-written projects
in the area of data archiving. Together
with Helmut Stefani, Rolf developed the
best practices guide “Managing SAP
Data Archiving Projects,” which has
become the vade mecum for data archiving
issues. He can be reached at firstname.lastname@example.org.