Entering content frame

Process documentation Savepoint Locate the document in its SAP Library structure

Purpose

The database system performs savepoints at regular intervals, whereby all data changes since the last savepoint are written from the data cache to the data volumes (hard disks).

The pages that were saved during the last savepoint are never overwritten by the savepoint. This means that the database system can use the information from the previous savepoint for a restart if the system crashes during the new savepoint. The pages of the previous savepoint are released for overwriting only once the new savepoint has been successfully completed.

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. However, you can use the _RESTART_TIME support database parameter to configure the time intervals between two sequential savepoints. With this parameter, you also define indirectly how many log entries have to be imported in the case of a restart.

Note

As savepoints affect system performance, the database system does not perform a new savepoint automatically at the end of this time interval. It waits for 5,000 I/O operations and only then does it check how much time has elapsed since the last savepoint. This means that the system does not write a savepoint unless at least 5,000 I/O operations have taken place since the last savepoint. With a lower number of I/O operations, more time may elapse until the next savepoint.

Different database activities, such as starting a data backup, implicitly request a savepoint. All savepoints and the actions that were triggered by them are entered in the knldiag log file.

Process Flow

The savepoint is controlled by the database system using a server task (savepoint coordinator) and is executed as follows:

...

       1.      Only for liveCache database instances:
The garbage collectors are stopped 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.      No more transactions can be started or completed.

       4.      Only for liveCache database instances:
The history directories stored in main memory are stored in data pages, so that they are automatically written to the data volumes in step 7.

       5.      A redo log entry is written during a savepoint during normal database operation. This indicates from when the log entries have to be imported, if a later restart has to be performed using the data from this savepoint.
With a savepoint during the restart, the current position of the log reader is determined and entered in the restart record.

       6.      The information about the transactions that are not yet complete are stored in data pages so that they are available for a restart for repeating (REDO) or rolling back (ROLLBACK) the transactions.

       7.      All changed pages in the data cache are marked so that only these are written to the data volumes during the current savepoint.

       8.      Transactions may now be started or completed again.

       9.      Only for liveCache database instances:
The garbage collectors are started again.

   10.         All marked pages are written from the data cache to the data volumes.

In addition to the changes that were already made 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 With a Restart or Recovery).

   11.      The version of the converter to be backed up is frozen during the savepoint so that the assignment of logical and physical pages is unique in the saved converter version. The converter version is written to the data area.

   12.      The restart record is written. This completes the actual savepoint.

   13.      All tasks that a savepoint requests, or for which a savepoint waited, are now reactivated. If the savepoint was requested during the transition to the OFFLINE operational state, then the database kernel is now stopped.

Example

Example: Restart

 

Leaving content frame