Transaction logging captures all the 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 IBM® Lotus® 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 x character 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.

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.

Understanding the database instance ID (DBIID)

When you enable transaction logging, Domino assigns a unique database instance ID (DBIID) to each Domino database. When Domino records a transaction in the log, it includes this DBIID. During recovery, Domino uses the DBIID to match transactions to databases.

Some database maintenance activities, such as using the Compact command with options, cause Domino to reconstruct the database in such a way that old transaction log records are no longer valid. When this happens, a new DBIID is assigned to the database. From that point on, all new transactions recorded in the log for that database use the new DBIID. After a database is assigned a new DBIID, take a new full backup of the database. The new full backup captures the database in its current state with the new DBIID. Then, if you have to restore the database, Domino needs only the new transactions that contain the new DBIID.

Domino assigns a new DBIID when:

• You enable transaction logging for the first time.
• You run the Compact task with an option -- for example, the option to reduce file size.
• You run the Fixup task on corrupted databases.
• You move a Domino database to a logged server.

How transaction logging works
Planning for transaction logging
Disabling transaction logging for a specific database
Using transaction logging for recovery
View logging
Transaction logging -- Troubleshooting

Glossary