Now accepting guest editorial from SAP, Oracle, Workday and ServiceNow practitioners.Pitch a guide
The Sign-Off Table

Lesson 3 of 5

Persistence: savepoints and redo logs

10 min

Listen to this lesson

0:00 / 7:00

If SAP HANA keeps its data in memory, what happens when the power goes? The answer is the persistence layer. SAP HANA writes everything it needs to disk so that, after a restart or a crash, the database comes back with every committed transaction. Two mechanisms do the work: savepoints and the redo log.

MemoryWhere queries and changes happen; changed pages are marked dirty
Redo log (log volume)Every committed change, written synchronously at commit before the commit is confirmed
Savepoints (data volume)Periodically, all changed pages are written to the data volume as one consistent image
Backups (outside the system)Copies of data and log so the database can be rebuilt even if the volumes are lost
The persistence layers of SAP HANA, from memory to backup.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-102

Data volumes and savepoints

Each service that persists data, such as the index server of a tenant, has a data volume on disk; SAP training material gives the default location as /usr/sap/<SID>/SYS/global/hdb/data. At regular intervals SAP HANA performs a savepoint: it writes every page changed since the last savepoint to the data volume, producing a consistent on-disk image. By default a savepoint runs every five minutes (parameter savepoint_interval_s in the [persistence] section of global.ini). Savepoints also happen automatically during a data backup, at shutdown and after a restart.

SAP HANA uses shadow paging: changed pages are written to new locations, and the previous savepoint's pages are kept until the new savepoint completes. If the system fails in the middle of a savepoint, the last complete savepoint is still intact.

Log volumes and the redo log

Five minutes is too long to risk losing work, so every change is also written to the redo log in the log volume (default /usr/sap/<SID>/SYS/global/hdb/log). These are write-ahead entries: a transaction's commit is only confirmed after its log entries are on disk. That is why SAP recommends fast storage for log volumes; every commit waits for a log write. The log is organized in segments; when one fills, writing moves to the next, and closed segments are backed up automatically (more on that in the next lesson).

Commit and savepoint are separate paths: a commit waits only for the redo log write, while savepoints write changed pages to the data volume every five minutes by default.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-102
  1. CrashCMQ's SAP HANA host fails at 10:07; memory is lost
  2. RestartSAP HANA starts and loads the last completed savepoint (10:05) from the data volume
  3. ReplayRedo log entries written after 10:05 are replayed from the log volume
  4. Roll back open workTransactions that never committed are rolled back
  5. Open for businessEvery transaction committed before 10:07 is present; nothing committed is lost
Restart after a crash. A recent savepoint keeps the replay short.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-102

Column tables do not all need to be in memory immediately after the restart. SAP HANA loads column-store tables column by column as they are used ("lazy loading"), so the first queries after a restart can be slower than usual. Testers who run performance checks right after a restart of CMQ should know this before they raise a defect.

Log mode: normal or overwrite

The parameter log_mode decides what happens to closed log segments. In normal mode, segments are kept until they have been backed up, which makes point-in-time recovery possible. In overwrite mode, segments are reused after the next savepoint without a backup, so you can only recover to a data backup. Overwrite mode is sometimes used in sandboxes; production, and any system whose data you cannot afford to lose, should run in normal mode with log backups.

What happens to a closed log segment depends on log_mode: in normal mode it waits for its backup, in overwrite mode it is reused after the next savepoint.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-102
SituationWhat survivesWhy
Power loss or crash, volumes intactEvery committed transactionLast savepoint plus redo log replay
Data volume lost, log backups and log volume intactEvery committed transactionRestore data backup, then replay log backups and the log area
Log volume lostChanges up to the last log backupOnly backed-up log segments can be replayed
Overwrite log mode and data volume lostData as of the last data backupNo log backups exist to roll forward
What a platform team can promise after different failures.
The Sign-Off Table · thesignofftable.com/academy/sap-bas-102

What would you do?

Sam sees that CMD, the development system, runs in overwrite log mode. Kenji's team has a week of unreleased development in CMD. What is the risk?

Key points
  • Savepoints write changed pages to the data volume, by default every five minutes.
  • The redo log records every committed change synchronously in the log volume.
  • Restart = last savepoint + replay of later redo log entries; committed work survives a crash.
  • Normal log mode keeps log segments until backed up and enables point-in-time recovery; overwrite mode does not.

Check your understanding · not graded

Lesson check

  1. 1. How often does SAP HANA write a savepoint by default?

  2. 2. When is a transaction's commit confirmed?

  3. 3. What happens at restart after a crash?

  4. 4. Which log mode supports point-in-time recovery?