One of the major advantages of buying a commercial database server is that most such servers have been designed to protect data if the database server shuts down unexpectedly for any reason, such as a power failure, a hardware failure, or a failure in the database software itself.

Suppose that you are writing data to a disk drive (or other permanent storage medium) and suddenly the power fails. The data that you write might not be written completely. For example, you might try to write the account balance "122.73", but because of the power failure you just write "12". Part of the solution to ensure that complete data is written, is to use a "transaction log".

Work is usually done in "transactions", see Transactions. An entire transaction is either committed or rolled back. No partial transactions are allowed. Any transactions that were already completed and were correctly written to disk should be preserved.

To help track what data has been written successfully and what data has not been written successfully, data is written to a "transaction log" as well as to the database tables. The transaction log is essentially a linear sequence of the operations that have been performed - that is, the transactions that have been committed. There are markers in the file to indicate the end of each transaction. If the last transaction in the file does not have an "end-of-transaction" marker, then you know that transaction was not completed, and it should be rolled back rather than committed.

When the server restarts after a failure, it reads the transaction log and applies the completed transactions one by one. In other words, it updates the tables in the database by using the information in the transaction log file. This is called "recovery". When done properly, recovery can even protect against power failures during the recovery process itself.