SAP HANA Inside – Some Aspects of Memory Consumption

Posted by Ruediger Karl on September 27, 2013

More by this author

Before we start … this whitepaper gives you a pretty good overview about SAP HANA’s memory architecture and how you can explore the used memory. If you want to dig a deeper into it, maybe the SAP note 1698281 is wortwhile to read. Here you find instructions to determine the memory usage on a even more detailed level.
Having that read the next question comes up: How can we optimize the memory consumption in SAP HANA? As all know, the memory is a fundamental system ressource for SAP HANA and limited due to the hardware capabilities when we talk about the physical memory. In this blog I want to give an overview about some ways on how to optimize your memory consumption in SAP HANA.

The principal guideline is: Load only those data into the main memory, which are actually required for processing. That is simple, but esssential. Let’s see what HANA can do:

1. First of all, column tables are loaded into memory column-by-column by the SAP HANA database only upon use. This is sometimes called “lazy loading”. Hence, columns that are never used will not be loaded, which avoids memory waste. Once a column is loaded, it will reside in the memory as long as there is sufficient memory available. Columns will be unloaded by SAP HANA with by using a LRU-Algorithm in case of a low-memory situation. This happens without any user internvention. But, you can optimize the column load by table partitioning. DUe to query prunig, SAP HANA loads then only those partitions which are really required for the actual query processing. Another advantage of table partitioning is that the merge operation (I can tell you more about merge in another blog) is merging only the relevant partitions of a table, which have been changed. By the way, This saves not only memory, but also CPU ressources.

2. SAP HANA offers since SPS06 a new capability to store large binary objects (LOBs), such as images or videos. When you import LOBs into the HANA database you can configure, if they are loaded into memory or remain on disk. That capability is called Hybrid LOBS. A hybrid LOB resides first on disk and is referenced only by an ID in the corresponding table column. Once they are required to be accessed, SAP HANA loads the LOB into the main memory. The LOBs will be preferable unloaded by SAP HANA in a low memory situation afterwards.

3. There are often customer requirements to access data in remote databases wihtout loading them into SAP HANA neccessarily. Because the remote data can be huge and you are only interested in the query result. For that SAP HANA SPS06 offers smart data access, which allows to define so-called virtual tables. Virtual tables are pointing to the remote database and can be handled like other HANA tables. Queries on virtual tables are sent by SAP HANA to the remote database for processing. Obviously, you have a tradeoff between response latency of the (non-in-memory)remote database and main memory savings.

4. Another option is to check the size of the row store in SAP HANA. Since the row store is not compressing data to this large extend than the column store, it makes sense in most cases to create custom-specific tables always in the column store or at least to move them to there. And, table partitioning is only supported in the column store.

5. I don’t want to forget to mention the following advise: If you operate a SAP System on SAP HANA, you should observe the table growth of SAP basis tables. There is a useful SAP note 706478 to prevent tables from increasing considerably. It is not only SAP HANA specific, but has even more importance in the context of main memory consumption.

SAP HANA plans in future further advanced capabilities to unload infrequent used data from memory to disk.

VN:F [1.9.22_1171]
Average User Rating
Rating: 4.6/5 (7 votes cast)
SAP HANA Inside – Some Aspects of Memory Consumption, 4.6 out of 5 based on 7 ratings