With any SAP system, an efficient data management strategy is an important aspect for maintaining good system performance and for keeping the storage cost of systems under control. Programs having to trawl through large volumes of unnecessary data can increase runtimes and delay important business processes; database backup storage requirements and runtimes increase with increased table storage.
The size of data has a direct impact on operational cost when you are on a consumption-based cloud environment. For SAP systems based on AnyDB, the costs are predominantly disk storage; for HANA-based SAP systems, this extends to memory.
If you’re considering a move of your SAP workload to a cloud environment, you will need to be mindful of storage costs. Reducing the size of the largest tables in a system being migrated to the cloud will reduce 1) the overall system downtime required to perform the migration, 2) the resulting storage footprint and, 3) the size of backups.
Within the SAP Basis Component, there are numerous opportunities to reduce the data footprint through avoidance (i.e. not creating the data in the first place) and deletion. This article discusses some of these as a taster of what’s possible.
Ensure that all SAP standard jobs are scheduled and running periodically up to and beyond the migration to ensure as clean a system as possible, i.e. jobs that reorganise ABAP short dumps, jobs and job logs, spool datasets, workflow trace, batch input, statistics and so on.
Review SAP Clients
Review the SAP clients that are defined in transaction SCC4 and verify that all of them are actually in use and required, especially in sandbox, development and test systems. Delete any clients that are deemed as unwanted. Do you still have standard clients 001 and 066 in any of your SAP systems as these may be candidates for deletion?
Changes to database tables are logged in table DBTABLOG if profile parameter “rec/client” is maintained and logging is switched on for specific tables in the data dictionary. In a production system, this logging is generally only switched on (flagged) for customizing tables and the volume of logged changes produced through these logs is not significant.
However, it may happen that tables are delivered (flagged) incorrectly by SAP or flagged by mistake by the customer. Experience from a previous customer migration project has seen instances of DBTABLOG exceeding 70GB in size. Check the SAP Support Portal for notes similar to the following if you see large volumes of data in DBTABLOG:
Avoidance: You can change the individual table setting in transaction SE11 by deselecting the “Log Changes” indicator in the technical settings for the table. If you decide to deactivate the logging mechanism for all tables (the entire system), you can simply set the R/3 profile parameter “rec/client” to OFF.
Deletion: Data in table DBTABLOG can be deleted using the ABAP report RSTBPDEL according to period (end date) and table. If the end date is selected, all change documents with the same end date or earlier are deleted from table DBTABLOG.
Application Log Tables
Analyse the SAP application log tables (BALHDR, BALDAT) to see if there is scope for removing any old log records. Application log entries are given expiry dates. These log entries must remain in the database tables until the expiry date has passed. After the expiry date has passed, the data can be deleted from the database tables. There are often a large number of application logs in the database because no expiry dates are assigned to the logs. You can recognise the log entries of this nature as they are given the large expiry date 31/12/9999 and will therefore never be eligible for deletion.
Avoidance: There are some possibilities for preventing log entries from being created in the first instance depending on the application area. After analysing the application log tables, you suspect one particular record type is occupying a large proportion of the application log, check the SAP Support Portal or other sources for any known issues or hints, e.g. transaction OMT0 for controlling application log creation during material master data distribution.
Deletion: SLG2 is the main transaction for the deletion of application log entries. Furthermore, report SBAL_DELETE can be scheduled periodically to delete expired and unwanted log entries frequently to keep growth in check.
Change Pointer Tables
Analyse the SAP change pointer tables (BDC, BDCPS) to see if there is scope for removing any old processed or obsolete change pointers, especially if BW is deployed and/or IDOC-relevant interfaces are running.
Avoidance: If you believe that change pointers should not be generated at all in your SAP system, deactivate their generation at the system level using transaction BD61. If you need to prevent change pointer generation for certain message types only, deactivate them accordingly in transaction BD50.
Deletion: Once an IDOC has been created for a change pointer, the change pointer is deemed to have been “processed” and is now considered “old”. These old processed change pointers can be deleted using report RBDCPCLR without any concern. Often, change pointers are never processed and so are never eligible for deletion, even though they are “obsolete”. Again, these obsolete change pointers can be deleted using report RBDCPCLR after careful consideration and discussion with the responsible functional consultant(s).
Review Temporary Sequential Storage (TemSe) Tables
The SAP TemSe storage can store temporary data such as spool requests and other transient datasets in the database or file system.
Ensure that spool requests which are no longer required are removed from the TemSe by scheduling the new improved spool reorganisation ABAP report RSPO1041 periodically. If after reorganisation, some old and potentially large spool datasets still exist, check their retention period as it may deviate from the default setting of eight days and may need special attention. Analysis from a recent customer migration project revealed spool tables exceeding 200GB in size out of a total database size of 1200GB, occupying approximately 16% of the database.
Ensure that the TemSe is consistent by scheduling ABAP report RSTS0020 periodically in the background or via SP12->TemSe Data Storage->Consistency check. As temporary inconsistencies may exist when business processes are running, repeat the check after 30 minutes and delete any inconsistencies that appear to be real.