Updating SAP ABAP Systems on UNIX and Linux: SAP ASE

Planning the Data Management

This section deals with the management of large database tables using methods such as data archiving.

Context

The upgrade runtime – and in particular the system downtime – is extended when dealing with large database tables. Table conversions during the upgrade and data adjustments at the end of the upgrade are the most time consuming actions and can result in long upgrade runtimes. To avoid these problems, you should minimize the quantity of table entries that have to be converted prior to the upgrade. The best way to achieve this is to carry out data management measures such as archiving or deleting data records from the tables.

As part of an overall Information Lifecycle Management (ILM) process, data management is vital for maintaining a “healthy” live system because it helps to keep system performance high and to make optimal use of existing hardware resources. One of the most effective data management methods is data archiving. It allows administrators to remove data that is no longer needed in everyday operations from the database and store it in archive files. These files can then be passed on to a storage system for long-term storage. After archiving, the data can still be accessed in read-only mode when the need arises, for example, during an audit.

For more information about data archiving, see the blog https://blogs.sap.com/2014/04/02/sap-netweaver-information-lifecycle-management/Information published on SAP site.

Procedure

  1. Before the upgrade, analyze the database to find out which database tables can be reduced in size, and how this can be achieved.
  2. If you use the CRM Marketing Segment Builder, you can reduce downtime by deleting target groups in your system. Two secondary indexes of database table CRMD_MKTTG_TG_I are deleted during the upgrade and one existing secondary index is enhanced by additional fields. The Software Update Manager deletes this index and re-creates it during downtime. The time needed to re-create the index depends on the number of records in table CRMD_MKTTG_TG_I. As a guide value, for 10 million records, the recreation needs 200 seconds on an average performance hardware.
  3. Check the number of records in your CRMD_MKTTG_TG_I table and calculate the additional downtime. To reduce downtime, delete target groups in your system to remove entries from this table before you start the upgrade.