The database system performs savepoints at regular intervals, whereby all data changes since the last savepoint from the data cache (working memory) are written to the data volumes (data area, permanent memory).
The pages that were saved during the last savepoint, however, are never overwritten by a following savepoint. This means that the database system can use the information from the previous savepoint for a restart if the system breaks down during the new savepoint. Only after the database system has successfully completed the new savepoint does it release the pages of the old savepoint for overwriting.
The database system performs savepoints both in normal ONLINE operation as well as during a restart. This means that a failed restart can be continued from where it terminated.
You cannot request a savepoint explicitly.
Because savepoints can compromise the performance of the system, the database system performs a new savepoint when one of the two following situations occurs:
a. The database system has filled 2/3 of the log area with log entries since the last savepoint.
b. The database system has performed 5000 log I/O operations and since the last savepoint at least the amount of time defined in the support database parameter _RESTART_TIME has elapsed. With this database parameter, you implicitly define how many log entries the database system has to re-import in case of a restart.
Various database activities, such as starting a data backup, implicitly request a savepoint. All savepoints and the actions that were triggered by them are entered by the database system in the knldiag log file.
The savepoint is controlled by the database system using a server task (savepoint coordinator) and proceeds as follows:
...
1.
Only for liveCache
database instances:
The database system stops the garbage collectors so that they cannot change
any more data pages.
2. All pages that were already changed are written to the data volumes. The quantity of those pages that have to be written to the volumes in step 10 is minimized, so that the duration of the stops for all transactions is kept as short as possible.
3. Now you cannot start or end any further transactions.
4.
For liveCache
database instances only:
The history files are stored as data pages in the data cache.
5.
A redo log entry is
written during a savepoint during normal database operation. This indicates
from which point in time the log entries have to be imported, if a later
restart has to be performed using the data from this savepoint.
If a savepoint is executed during the restart, the current position of the log
reader is determined and entered in the restart record.
6. The information about transactions that are not yet complete is stored in data pages so that it is available for repeating (REDO) or rolling back (ROLLBACK) the transactions in the course of a restart.
7. All changed pages in the data cache are flagged so that only these are written during the current savepoint to the data volumes.
8. Transactions may now be started or ended again.
9.
Only for liveCache
database instances:
The garbage collectors are started again.
10. All flagged pages are written from the data cache to the data volumes.
In addition to the changes that were already completed with a COMMIT, this also includes the undo log files of transactions that are not complete, which are required in the case of a restart (see Using Log Entries for a Restart or Restore).
11. All changed converter pages are written to the data area.
12. The restart record is written. It includes, among other things, the savepoint version. This completes the actual savepoint.
13. Now the database system releases for overwriting all the pages in the data area that are no longer needed.
14. All tasks that had requested or waited for a savepoint are now woken up. If the savepoint was requested during the transfer to the OFFLINE operational state, then the database kernel is now stopped.