SAP HANA Memory Pressure: What to Check Before Increasing Memory

HANA deliberately manages a large memory pool, and host-level operating-system figures can be misleading when interpreted without HANA’s own allocation and usage information. SAP specifically recommends understanding used memory, peak used memory and the configured allocation limits rather than treating resident-memory figures alone as sizing evidence. See SAP's SAP HANA Used Memory guidance.

Before changing memory parameters or increasing infrastructure capacity, collect enough evidence to answer a simpler question:

What is consuming memory, what limit is actually being approached, and what workload caused the pressure?

This guide focuses on SAP HANA 2.0-style environments. Exact views, privileges and available columns vary by release, so verify them against the affected system.

1. Establish whether there is actual memory pressure

Start with the HANA-side memory picture rather than OS memory alone.

Useful evidence includes:

• current HANA used memory
• peak used memory
• allocation limit
• host physical memory
• swap activity where relevant
• whether memory consumption is rising or simply remaining at a normal steady level

M_HOST_RESOURCE_UTILIZATION exposes values including the allocation limit, current HANA memory use, peak memory use and host memory information.

The distinction matters because HANA has its own memory manager and memory pool. A large amount of allocated or resident memory is not automatically evidence of an incident.

Record the timestamp and affected host as well. In multi-host environments, memory pressure may be concentrated on a single host rather than affecting the whole database.

2. Compare used memory with the relevant limits

Do not treat “80% memory used” as a diagnosis by itself.

Determine which limit actually applies.

HANA uses allocation limits to control how much memory the system or individual processes may consume. SAP documents the global allocation limit and process allocation limits as distinct controls in its statement memory limit guidance.

Capture:

• current used memory
• peak used memory
• global allocation limit
• service/process allocation information where applicable
• the time at which pressure was observed

This helps distinguish:

high but expected utilization

from:

a system actually approaching an enforced limit.

3. Check whether an out-of-memory event really occurred

If users report failures or HANA services have experienced memory problems, inspect actual OOM evidence.

M_OUT_OF_MEMORY_EVENTS records recent out-of-memory events and includes information such as:

• event timestamp
• host
• connection
• statement identifier/hash
• failed memory request size
• memory already used
• applicable memory limit
• event reason

SAP documents event reasons including the global allocation limit, process allocation limit and statement memory limit.

That distinction is important.

A statement hitting its configured statement limit is not the same problem as the entire HANA system exhausting its global allocation.

Do not collapse every OOM symptom into:

“The HANA server needs more RAM.”

4. Identify which service or component is consuming memory

If total memory is unusually high, move from system-level numbers into the services and components responsible for the increase.

HANA monitoring exposes service and component-level memory information through views such as:

• M_SERVICE_MEMORY
• M_SERVICE_COMPONENT_MEMORY
• M_HEAP_MEMORY

SAP's Memory Analysis guidance explains that when overall memory usage increases, you can investigate whether it is due to a particular component, allocator or table.

Look for concentration.

For example:

• Is one indexserver substantially larger than others?
• Is a particular allocator growing?
• Is memory concentrated in table storage?
• Is temporary computation responsible for the increase?
• Is one tenant responsible in an MDC environment?

The important evidence is not simply that memory increased.

It is where the increase occurred.

5. Check active and expensive SQL

Some memory incidents are workload-driven.

SQL statements consume memory for execution plans, intermediate calculations and result processing. SAP notes that some queries can place extremely high memory demands on the system.

If the incident window points toward SQL activity, inspect:

• currently active long-running statements
• expensive statements around the incident time
• statement hashes/identifiers
• peak statement memory where tracking is enabled
• application/user context where appropriate

When statement-memory tracking is enabled, M_EXPENSIVE_STATEMENTS can expose statement memory consumption. SAP also supports statement-level memory limits specifically to prevent individual queries from consuming excessive memory. See SAP's Expensive Statements Trace documentation.

Again, the conclusion matters.

A single pathological query is a very different problem from general capacity exhaustion.

6. Look for table and allocator growth

Persistent table memory and temporary execution memory behave differently.

Check whether the increase is driven by:

• large column-store tables
• row-store tables
• heap allocators
• temporary calculations
• caches
• application-specific workload

SAP's HANA Memory Analysis guidance describes separate Column Store and Row Store memory analysis, including top tables by memory consumption. SAP also provides allocator statistics for deeper investigation.

A useful investigation therefore asks:

Did the system grow because the business dataset grew, because a workload temporarily consumed memory, or because a component retained an unusual amount of memory?

Those lead to very different corrective actions.

7. Correlate memory pressure with the rest of the system

Memory should not be investigated in isolation.

During the same time window, check for related evidence such as:

• long-running SQL
• blocked transactions
• connection spikes
• CPU pressure
• service restarts
• HANA alerts
• SAP application response-time degradation
• abnormal job activity

Correlation does not automatically establish causation, but it prevents the investigation from becoming a one-metric diagnosis.

8. Do not immediately increase the allocation limit

Changing memory limits is an administrative decision, not an incident diagnosis.

Increasing the limit without understanding the cause can:

• mask an inefficient workload
• allow an expensive statement to consume even more memory
• push pressure toward the operating system
• delay recurrence rather than resolve it

The opposite is also dangerous. Setting allocation limits too low can make a tenant database inaccessible when it can no longer allocate enough memory, as SAP notes in its tenant resource guidance.

Treat memory configuration changes as the result of analysis.

Not as the first reaction to a red monitoring value.

Evidence-first checklist

Before changing HANA memory configuration, capture:

1. Incident timestamp and affected host/database
2. Current used memory
3. Peak used memory
4. Relevant allocation limits
5. Physical memory and swap context
6. Recent OOM events and their reason
7. Services consuming the most memory
8. Relevant allocators/components
9. Large table-memory contributors where appropriate
10. Active/expensive SQL around the incident
11. Connection and transaction pressure
12. HANA alerts around the same window
13. Related application or workload symptoms
14. Any configuration change proposed
15. How the result will be verified afterward

That turns:

“HANA memory was high.”

into:

“Memory approached this limit on this host, this service and workload accounted for the increase, these OOM/SQL events occurred in the same window, and this is the evidence supporting the next action.”

How this relates to BasisPilot

BasisPilot is being developed around operational signals, incidents, evidence and human-controlled investigation.

The repository already contains baseline HANA monitoring paths covering areas such as memory, services, connections, SQL activity and incident evidence. Broader HANA investigation evidence is still being developed and should not be treated as generally available production functionality.

The public Interactive Demo illustrates BasisPilot’s evidence-first investigation workflow using fictional deterministic data. It does not connect to a live SAP system or an AI service.

Further reading

• SAP: SAP HANA Used Memory
• SAP: M_HOST_RESOURCE_UTILIZATION System View
• SAP: M_OUT_OF_MEMORY_EVENTS System View
• SAP: Setting a Memory Limit for SQL Statements
• SAP: Expensive Statements Trace
• SAP: HANA Memory Analysis
• SAP: Memory Allocator Statistics

Back to resources