HANA Memory Management: What the Numbers Actually Mean

HANA's memory model is fundamentally different from the database platforms it replaced. On Oracle or SQL Server, the DBA manages buffer pools and cache hit ratios. On HANA, the entire working dataset is expected to live in memory — the database is designed around the assumption that memory is cheap and fast, and disk is only for persistence. Understanding this model is the prerequisite for diagnosing any HANA performance or capacity problem.

The HANA Memory Architecture

HANA uses a process memory model. The indexserver process (the primary database process) allocates memory directly from the operating system. There is no fixed buffer pool — HANA manages memory internally across its components using an allocator layer that tracks usage by pool and service.

The global allocation limit (GAL) defines the total memory HANA is permitted to use. It is set in the global.ini configuration file under the [memorymanager] section as global_allocation_limit. If HANA reaches the GAL, it will attempt to evict data from memory (unloading column store tables) before failing operations with out-of-memory errors.

On a dedicated HANA appliance, the GAL is typically set to 90-95% of physical RAM, leaving headroom for the OS and other processes. On shared servers, it must be sized to coexist with other workloads.

Column Store and Row Store

HANA stores most tables in the column store. Column store organises data by column rather than by row, which is highly efficient for analytical queries that touch a few columns across many rows but less efficient for OLTP-style operations that read or write entire rows.

The column store has two sub-components for each table: the main store (compressed, read-optimised) and the delta store (uncompressed, write-optimised). New writes go to the delta store. The delta merge process periodically consolidates the delta store into the main store and applies compression. This is why HANA tables show two memory footprints in the monitoring views — main and delta.

The row store handles the ABAP repository, SAP configuration tables, and some system tables. Row store memory is managed differently from column store and generally grows slowly after initial load.

Memory Pools and the Global Allocation Limit

Within the GAL, HANA divides memory into pools. The primary pools to monitor are:

The column store pool holds all column-store table data (main and delta). This is typically the largest consumer and the one that grows with data volume.

The code and stack pool holds executable code and thread stacks. This is relatively stable and not a typical source of unexpected growth.

The heap pools cover various allocators used by SQL processing, plan cache, result sets, and internal operations. Spikes in heap usage during complex queries or large import operations are normal but can indicate query plan problems if they are persistent.

Understanding which pool is consuming memory is the first step in diagnosing unexpected memory growth.

Reading M_MEMORY_OVERVIEW

The system view M_MEMORY_OVERVIEW provides a single-row summary of HANA memory state. Key columns:

PHYSICAL_MEMORY_SIZE — total physical RAM on the server.

RESIDENT_MEMORY_SIZE — total memory currently used by all HANA processes. This is what the OS sees.

ALLOCATION_LIMIT — the configured GAL.

USED_PHYSICAL_MEMORY — memory allocated and currently used.

FREE_PHYSICAL_MEMORY — memory not yet allocated by HANA.

The ratio of USED_PHYSICAL_MEMORY to ALLOCATION_LIMIT is your headline memory utilisation. When this approaches 90%, plan an investigation. When it exceeds 95%, HANA will begin unloading tables from memory, which significantly degrades query performance on the unloaded tables until they are reloaded.

For more granular analysis, query M_HEAP_MEMORY grouped by CATEGORY to see which allocator is using the most memory. Query M_CS_TABLES sorted by MEMORY_SIZE_IN_TOTAL to find the largest column store tables.

Delta Merge

The delta merge is a background process that moves data from the uncompressed delta store into the compressed main store. It runs automatically based on configurable thresholds — primarily when the delta store exceeds a size limit.

A delta merge that is not running (either because it is disabled or because the threshold is never reached) results in the delta store growing without bound, consuming memory inefficiently and degrading query performance on the affected tables.

Monitor M_CS_TABLES for tables with high DELTA_RECORD_COUNT relative to RECORD_COUNT. If the delta:main ratio is consistently above 1:10, the delta merge may not be running effectively for those tables. Check the delta merge log in the HANA Administration Console for errors.

A forced delta merge can be triggered manually via SQL: MERGE DELTA OF schema.tablename. Use this for specific tables, not as a general maintenance action.

Out-of-Memory Situations

An out-of-memory error in HANA means one of two things: either the GAL has been reached and HANA cannot allocate more memory, or a specific allocator has reached its configured limit.

The nameserver trace file and the indexserver trace file will contain OOM entries with the specific allocator and the amount requested at the time of failure. This is more informative than the error message presented to the application.

Immediate responses to an OOM situation: identify the largest column store tables and evaluate which can be unloaded from memory (they will reload on next access — the question is whether that trade-off is acceptable). Identify any runaway queries or large result sets that are consuming heap memory. Consider whether the GAL can be increased by adding RAM or by reducing the footprint of other processes on the server.

Do not simply restart the HANA database to clear an OOM situation — this reloads all previously loaded tables and may trigger another OOM immediately. Diagnose and address the root cause first.

Sizing Rules of Thumb

SAP publishes detailed HANA sizing guides for each application. These should be followed for new implementations. For ongoing capacity management, practical rules to keep in mind:

The column store compresses data at roughly 4:1 to 7:1 ratios compared to uncompressed row-oriented data, depending on data type distribution. Do not use raw table size from SE16 to estimate HANA memory requirements — use the compressed footprint from M_CS_TABLES.

Leave at least 20% of the GAL as headroom under normal operating conditions. HANA needs room to handle query peak loads, delta merge operations, and large exports without hitting the limit.

Memory growth in HANA is driven by data volume growth, not by workload. More users running more queries increases CPU, not persistent memory. If memory is growing faster than your data volume, investigate the heap allocators for a leak or a runaway cache.

> Editorial note: HANA memory management behaviour varies between HANA versions and revisions. System views and configuration parameters referenced here apply broadly to HANA 2.0. Verify parameter names and view columns against your specific HANA revision.