SAP HANA Fundamentals & In-Memory Computing Paradigm
A foundational architectural guide to SAP HANA in-memory architecture, hybrid column and row store engines, columnar compression, and the transition from disk-bound RDBMS to real-time HTAP computing.
BeginnerFundamentals~14 min studyHANA 1.0 SPS 12 to HANA 2.0 SPS 07+ / HANA Cloud
Core Learning Objectives
- 1.Understand how in-memory computing fundamentally transforms CPU latency and I/O bottlenecks.
- 2.Contrast Column Store and Row Store layouts, compression mechanisms, and memory footprints.
- 3.Compare SAP HANA against traditional RDBMS engines (Oracle, PostgreSQL, SAP ASE).
- 4.Explain the architectural differences between SAP HANA 1.0 and SAP HANA 2.0 (mandatory MDC).
- 5.Differentiate Scale-Up vs. Scale-Out hardware topology guidelines.
Prerequisites:Basic relational database concepts (ACID properties, tables, indexes, transactions)Basic understanding of OS memory hierarchies (CPU cache, RAM, NVMe/SSD, spindle disk)
Definition & Architectural Rationale
Technical Definition:
SAP HANA (High-Performance Analytic Appliance) is an ACID-compliant, in-memory, column-oriented relational database management system designed to process high-volume operational transactions (OLTP) and real-time analytical queries (OLAP) simultaneously on a single data copy (HTAP).
Why this component exists:
Traditional RDBMS architectures (like Oracle 11g or IBM DB2) were architected when RAM was expensive and scarce. They relied on disk persistence with caching buffers (SGA, buffer pools), requiring elaborate materialized aggregations, secondary indexes, and ETL staging to deliver reporting performance. SAP HANA was built from the ground up to keep all hot transactional and analytical data resident in main memory, eliminating mechanical disk latency and duplicate database layers.
Internal Working & Mechanics
In SAP HANA, data is held in main RAM while changes are continuously written to durable log segments on persistent storage to satisfy durability.
1. Memory Hierarchy & CPU Cache Line Alignment:
In traditional disk databases, disk I/O takes ~5-10 milliseconds (spindle) or ~100 microseconds (NVMe). RAM access takes ~60-100 nanoseconds, while L1/L2/L3 CPU caches take 1-15 nanoseconds. HANA arranges column vectors contiguously so that CPU vector registers (SIMD - Single Instruction Multiple Data) can process millions of integer values per clock cycle without cache misses.
2. Column Store vs. Row Store Mechanics:
- Row Store: Entire tuple (ID, Name, Date, Amount) is stored contiguously in memory. Ideal for single-record lookups (SELECT * FROM USR02 WHERE BNAME = 'SAMEER') or write-intensive operational tables with frequent multi-column inserts.
- Column Store: Each column is stored as an independent, contiguous array. Aggregations (e.g., SUM(NETWR) WHERE BUKRS = '1000') only read the relevant column vectors into CPU cache, skipping irrelevant columns entirely.
3. Compression & Dictionary Encoding:
HANA Column Store automatically applies Dictionary Encoding. Distinct column values are sorted and stored once in a dictionary table; the actual data vector holds tiny fixed-bit integer ValueIDs referencing the dictionary. This achieves 3x to 7x data compression, allowing a 5 TB ERP disk footprint to fit into 1 to 1.5 TB of memory.
4. Hybrid Transactional/Analytical Processing (HTAP):
Because column store aggregation on compressed vectors runs in sub-seconds across billions of rows, SAP S/4HANA eliminated historical aggregate and index tables (e.g., BSIS, BSAS, GLT0 replaced by the universal journal ACDOCA). Transactions insert directly into the Main/Delta structure while analytics query the same live tables without ETL delays.
Architecture Flow Diagram
Mermaid DiagramSAP HANA Fundamentals & In-Memory Computing Paradigm
Architectural Flow: The architectural flow demonstrates how transactions land in the write-optimized Delta Store with synchronous Redo Log persistence, while reads scan compressed Main Store vectors. Periodic savepoints flush altered memory pages to /hana/data every 5 minutes.
Production SQL Diagnostics
Inspect Row Store vs Column Store Footprint in MemorySafe (Read-Only)
Provides aggregate memory consumption, record count, and table count divided between Row Store and Column Store.
Tenant
Privileges: MONITORING or CATALOG READ
Target Engine: HANA 2.0 (All SPS Revisions)
SELECT
'Column Store' AS ENGINE_TYPE,
COUNT(*) AS TABLE_COUNT,
SUM(RECORD_COUNT) AS TOTAL_RECORDS,
ROUND(SUM(MEMORY_SIZE_IN_TOTAL) / 1024 / 1024 / 1024, 2) AS ALLOCATED_GB
FROM SYS.M_CS_TABLES
UNION ALL
SELECT
'Row Store' AS ENGINE_TYPE,
COUNT(*) AS TABLE_COUNT,
SUM(RECORD_COUNT) AS TOTAL_RECORDS,
ROUND(SUM(ALLOCATED_FIXED_PART_SIZE + ALLOCATED_VARIABLE_PART_SIZE) / 1024 / 1024 / 1024, 2) AS ALLOCATED_GB
FROM SYS.M_RS_TABLES;
Key Diagnostic Columns
ENGINE_TYPE:Column Store vs Row Store engineTABLE_COUNT:Number of loaded tablesTOTAL_RECORDS:Aggregate number of rowsALLOCATED_GB:RAM consumption in gigabytesExpected Diagnostic Output
ENGINE_TYPE | TABLE_COUNT | TOTAL_RECORDS | ALLOCATED_GB ----------------------------------------------------------- Column Store | 42150 | 1854200900 | 485.60 Row Store | 3120 | 14205000 | 32.10
DBA Interpretation: In standard SAP S/4HANA systems, Column Store should account for 90-95% of total table memory footprint. An unusually large Row Store (>100GB) indicates improper table engine placement or unfragmented row store memory.
Next Diagnostic Action: If Row Store is high, inspect M_RS_TABLES ordered by ALLOCATED_SIZE to identify offending tables.
Linux Terminal Diagnostics & Operations
Check CPU NUMA Node Configuration & Memory Interleaving
user: root
HANA relies heavily on NUMA balance. Unbalanced NUMA nodes cause remote memory access penalties (QPI/UPI interconnect latency).
root@host # numactl --hardware
Terminal Standard Output (stdout):
available: 2 nodes (0-1) node 0 cpus: 0 1 2 3 4 5 6 7 16 17 18 19 20 21 22 23 node 0 size: 131072 MB node 0 free: 42100 MB node 1 cpus: 8 9 10 11 12 13 14 15 24 25 26 27 28 29 30 31 node 1 size: 131072 MB node 1 free: 41980 MB node distances: node 0 1 0: 10 21 1: 21 10
Output Analysis: Both nodes have equal memory (128 GB each) and balanced core distribution. Node distance 10 (local) vs 21 (remote) shows ~2x latency penalty when accessing remote node memory.
Troubleshooting & Root Cause Analysis
Production Best Practices & Operational Risks
Mandatory Best Practices
- Keep Global Allocation Limit (GAL) set to 90% of physical RAM to leave headroom for OS kernel buffers and SAP Host Agent.
- Never run memory-hungry non-SAP background jobs on the dedicated HANA database host.
Risks & Common Gotchas
- HANA does not mean "no disks needed": Persistent storage (/hana/data and /hana/log) is mandatory for ACID recovery upon host reboot.
- Column Store tables must be loaded into RAM to be queried. A cold restart will load tables on demand or asynchronously based on preload flags.