Example: Partitioning of an Infostructure

You have an infostructure that already contain many entries and the corresponding ZARIX table is getting too large. The infostructure has not been partitioned, and you want to do so now.

You want to change the infostructure in such a way that no more data is written to the current table. You also want to configure partitioning so that the data for the current year (2005), the past two years and the coming three years is written to separate corresponding tables.

To do so, you use the following procedure:

       1.      You configure partitioning in the development or Customizing system (the system in which you make the developments and changes that are not permitted in the production system) in the following manner:

From Date

Table Name

01.01.0001

01.01.2003

01.01.2004

01.01.2005

01.01.2006

01.01.2007

01.01.2008

       2.      You transport these settings to the production system. It does not matter whether you enter the changes from the configuration of partitioning in a transport request, or transport the infostructure from a different place. It is always the complete definition of the infostructure that is sent to the target system.

       3.      You continue to archive as usual in the production system.

After the transport of the configuration settings into the production system, the partitioning of the infostructure looks as follows:

From Date

To Date

Table Name

Change Date

G

R

01.01.0001

12.31.9999

ZARIXBC62

X

The infostructure is still not partitioned. Table ZARIXBC62 is the already very large database table for the infostructure. As long as no new entries are included in the infostructure read accesses only take place from this table. The system generates and then fills the new table only when the infostructure is filled again. You are certain that the system does not insert any data into the "old" table, because the partitioning configuration covers the entire time available period. After another archiving session the partitioning could look as follows:

From Date

To Date

Table Name

Change Date

G

R

01.01.2005

12.31.2005

ZARIXBC64

06.28.2005

X

01.01.0001

12.31.9999

ZARIXBC62

X

The system has now generated the table ZARIXBC64 for the time period between 01.01.2005 and 12.31.2005 specified in the partitioning configuration. In 2006 the system would create the next table. Read accesses occur from both tables.

You now have two options for proceeding: You either use partitioning only for new entries in the infostructure or you use partitioning also for older entries.

...

·        Partitioning only for new entries

In this case you do not need to do anything else. New entries are automatically written to the infostructure based on your partitioning configuration. When you delete older data from the infostructure the system recognizes that these entries are still in the old table ZARIXBC62. After the infostructure no longer serves any of the old files, table ZARIXBC62 is empty and the partitioning is exactly as configured.

The configuration information concerning the time periods before 2005 are not needed in this scenario.

·        Partitioning for all entries

If you want that partitioning corresponds exactly to the configuration settings also in the case of older files, you must delete and rebuild the infostructure for all old sessions. In this case the system also uses the configuration entries for the periods before 2005 and generates the corresponding tables.

This procedure is not necessary and we do not recommend it. It is only necessary if you notice that the old table is too large to handle, even when no new entries are added to it.

It is possible for you to combine both methods all at once, or implement them in partial steps.

You can remove empty tables after you have switched to partitioning by deactivating the infostructure and reactivating it immediately. As a result the system deletes any extra tables that are not needed.