Persistence Layer: Data Volumes, Log Volumes, Savepoints & Redo Logs

An architectural deep dive into SAP HANA persistence mechanisms: write-ahead logging (WAL), log buffer flushing to /hana/log, cyclic savepoints flushing dirty memory pages to /hana/data every 5 minutes, and crash recovery mechanics.

Advanced (Senior DBA)Internals~18 min studyHANA 2.0 (All SPS)

Core Learning Objectives

1.Master the distinction between synchronous redo logging and asynchronous savepoints.
2.Understand how write-ahead logging (WAL) guarantees ACID durability in an in-memory database.
3.Trace the savepoint execution cycle and its phases (Prepare, Flush Dirty Pages, Close).
4.Learn how crash recovery reconstructs in-memory state after a sudden power loss or kernel panic.

Prerequisites:hana-architecture-services-overview

Definition & Architectural Rationale

Technical Definition:

The SAP HANA Persistence Layer is the underlying disk subsystem responsible for ensuring transaction durability (ACID) by maintaining persistent data volumes (/hana/data) updated via periodic savepoints and write-ahead log volumes (/hana/log) updated synchronously on every transaction COMMIT.

Why this component exists:

RAM is volatile memory. If power fails or the operating system crashes, the entire contents of physical RAM vanish. The persistence layer guarantees that committed transactions are never lost (RPO = 0) and enables complete crash recovery upon restart.

Internal Working & Mechanics

1. Write-Ahead Logging (WAL) & /hana/log: - When a transaction performs an INSERT/UPDATE, changes are recorded in memory log buffers. - On COMMIT, the log buffer is flushed synchronously to the active log segment in /hana/log. The client application receives a "Commit Succeeded" acknowledgement ONLY after the log buffer has safely reached persistent disk storage! - Log Segments: Pre-allocated files (typically 512 MB to 1 GB each) organized cyclically in /hana/log/mnt00001/hdb00002... 2. Savepoint Mechanism & /hana/data: - A Savepoint is a periodic background synchronization (default: every 300 seconds / 5 minutes) that writes all dirty (modified) in-memory pages from RAM to persistent data volumes in /hana/data. - Savepoints use a Shadow Paging technique: changed pages are written to free blocks on disk rather than overwriting existing blocks in place. Once all dirty pages are safely written, the savepoint anchor block is updated atomically. - Savepoint Phases: 1. Phase 1 (Determine modified pages): Prepares list of dirty pages in RAM. 2. Phase 2 (Flush dirty pages): Heavy asynchronous disk I/O writes data blocks to /hana/data. 3. Phase 3 (Savepoint Critical Phase): A brief blocking phase (typically < 100 milliseconds) that secures transaction manager state and advances the restart log sequence number (LSN). 3. Crash Recovery (Restart Replay): When HANA restarts after a crash: - Step 1: Open /hana/data and locate the last consistent savepoint anchor block. - Step 2: Load the Row Store and catalog metadata from the savepoint snapshot. - Step 3 (Redo Phase): Read all redo logs in /hana/log created SINCE that savepoint and roll forward all committed transactions. - Step 4 (Undo Phase): Roll back all transactions that were active (uncommitted) at the time of the crash.

Architecture Flow Diagram

Mermaid DiagramPersistence Layer: Data Volumes, Log Volumes, Savepoints & Redo Logs

Architectural Flow: Transactions write to RAM and synchronously commit to /hana/log. Savepoints periodically flush dirty RAM pages to /hana/data. On reboot, crash recovery loads the last savepoint and replays redo logs forward.

Production SQL Diagnostics

Monitor Savepoint Execution Frequency and Blocking DurationSafe (Read-Only)

Measures savepoint total time, dirty page write size, and critical blocking phase duration.

Tenant

Privileges: MONITORING

Target Engine: HANA 2.0 (All SPS)

SELECT TOP 20 SAVEPOINT_START_TIME, ROUND(DURATION / 1000, 2) AS TOTAL_DURATION_SEC, ROUND(CRITICAL_PHASE_DURATION / 1000, 2) AS CRITICAL_BLOCKING_MS, ROUND(FLUSHED_PAGES_SIZE / 1024 / 1024, 2) AS FLUSHED_MB, ROUND(FLUSHED_PAGES_SIZE / NULLIF(DURATION / 1000000, 0) / 1024 / 1024, 2) AS WRITE_THROUGHPUT_MB_S, STATE FROM SYS.M_SAVEPOINTS ORDER BY SAVEPOINT_START_TIME DESC;

Key Diagnostic Columns

TOTAL_DURATION_SEC:Time taken to flush all dirty pages to disk

CRITICAL_BLOCKING_MS:Brief phase that blocks transactions (should be < 500 ms)

WRITE_THROUGHPUT_MB_S:Disk write bandwidth achieved on /hana/data

Expected Diagnostic Output

SAVEPOINT_START_TIME | TOTAL_DURATION_SEC | CRITICAL_BLOCKING_MS | FLUSHED_MB | WRITE_THROUGHPUT_MB_S | STATE
---------------------------------------------------------------------------------------------------------
2026-10-23 08:00:00  | 4.20               | 45.10                | 1240.50    | 295.35                | Done
2026-10-23 07:55:00  | 3.85               | 38.20                | 980.20     | 254.60                | Done

DBA Interpretation: Savepoints are triggering every 5 minutes, flushing ~1 GB of dirty pages in ~4 seconds with only ~40ms critical blocking time. Excellent storage health.

Troubleshooting & Root Cause Analysis

Production Best Practices & Operational Risks

Mandatory Best Practices

Keep /hana/log on ultra-fast storage (NVMe / Enterprise SSD) with sub-millisecond commit latency.
Never locate /hana/data and /hana/log on the same physical disks or LUNs; write-ahead logging and savepoint flushes will contend for I/O queues.

Senior DBA Interview Mastery

3–5 Year Experience Target

Official Documentation & SAP Notes

SAP HANA Persistence - SAP Help Portal

SAP Note 1999998 - FAQ: SAP HANA I/O Analysis

SAP Note: 1999998