GRC
HR
SCM
CRM
BI


Article

 

Don't Overlook the Technical and Business Requirements for Moving Data to External Storage

by Dr. Rolf Gersbacher | SAPinsider

April 1, 2003

by Dr. Rolf Gersbacher SAPinsider - 2003 (Volume 4), April (Issue 2)
 

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:

Technical Considerations Possible Actions
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, etc.
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, etc.).
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.).
Figure 1 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 project.

Business Considerations Possible Actions
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 data?

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 Possible Actions
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 important role.) Legal requirements vary from country to country, so it's best to ask and incorporate the information from the subsidiaries in the affected countries.

* A database table that contains a pointer to the position of an archived data object in the archive file system.

** 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 the future).

Figure 2 Examples of Legal, Auditing, and Business Decisions When Planning for Archiving


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.


Dr. 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 rolf.gersbacher@sap.com.

 

An email has been sent to:






More from SAPinsider



COMMENTS

Please log in to post a comment.

No comments have been submitted on this article. Be the first to comment!


SAPinsider
FAQ