Transaction logging

Domino® transaction logging captures changes made to a database and writes them to a transaction log. The logged transactions are then written to disk in a batch, either when resources are available or when scheduled.

A transaction is a related series of changes made to a database on a server. For example, opening a new document, adding text, and saving the document is one transaction. In this case, the transaction consists of three separate implicit API calls: NotesOpen, NoteUpdate, and NoteClose.

A transaction log is a record of changes made to Notes® databases. The transaction log consists of log extents and the log control file (NLOGCTRL.LFH). A log extent is one of the log files into which the transaction logs are written. It has the form Sxxxxxxx.TXN, where the xxxxxxx characters represents a seven-digit number that is unique to that server. Domino® fills each extent sequentially before writing data to a new one. The records are secured using a proprietary byte-stream format. Each server has only one transaction log that captures all the changes to databases that are enabled for transaction logging.

Use transaction logging to:

• Schedule regular backups. Backups based on transaction logs are faster and easier than full database backups that do not use transaction logging.
• Recover from a media failure. If you have a media failure, you can restore the most recent full backup from tape, then use the transaction logs to add the data that was not written to disk.
• Recover from a system crash. When the server restarts, it runs through the end of the transaction logs and recovers any writes that were not made to disk at the time of the crash. Logged databases do not require a consistency check.
• Log the database views. You can avoid most view rebuilds.

To use all the features of transaction logging for backups and backup recovery, you need a third-party backup utility that uses the backup and recovery methods of the Domino® C API Toolkit. For example, in the case of a media recovery, a database backup is taken with the third-party utility, while logging keeps track of updates to the database. When the database is then lost, the backup is brought up to current state by going through the transaction log and applying any updates which have happened to that databases since the database backup was taken.

Note that restart recovery does not require a third-party utility. In this case, logging goes on while updates are happening. When the server crashes then restarts, any updates which would have otherwise been lost are written to the database. This significantly reduces lost data and database corruption because of server crashes, and reduces overall restart time since the consistency check of databases is not required.