How to reduce the size of tables in the SAP system

    Recently retired from the St. Petersburg Center for Expertise SAP, an excellent company. He was mainly engaged in archiving and installation of Solution Manager.
    I’ll write a few introductory words about what archiving is in the SAP system. I don’t give out any secret information, everything that I wrote can be found on two main resources that can answer almost any question on the SAP help.sap.com and sdn.sap.com systems, and I will also refrain from evaluating the characteristics of functionality.

    Let's start with the basic approaches to managing the size of a Database (DB) in SAP systems.

    You can take care of the size of the database in several ways:
    1. Reduce the amount of data recorded in the database. Those. Either summarize the data that is not necessary for the business to such a degree of detail, or do not write it to the database at all if this data is unnecessary and is not used now and will not be used later.
    2. Reduce the amount of data already written to the system. This can be done either by archiving some of this data using special archiving objects, or simply deleting it using special programs, or in some cases deleting a table and creating it in the database again.

    Main differences:
    In the first case, the effect is achieved by customization of the system, in the second - by specific measures.
    In the first case - the effect extends only to new data that is written to the system, in the second - only to data that is already in the database.

    How to understand whether it’s time to do something with the data or not?
    If you think about it, it comes to a few reasons for the company to think about reducing the database:
    1. The company has free resources in the form of consultants, money or enthusiasm in order to take care of the growth of the database.
    2. The execution time of key transactions has increased or the database has reached an impressive size, in connection with which the company is seeking resources to solve the problem.
    3. The company approached the implementation of SAP thoroughly, and thinks about the growth of the database at the design stage.

    What is the advantage of developing a database size management strategy at the design stage:
    1. If from the very beginning you decide the question what data is needed in the system, which data is not available, and what data can be archived or periodically deleted by the planned job at the design stage, in many cases the database will grow much more slowly.
    2. Actually save on disk space for storing the database.
    3. Save time on deleting or archiving unnecessary information that will already be recorded in the database after a productive start.
    4. The moment when you need to invest in more powerful processors for the database will be postponed for some time due to the same reduced amount of processed data.

    As I mentioned earlier, you can do a lot with the data, depending on the available functionality: delete, archive, summarize or not write to the database at all. I will dwell on archiving in more detail, because many legends go about her.

    What is archiving in the SAP system?
    Archiving is inextricably linked with the archiving object - a logical unit that combines the available programs and the logic of data archiving. He will make sure that the data after archiving in the system remains consistent.

    The archiving process consists of 2 steps:
    1 step- Launch a recording program. An archive file is created and information from the database is written to it. At this step, nothing is deleted from the database! Records are created that duplicate the information stored in the database that we are going to archive.
    Step 2 - Run the uninstall program. The program reads the data in the archive file, verifies this data with the data in the database, and then, if it matches, deletes the data in the database.

    What you need to know about data in archive files:
    1. Access to data in an archive file is possible! For some modules (such as FI and CO), with proper configuration when accessing documents, you may not notice at all that the data is archived. Those. this data has not been erased, it can be accessed!
    2. The reverse loading of data from the archive file into the database is not recommended and in some cases is not possible.
    3. Data is read-only, not editable.
    The main transaction for working with archive objects is SARA. Almost all the functionality for working with the archive object, with the exception of some settings, is available in this transaction. Archiving is done right here. I will tell you more about archiving, other related functionality and principles in the following parts, if I see interest in this topic on the resource.

    Also popular now: