In-memory data is hot! Wait, it’s actually warm! – Multi-temperature data for SAP BW on top of SAP HANA

When BW on top of SAP HANA was first introduced on the market, the idea was simple: Your whole database needs to fit in RAM memory; this implied having enough RAM memory and having a HANA license for this size of memory.

But sometimes companies forget the good practices for keeping the BW database lean: archiving and house cleaning tasks.

Not performing these tasks makes difficult to plan the BW HANA sizing, since they don’t know what is the “real” size and the growth rate of the database. These good practices need to be carried out always, even if you are not on SAP HANA, otherwise your main database will grow and grow, meaning more costs: (disks, backup, etc.) and more risks (recovering a huge DB from a backup is more risky).

With the latest release of SAP HANA and SAP BW not all the data needs to fit in the RAM memory, now you have Multi-temperature data:

Hot data has highest performance and a lesser data volume. Hot data is kept in the main memory (RAM), while warm data is kept on the disk of the HANA box, and cold data resides in the NLS.

This concept is called Multi-temperature, you can find more information here: Multi-Temperature Categories and BW Architecture (LSA) – Using the SAP HANA Database – SAP Library

Warm data is enabled via two technologies in SAP BW for SAP HANA:

• Non-active data concept (by default ON) for PSA tables and write optimised DSOs. This works on parts of the table (such as partitions, requests, and so on)
• Warm store can be set for write optimised DSOs and datasources

The data on the warm area is available for all kind of operations (read/write) without any change to the BW processes.

The NLS is a different box where you store or archive data that is read-only and is not going to change anymore (e.g. last year’s invoices). The magic of the NLS is that queries without any modification are able to access both, the main database and the NLS. Performance off course is different when accessing the NLS.

To keep hot and warm data volumes under control, you can periodically archive (move) the data into the NLS.

For the NLS box there are solutions from several vendors like SAP, IBM, and others. The good news here is that some NLS solutions are using columnar storage and compression making the data in the archive faster to access and cheaper to store.

All these concepts help reducing the size of the needed main memory and license costs of your SAP HANA box, making the SAP BW HANA project more cost efficient.

After this oversimplified intro, my idea is to get your feedback about:

-Your NLS solution: Which vendor are you using? How is the performance?

-How is the SAP HANA warm data performance?