Savepoint 
Purpose
The database system carries out savepoints automatically in the ONLINE operational state and during restarts. At a savepoint, the database system writes the data changes executed since the last savepoint from the data cache (working memory) to the data area (permanent storage).
The data that is written into the data area by a savepoint always represents a consistent state of the database. You can always start the database instance, for example after a power outage, in a consistent state without importing log backups.
Where Does the Database System Write the Data Changes?
At the savepoint the database system does not overwrite the pages written into the data area at the previous savepoint, but instead it writes the changed data to free positions. This is because the database system requires this 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 in the data area for overwriting.
When Does the Database System Perform Savepoints?
The database system performs savepoints in the following situations:
● The database system has filled 2/3 of the log area with redo log entries since the last savepoint.
● 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.
If you increase the value in _RESTART_TIME, you do reduce the number of savepoints and thus the workload, but this also slows down the restart after a system outage.
● Various database activities, such as starting a data backup, implicitly request a savepoint. All savepoints and the actions that were triggered by them are logged by the database system in the kernel log.
Process Flow
The savepoint is controlled by the database system using a server task (savepoint coordinator). It runs as follows:
...
1. The system writes all modified permanent data pages from the data cache to the data area.
2. The system waits for all operations to end that need to synchronize with the savepoint, for example inserting a data record into a B* tree. The database system does not permit new operations of this type.
3. The system does not permit any transactions to be started or finished.
4. During a savepoint during normal database operation:
The system writes a redo log entry. This indicates from which point in time the system has to import the log entries, if a later restart has to be performed using the data from this savepoint.
During a savepoint during a restart:
The system determines the current position of the log reader and enters this in the restart information.
5. The system stores information about the transactions that are not yet complete in data pages, so that it is available for repeating or rolling back the transactions in the course of a restart.
6. The system imports the history information to the data cache.
7. The system marks all permanent data pages modified since step 1 in the data cache.
8. The system permits all operations listed in steps 2 and 3.
Any changes carried out by the database users from this point in time no longer affect the data marked in step 7. The system can only write these changes to the data area once the current savepoint is completed.
9. The system writes the data pages marked in step 7 to the data area. 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 by the system in the case of a restart.
10. The system writes all modified pages of the internal file directory to the data area.
11. The system writes all modified converter pages to the data area.
12. The system updates the restart information, which contains, among others, the savepoint version (=converter version).
This completes the actual savepoint.
13. Now the system releases for overwriting all the pages in the data area that are no longer needed.
14. The system wakes up those tasks that had requested or waited for a savepoint
If the savepoint was triggered during the transfer to the OFFLINE operational state, the system now stops the database kernel.
See also:
Database Manager CLI, 
db_restartinfo