0 Comments
SAP HANA hangs on in-memory data by making use of savepoints. Each of the SAP HANA services has its own separate savepoints. During the ongoing savepoint operation, SAP HANA carries out database flushes thus changing the required data from the memory to the data volumes. The data does belong to a savepoint and represents a consistent state of the data on the respective disk. It remains so until the next savepoint operation has been completed. Redo log entries are written to the log volumes for all changes to the persistent data. In the case of a database restart (for instance, after a crash), the data from given last completed savepoint can be actually read from the data volumes, and then one has to redo log entries written to the log volumes as the last savepoint can be replayed.
What there is more to know?
The frequencies of these savepoints are much defined and can be configured in the persistence section of the global.ini file (every 5 minutes by default). Savepoints are rather triggered off by a number of other operations such as data backup, and database shutdown and restart. You can thus trigger a savepoint manually by executing the following statement: ALTER SYSTEM SAVEPOINT.
One must always ensure that there is sufficient space on the disk to be able to save the respective data and logs; or else, a disk-full event will thus occur and the database will indeed stop working.
What are the HANA Savepoint three individual stages?
Phase 1 (PAGEFLUSH) : involves all the modified that are determined pages are determined that are not actually yet written to the disk. The savepoint coordinator does trigger off the writing of all these pages and thus waits until the I/O operations are complete.
Phase 2 (CRITICAL): This 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 does store the savepoint log position and the list of open transactions. Also, the pages that were actually changed during phase 1 are written to disk asynchronously.
Phase 3 (POST CRITICAL): Changes are of course allowed in this phase again. The savepoint coordinator does wait until all asynchronous I/O operations get related to the savepoint are thus finished and also mark the savepoint as completed.
What happens if the system crashes?
In order to secure SAP HANA data, a savepoint containing the image of the data in the main memory is regularly written to the storage subsystems. The savepoint is created in parallel to living operations and without impacting them. A transaction log is rather continuously stored on high-performance flash storages. These two mechanisms to ensure data persistence and consistency in the event of a system failure. If the database is restarted, the last of the savepoint will make use of and the transaction log will thus be applied to it. Completed transactions will be then be “redone”, ensuring sure that the database is again consistent. However, both of these mechanisms (savepoint and transaction log) cannot replace a backup.
