Redo tasks are active components during a restart or recovery. They are server tasks. The redo tasks carry out those transactions that need to be repeated in the case of a restart or recovery. They proceed as follows:
...
1. In the redo list, the redo tasks look for transactions that were completed with a COMMIT, and are therefore ready to be redone. In the redo list, the transactions are sorted by the log sequence numbers of their COMMIT.
2. The redo task starts by processing the transaction with the lowest COMMIT log sequence number. The redo log file that belongs to this transaction is processed in sequence. If a redo log entry for this redo log file has a higher log sequence number than the lowest COMMIT log sequence number, it cannot be processed. In this case, the redo task waits for the COMMIT of the other transaction. Only then can the redo task continue processing the redo log file. This mechanism guarantees the consistency of the data.
3. When a COMMIT transaction has been processed completely, the redo task deletes the redo log file. If it is an OLTP instance, the undo log file for the transaction is also deleted. With liveCache instances, the undo log file is transferred to History Management. The transaction is removed from the redo list.
...
1. In the redo list, the redo tasks look for transactions that were completed with a ROLLBACK.
2. The redo tasks delete the corresponding redo log files. This prevents the transactions being redone unnecessarily.
3. If the ROLLBACK transaction was started before the savepoint, the redo task evaluates the undo log file of the transaction in order to reset the transaction to the status it had before the savepoint. If the ROLLBACK transaction had been processed completely, the redo task deletes the undo log file of the transaction. If the ROLLBACK transaction was started after the savepoint, the redo task does not process the transaction further.
See also: