Logging
Transaction Logging & Rollforward
These work together to assure transaction integrity against more serious malfunctions, such as operating system crashes, random power failure (which may happen during commit, not only in the trivial case of switching off during data entry), disk head crashes and other physical damage.
Two-phase commit alone cannot protect against such events, ultimately because disks read and write whole sectors and on power failure may have already partially re-written a contiguous file region which is not involved in the transaction and which therefore cannot be restored by that transaction’s phase one undo.
If a virtual space has been corrupted by a crash during commit, the next attempted commit, even after repeated shutdown and restart attempts, will report this fact and provide online instructions how to rollforward the last backup(s) using the log of transactions committed since then.
Each disjoint family set of related virtual spaces includes one designated to contain the transaction log so that all the others are rolled forward together when required. If the transaction log itself has been corrupted then the rest of the family will be in good order, and all that is required is to backup all of them, the first of which backups will trigger the creation of a new transaction log. Transaction logging increases disk space requirement and commit time, and so may be disabled if not needed; re-enabling transaction logging triggers the required checkpoint backups automatically.
