Answers:
It defers or postpones any actual updates to the database until the transaction completes its execution successfully, and reaches its commit point. During transaction execution the updates are recorded only in the log and in each buffer. After the transaction reaches its commit point, the log is force written to the disk, i.e., the updates are recorded in the database. If a transaction fails before it reaches the commit point, there is no need to undo any operations, any how changes are not updated to db, so no undoing is required, and i.e. the information on the log is simply ignored. REDO is needed in case the system fails after a transaction commits, but before all the changes are recorded in the database on disk [after a failure has occurred, the recovery sub system consults the log to determine which transactions need to be redone]. Transaction Ti needs to be redone if and only if the log contains both the record <Ti Start> and the record <Ti commit>. Thus information in the log is used in restoring the system to a previous consistent state.
Hence it is also known as No-undo/redo algorithm.