Logging Data Changes 
Use
The database system logs all transactions that change application data or the database catalog in log entries. The database system uses these log entries to roll back or repeat SQL statements, if necessary.
A power outage has occurred. The data changes that the last transactions executed had only been stored by the database system in the data cache and had not yet been written to the data area with a savepoint. These data changes in the data cache (working memory) were lost due to the power outage and must therefore be repeated by the database system.
Types of Log Entries
Name |
Use |
Undo log entries (before images) |
- enable the rollback of transactions that are not yet complete - enable consistent views (only for SAP liveCache Database Instances) |
Redo log entries (after images) |
- enable repetition of completed transactions |
To configure logging, use the log settings and database parameters.
Process Flow
...
1. At the beginning of a transaction that will change data, the database system writes undo log entries (before images) for all database objects that are to be changed by the transaction to an undo log file in the data area.
Each undo log entry in the undo log file receives an undo log sequence number, starting with 0.
2. During the transaction the system continuously writes redo log entries in a log queue in the working memory.
A transaction always writes to the same log queue.
3. When the log queue is full, the log writer writes the redo log entries to the log area.
When writing the redo log entries to the log area, the log writer gives each page a sequence number and a time stamp. Using the sequence numbers, the database system can later determine the definitive sequence of the pages in the log area. The timestamp is required by the database system for it to be able to restore the database instance to its state at a certain point in time.
The time intervals between the individual write operations from the log queue to the log area are much smaller than the intervals between savepoints.
When the log area is full, the database system locks all log queues and holds all transactions. Database users cannot perform any further data changes in the database. You have to back up redo log entries from the log area to data carriers so that the database system can again overwrite old redo log entries in the log area (exceptions: overwrite mode is activated for the log area; automatic log backup is on).
4. At the end of the transaction, the following situations are possible:
○ The transaction is closed with a COMMIT.
The database system writes the rest of the redo log entries (after images) from the log queue to the log area. Log pages in the log queue that were not yet full at the time of the writing remain in the log queue until they are full; they are then written to the log area during the next write process.
If the undo log file contains actions for garbage collectors or if the undo log file is larger than one page, the database system assigns the file to history management. Later, a garbage collector deletes the undo log file from the data area (see History Management). Otherwise, the transaction deletes the undo log file.
○ The transaction is retracted with a ROLLBACK.
The database system uses the undo log files to roll back all data changes.
Redo log entries already written to the log area or the log queue remain there and are ignored by the database system.
Logging the Data Changes of a Transaction Closed with a COMMIT
See also: