SAP HANA Savepoint Mechanism - Internal stages

[former_member1232]

SAP HANA persists in-memory data by using savepoints. Each SAP HANA service has its own separate savepoints. During a savepoint operation, SAP HANA database flushes all changed data from memory to the data volumes. The data belonging to a savepoint represents a consistent state of the data on disk and remains so until the next savepoint operation has completed. Redo log entries are written to the log volumes for all changes to persistent data. In the event of a database restart (for example, after a crash), the data from the last completed savepoint can be read from the data volumes, and the redo log entries written to the log volumes since the last savepoint can be replayed.

The frequency at which savepoints are defined can be configured in the persistence section of the global.ini file (every 5 minutes by default). Savepoints are also triggered automatically by a number of other operations such as data backup, and database shutdown and restart. You can trigger a savepoint manually by executing the following statement ALTER SYSTEM SAVEPOINT.

You must always ensure that there is enough space on the disk to save data and logs. Otherwise, a disk-full event will occur and the database will stop working.

 

HANA Savepoint is split into three individual stages:

Phase 1 (PAGEFLUSH): All modified pages are determined that are not yet written to disk. The savepoint coordinator triggers writing of all these pages and waits until the I/O operations are complete.

 

Phase 2 (CRITICAL): The is the critical part of a savepoint operation where no concurrent write operations are allowed. This is achieved using the consistent change lock. To minimize the impact on concurrent operations, phase 2 must be kept as short as possible. The savepoint coordinator determines and stores the savepoint log position and the list of open transactions. Also pages that were changed during phase 1 are written to disk asynchronously.

 

Phase 3 (POSTCRITICAL): Changes are allowed in this phase again. The savepoint coordinator waits until all asynchronous I/O operations related to the savepoint are finished and marks the savepoint as completed.

 



 

The availability of a recent savepoint improves the restart time of SAP HANA, because less redo logs need to be applied to make the database consistent. After a consistent database state is reached during startup, a savepoint is performed again.

Termination of rollback(s) open in restart/backup savepoint can delay restart of HANA startup significantly. You can adjust daemon.ini -> [daemon] -> terminationtimeout (in case lower than below versions)

As of SAP HANA 1.00.122.11 and 2.00.020 the performance of rollback is optimized, so an upgrade to these minimum Revision levels may help to speed up rollbacks. See Note 2000000 - FAQ: SAP HANA Performance Optimization.

 

---

 

 

Thank you,

Amit Lal