External failure: A failure can also result because of an external cause, such as earthquakes, fire, floods, etc. The database must be duly backed up to avoid troubles occurring due to such failures.

In practice software failures are more ordinary than hardware failures.  Fortunately, recovery from software failures is much faster.

The essential unit of recovery is a transaction. But, how are the transactions can handle during recovery? Let some transactions are deadlocked, then at least one of these transactions has to be start again to break the deadlock and therefore the partial updates made by such restarted program in the database require to be undone so that the database did not go to an inconsistent state. So the transaction must roll back which makes sure that the transaction does not bring the database to an inconsistent state. This is one type of recovery. Let us take a case when a transaction has committed but the alteration made by the transaction has not been communicated to permanently store physical database. A software failure now happens and the contents of the RAM / CPU are lost. This remains the database in an inconsistent state. Such failure needs that on restarting the system the database be brought to a consistent state by using redo operation. The redo operation needs the changes made by the transaction again to bring the system to a consistent state. The database system then could be made available to the users. The main point here is that the database updates are performed in the buffer in the memory. Figure shows some cases of redo and undo. You can make more such cases.

                                                    Figure: Database Updates and Recovery