Back to Blog
HANA

Optimizing SAP HANA Memory Management

5 May 2026
8 min read

SAP HANA's in-memory architecture delivers unprecedented performance, but it also introduces unique memory management challenges. Out-of-memory situations can bring your entire S/4HANA landscape to a halt. This guide provides practical strategies to optimize HANA memory usage and prevent OOM crashes.

Understanding HANA Memory Architecture

HANA memory is divided into several key areas, each serving different purposes:

HANA Memory Components:

Code & Stack
~1-2 GB - Fixed size for HANA processes
Row Store
System tables, temp tables, delta storage - Usually 10-20% of total
Column Store
Business data (main) - Largest component, 60-80% of total
Shared Memory
Result cache, OLAP cube cache - 5-10%

Common Causes of Memory Issues

1. Unoptimized SQL Queries

Loading entire large tables into memory without WHERE clauses

Solution: Use HANA SQL Monitor (SQLM) to identify expensive queries. Add filters, optimize joins.

2. Delta Merge Not Running

Delta storage grows unchecked, consuming excessive memory

Solution: Schedule automatic delta merge or run manually during low-load periods.

3. Unnecessary Column Store Tables

Tables that should be row store are in column store

Solution: Review table types. Small, frequently updated tables should be row store.

Monitoring HANA Memory

Key Transactions & Views

-- Essential SQL for Memory Monitoring:
-- Overall Memory Usage
SELECT * FROM M_HOST_RESOURCE_UTILIZATION;
-- Memory by Service
SELECT * FROM M_SERVICE_MEMORY;
-- Largest Tables in Memory
SELECT * FROM M_TABLE_PERSISTENCE_STATISTICS
ORDER BY MEMORY_SIZE_IN_TOTAL DESC;

Optimization Strategies

Quick Wins for Memory Reduction

1. Partitioning Large Tables (20-30% savings)

Partition tables >50M rows by date. HANA loads only needed partitions.

2. Unload Unused Tables (10-15% savings)

Use UNLOAD statement for archive tables accessed rarely.

3. NSE (Native Storage Extension) (30-40% savings)

Move warm data to disk-based NSE. Transparent to applications.

4. Optimize LOB Columns (5-10% savings)

Store BLOBs/CLOBs in separate tables to reduce main memory footprint.

Advanced: Memory-Optimized CDS Views

In S/4HANA, CDS views can inadvertently load large datasets. Best practices:

  • Avoid SELECT * in CDS views - Only expose needed fields
  • Use parameters to enforce filtering (e.g., mandatory date range)
  • Leverage associations instead of joins where possible
  • Monitor CDS consumption with /SDF/CD_CDS transaction

Emergency: Handling Out-of-Memory

If HANA runs out of memory RIGHT NOW:

  1. 1. Kill expensive queries - Use ALTER SYSTEM CANCEL SESSION
  2. 2. Unload large tables - UNLOAD "SCHEMA"."LARGE_TABLE"
  3. 3. Clear result cache - ALTER SYSTEM CLEAR RESULT CACHE
  4. 4. Increase memory (temp) - If virtualized, add RAM immediately
  5. 5. Restart services - Last resort: restart indexserver to clear leaks

Proactive Monitoring Setup

Recommended Alert Thresholds:

Warning Alerts
  • Memory usage >70%
  • Delta merge pending >24 hours
  • Memory growth >5% per day
Critical Alerts
  • Memory usage >85%
  • OOM events in alert logs
  • Single table >30% total memory

Conclusion

HANA memory optimization is an ongoing process, not a one-time task. Regular monitoring, proactive alerts, and periodic reviews of table sizes and query patterns are essential. With proper management, you can maintain optimal performance while avoiding costly out-of-memory incidents.

Optimize Your HANA Memory

SUPtime reads the memory used by each HANA service at every poll, next to backups, disks and slow queries, so you see where it is heading before an out of memory.

Start Monitoring