Back to Blog
HANA

Optimizing SAP HANA Memory Management

5 maggio 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 monitors HANA memory 24/7 and alerts before OOM situations occur.

Start Monitoring