This blog is for beginner in HANA savepoint , if you know already how it works feel free to skip this blog and read another blog mentioned as Advanced Hana Savepoint. I have used a reference from Klaus in this blog and you can check his blog in link.
We all know, that the unique selling point of HANA is that it is in-memory database, which means that the data is stored and processed in RAM. First thing that popped in my mind after hearing this was, If it is stored in RAM what happens when you turn off the system. As RAM is volatile in nature, how is persistency maintained ?
So when persistency is concerned , SAVEPOINTS come in action. Savepoints are required to synchronize change in memory with disk level data. Savepoint is a periodic point in time , when all changed data is written in storage in form of pages, all data is flushed from memory to data volumes.
Talking in Layman terms, how the data is saved from RAM to disk, which is a nonvolatile storage . How HANA as a database justifies the C (consistency) of the ACID properties. The answer to all this is savepoint.
All modified pages of row and column store are written to disk during savepoint. Pages can be considered as the block which stores data that will be transferred from memory to disk.
Points to Note in case of HANA Savepoint :-
Each SAP HANA host and service has its own savepoint.
Data that belongs to savepoint represents a consistent state of data in disk
No changes are done to these savepoint until the next savepoint operation has been completed [changes are not done on the previous consistent state until the next savepoint is completed]
When are the savepoints triggered ?
Savepoint interval (automatic) : During normal operations savepoints are automatically triggered after a specific time interval. This time can be controlled by defining the parameter [persistence] -> savepoint_interval_s in global.ini
The default value is 300 seconds, so savepoints are taken at interval of 300 seconds i.e. 5 mins
We can trigger SAVEPOINT manually : ALTER SYSTEM SAVEPOINT
Soft shutdown triggers a savepoint that is why after soft shutdown you have a quick restart (because you have a consistent state and you don't need to process the log segment) but not the same case in Hard Shutdown (logs need not be processed from the beginning, but only from the last savepoint position.)
A global savepoint is performed before a data backup is started , A savepoint is written after the backup of a service is finished
After a consistent database state is reached during startup , a savepoint is performed
Reclaim Data Volume
Auto Merge Function (mergedog)
Savepoint normally overwrites older savepoint, but it is possible to freeze savepoint that is known as snapshot. Snapshots are savepoints that are preserved for longer use and so they are not overwritten by the next savepoint.
HANA Savepoint is split into three individual stages:
Majority of the savepoint is performed online without holding a lock , but the finalization of the savepoint requires a lock ( Allow me to add that if we have savepoint interval less than 5 mins we do not face immediate issue but we can face some issue as we need to hold locks at every savepoint. In real life scenario we have seen some issue with 3 mins). This step is called the blocking phase of the savepoint. It consists of two major phase
Helpful Views when we talk savepoint
Helpful SQL Script when we talk savepoint.
1969700 – SQL statement collection for SAP HANA , these self explanatory scripts SQL: “HANA_IO_Savepoints“ [for savepoints]and SQL: “HANA_IO_Snapshots” [for snapshot]
Known issue in Savepoint
Analyzing the runtime dumps
So all the dumps are created in trace directory quick way to reach that cdtrace and get to the file indexserver_<hostname>.30003.rtedump.<timestamp>.savepoint_blocked.trc
is triggered by the parameter runtimedump_for_blocked_savepoint_timeout.