Backup your way from SAP Netweaver to SAP NetZero

Written By - Arwel Owen | November 25th, 2023

SAP BASIS GURUS – Is your largest tablespace that big you’re faced with extra-long database backup times? Do you want to cut your backup times and open an opportunity to reduce your SAP CO2 emissions?

There’s a wonderful solution called Tablespace Pools for those of you fortunate enough to run SAP on Db2, which I’ve used to successfully slice around 75% from our SAP backup and recovery runtimes. Not only can it massively shrink your backup time, it can also reduce your SAP architecture’s carbon emissions by making more efficient use of CPU and I/O, and also providing you more flexibility in when you schedule your backups. Consider why you schedule your backups to run overnight when they could be running while the sun shines and the wind blows, and your electricity grid is powered by low-carbon, renewable sources.

Here’s how it works (words courtesy of IBM’s must-read Redbook “Db2 Optimization Techniques for SAP Database Migration to the Cloud”).

In an SAP on Db2 system, which uses a traditional tablespace layout, you will typically find 20 to 60 tablespaces. There might be more, or fewer tablespaces based on your individual system layout. Each table is stored within one of these tablespaces. Tables can be grouped together logically and assigned to dedicated tablespaces.

With the traditional Db2 tablespace layout for SAP systems this type of functional grouping is used by grouping master data and transaction data, for example. This layout typically results in a few large, tablespaces containing one or more large tables. However, this kind of unbalanced tablespace setup may result in some issues, for example increased backup run times.

The concept of tablespace pools implements a more even distribution of tables to tablespaces. In addition, the tablespace pool concept establishes a clear separation of regular, index, long field (LF), and large object (LOB) data into dedicated tablespaces. In comparison, a traditional layout typically does not separate LF and LOB data from regular data.

Therefore, the tablespace pool layout comes with several advantages:

Optimized backup and restore runtimes:

Database backup (and restore) operations are parallelized down to the tablespace level. This means, if your system has an unbalanced tablespace layout, with a few large and many smaller tablespaces, then parallelizing the backup process will not work in the most optimal way and the largest tablespaces will determine the overall backup runtime. As tablespace pools typically show a uniform distribution of data amongst tablespaces, backup and restore operations can run with an ideal degree of parallelism and runtime is expected to improve significantly.

Better performance optimization:

The separation of regular table data from LF/LOB data allows fine-grained performance optimization. LF/LOB data is not cached in the Db2 buffer pool but is read directly. By storing this type of data into dedicated tablespaces, you can selectively enable file system caching for the respective tablespaces to allow buffering at the file system level. This type of caching is enabled by default for the long tablespaces, when using tablespace pools.

Minimize risk of hitting maximum table objects:

There is a limit on the maximum number of table objects that can be stored in a single DMS tablespace. When using 16k pages, this limit is 53,747. With an unbalanced tablespace layout, there is a significantly higher chance to run into this limit – for example this might happen during an SAP upgrade. Using tablespace pools minimizes this risk. In a nutshell, we recommend using tablespace pools. Building a new target system as part of a system copy process is a perfect opportunity to implement the tablespace pool concept.

Apply Tablespace Pools and take yet another step on your journey from SAP Netweaver to SAP NetZero.