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”. The person whose account is missing some money will be quite displeased. How do we ensure that we always write complete data? Part of the solution is to use what is called a “transaction log”.
Note In the world of computers, many different things are called “logs”. For example, the solidDB® writes multiple log files, including a transaction log file and an error message log file. For the moment, we are discussing only the transaction log file.
As we mentioned previously, work is usually done in “transactions”. An entire transaction is either committed or rolled back. No partial transactions are allowed. In the situation described here, where we started to write a person’s new accountbalance to disk but lost power before we could finish, we would like to roll back this transaction. Any transactions that were already completed and were correctly written to disk should be preserved.
To help us track what data has been written successfully and what data has not been written successfully, we actually write data 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 we know that fractional 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, 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.
This is not a complete description of how transaction logging protects against data corruption. We have explained how the server makes sure that it doesn’t lose transactions. But we have not really explained how the server prevents the database file from becoming corrupted if a write failure occurs while the server is in the middle of writing a record to a table in the disk drive. That topic is more advanced and is not discussed here.