Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
mpreddy_mettu
Explorer

Applies to:

SAP BW NW 7.X. For more information, visit the Business Intelligence home page for Data ware house management.

Author:          MP Reddy

Company:      NTT DATA Global Delivery Services Private Limited

Created On:   4th August 2015


Author Bio  

Pitchireddy Mettu is a Principal Consultant at NTT DATA Global Delivery Services Private Limited from the SAP Analytics Practice.


Summary

In one BI system, the volume of data increases constantly. Constant changes to business and legal requirements mean that this data must be available for Longer. Since keeping a large volume of data in the system affects performance and increases administration efforts, we recommend BI administrator to apply Data archiving task if needed.

Using the archive administration for the archiving object BWREQARCH we execute an archiving program. This program writes the administration data for selected requests in an archive file. After archiving,we execute a deletion program that deletes the administration data from the database.

By archiving request administration data we make sure that the request administration data does not impair the performance of our system.

This guide gives a step-by-step demo to show how to Achieving BW Requests using BWREQARCH and reloading Achieved requests when needed.

Prerequisites

In our case the settings are already maintained for the object that we are archiving on the SAP BW system.

The objects that are archived are:

  • BWREQARCH
  • IDOC
  • WORKITEM

The checklist of archiving new objects is as followed

Process Flow

Before using an archiving object for the first time

  • Check archiving object-specific Customizing settings:
  • Was the file name is correctly assigned?
  • Are the deletion program variants maintained? (Note that the variants are client-specific)
  • Is the maximum archive file size correctly set?
  • Is the deletion program to run automatically?

File locations


File locations must be set in order to write the archive files. Currently the files are located in /local/data/storage/<SYSEMID>/archiving.

The section below explains the setup of the files. Unless specified by the support lead DO NOT CHANGE ANY OF THE SETTINGS.

This can be accessed via AL11 .

File Names

The file names are generated automatically by the archiving tool. The current setup is as followed:

For BWREQARCH the customizing shows that ARCHIVE_DATA_FILE is used.

The ARCHIVE_DATA_FILE has the mask <PARAM_1>_<PARAM_3>_<DATE>_<TIME>_<PARAM_2>.ARCHIVE
and uses the logical path ARCHIVE_GLOBAL_PATH

PARAM_1 = Type of system

PARAM_2 = Sequence number

PARAM_3 = Archiving Object

Archiving
  Object

PARAM_1

PARAM_2

PARAM_3

BWREQARCH

BW

0

BWREQARCH

The ARCHIVE_GLOBAL_PATH is set to /local/data/storage/<SYSID>/archiving.

In AL11 you can view the files created.

Archive BW Requests

When archiving requests there are two steps to perform.

  1. Write the archive files
  2. Delete the data from the tables

Write the archive files


Start transaction code SARA - Fill in BWREQARCH

First we need to write the archive log files.
In order to this we need to create a variant of what needs to be archived.

When installing a regular job we need to make the timing relative to the date. By default we archive requests older than 4 months.

For a test run you can put the processing option to Test Mode, for actual archiving you can put the processing option to Production Mode. Keep With DTP Requests turned on as we also archive the DTP request information. Min. Number Requests will stay on 1000. This means that only if there are more than 1000 requests to archive it will actually start archiving.

Manual writing with SARA

When running the manual jobs make sure that the username is has the correct authorization to run archive jobs.

Create the archive file once all the settings (Spool Params& Date) have been maintained.

When the write is executed you can find the jobs running/finished.

There will be two jobs, one with SUB in the name that will schedule the various write job(s).
The other job will have WRI in the name.

Delete the data from the tables

When the request are writing into the archive files. The data can be deleted from the tables.

The next chapters will provide details on how to delete the BW-Request data once the archive files have been written.

Manual deletion with SARA

  Return to SARA and select Delete.

  Click on Archive selection to select the file for deleting the actual entries from the table

When file is selected enter the start data for deletion of the entries from the table. Periodic scheduling only makes sense when the write
job is dynamically deleting the requests. As we are deleting once a month on a 4 month basis we can schedule the delete also periodically.

Be aware that the delete should not run during the write job and that there is enough time between the two activities.

When all settings (Spool params.and scheduled date) are maintained you can run the deletion job.

In the job overview you should see a deletion job running/finished.


Reloading Archived Requests

When the requests are archived they are still accessible when needed if

There are three ways of reloading the requests

  1. Reload the individual request from the DTP monitoring screen or InfoPackage monitoring screen
  2. Reload a complete archiving job (T-Code SARA)
  3. Reload multiple requests (T-Code RSREQARCH)

For reloading complete archive jobs or multiple requests look further down in the documents. The following sections shows how individual
requests can be reloaded from the archive.

Reload the individual request

Before retrieving the request from the archive, question yourself if the detailed data is needed. The header information of the request is still visible, only detailed messages are archived.

InfoPackage Requests

When displaying the request in the monitoring screen a popup will inform the user that the request is archived with a question to retrieve
the details from the archiving. By default do not reload the details when looking at an archived request unless it is really necessary.

  An archived requests looks like this:

  When an request is reloaded the data becomes visible again

DTP Requests

When displaying the request there will not be a popup compared to InfoPackage requests. On the DTP overview screen you will see that the DTP is archived.

By default the details will not show the details.

On the menu you can reload the request from the archive.

When the data is reloaded the details become visible again.

Reload a complete archiving job :

When you want to reload a complete archiving job you have to reload is within T-Code SARA.

Run SARA and put in the archiving object. In the menu the Reload function becomes available.

  Select a variant. There will be only two necessary variants as the selection screen will only give you option Test or Production mode.

Select an Archive file.

Maintain the start data and spool parameters like in the previous sections and run the reload activity.

The job log will show if the reload has finished.

A job with REL in the name will run.

Related Content


http://scn.sap.com/docs/DOC-30539

http://scn.sap.com/thread/1944220


http://www.sdn.sap.com/irj/sdn/go/portal/prtroot/docs/library/uuid/70ef2f01-641a-2d10-c59e-cf6d9e673...

https://help.sap.com/saphelp_nw73/helpdata/en/49/9500f79c1d311fe10000000a421938/content.htm

For more information, visit the Business Intelligence home page for Data ware house management.

2 Comments
Labels in this area