8.4 Transaction logging

< Day Day Up >

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 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. Each server has only one transaction log, which captures all the changes to databases that are enabled for transaction logging.

Domino Release 6 supports transaction logging and recovery. With this feature enabled, the system captures database changes and writes them to the transaction log. Then, if a system or media failure occurs, or a user needs to have documents or a whole data base restored, you can use the transaction log and a backup utility to recover your database to either its most current state, or to any point in time.

All changes to a Domino database are made by transactions applied to the database using a defined set of procedure calls. There is no other way of updating the Domino databases. Domino transaction logging logs both the data and the actual transaction commands used to make the change; for example: "NSFNoteOpen, NoteUpdate, NoteClose."

Transaction logging provides these main benefits:

In most situations, you no longer need to run the Fixup task to recover databases following a system failure.
Faster recovery after crash. When a server terminates abnormally, databases can be left in an inconsistent state. When transaction logging is not used, the server will scan all databases it can find at startup time to see if any are in this inconsistent state. Consistency checks, a type of fixup, are performed on these databases to remove the inconsistencies. This operation typically requires a great deal of time for large installations that have many databases.

When transaction logging is employed, only those databases that have had updates in the log since the last transaction log checkpoint was written need to be processed at server startup. Since only the small specific number of updates need to be applied to this set of databases, this greatly reduces the processing time. There is no need to scan all of the documents in the database to see if they are all correct.
Transaction logging saves processing time because it allows Domino to defer database updates to disk during periods of high server activity. Transactions are recorded sequentially in the log files, which is much quicker than database updates to random, nonsequential parts of a disk. Because the transactions are already recorded, Domino can safely defer database updates until a period of low server activity.
More efficient handling of disk I/O. Transaction logging may improve performance and save I/O processing time because it allows Domino to defer database updates to disk during periods of high server activity. Transactions are committed sequentially to the logfiles, typically within about 1/100 of a second of the completion of a transaction, rather than being committed to the database on disk. This is much quicker than database updates to random, nonsequential parts of a disk. Since writes to disk are deferred, they can be consolidated, and thus more work can be done with fewer operations. Because the transactions are already recorded on disk in the transaction log, Domino can safely defer database updates until a period of low server activity.

The backup benefits of transaction logging are discussed in 9.7, "Backup/recovery" on page 245.

8.4.1 Setting up transaction logging

The following procedure shows you how to set up transaction logging:

Ensure that all databases to be logged reside in the Domino data directory, either at the root or in subdirectories.
From the Domino Administrator, click the Configuration tab, expand the Server section, and click All Server Documents.
Select the Server Document for the Domino server you want to edit and then click Edit Server.
Click Server, and then click Current Server Document.
Click the Transactional Logging tab.
Decide which logging style you will use; the choices here are Circular, Linear, or Archival. Circular (the default) is the easiest to begin with and includes a slight performance gain. Whichever method you choose, be sure that you have enough disk space.
Enable "Transactional logging."; refer to Figure 8-20 on page 200.

Figure 8-20: Enabling transaction logging
Complete other fields as appropriate, and then save the document. See Domino 6 Administration Help database for more details.
Stop and restart the Domino server to have the changes take effect.

Note

The initial setup for transaction logging can result in a long period of unavailability while the server assigns DBIIDs to each database; it could take several hours.

8.4.2 View logging

View logging is a feature in Domino 6 that allows transaction logging of view elements. When enabled, view logging logs complex view information to the transaction log. If a crash of a server occurs, the log and the view can be reloaded from the transaction log, eliminating the need for a view rebuild.

There is a slight cost associated with view logging, which causes increased CPU utilization when using this features, so it should only be enabled for complex views. This feature is off by default for most databases. It must be enabled for each database view using the Domino Designer® client.

Enabling view logging

To enable view logging, use Domino Designer. In Designer, open a view or folder, select the Advanced tab, and check: Logging - Include updates in transaction log.; see Figure 8-21 on page 201.

click to expand
Figure 8-21: Enabling view logging

Soft deletes

The process of restoring a database, in this case a mail file, can be time-consuming for the administrators on any platform. This is especially true when the restore is needed to recover a single document that was recently accidently deleted by the user.

The new design of the mail file standard template for Domino 6 includes a Trash view. Soft deletes are enabled by default. When a user deletes a document, it is placed in the Trash view and is recoverable by the user for 48 hours. This default time period can be changed; see Figure 8-22 on page 202.

click to expand
Figure 8-22: Changing retention period of soft deletes

The issue of quotas is addressed by specifying "Check space used in file when adding a note" in the quota enforcement field on the Transaction Logging tab (Figure 8-23 on page 202). When this option is specified and user deletes a document, the space occupied by that message is immediately removed from the calculated size of the mail file. There is no need to run the Compact task to recover space.

Figure 8-23: Quota enforcement field

Users who cannot receive mail because of a quota violation can reduce the current size of the mail file immediately by archiving or deleting messages. Since the calculation of quota does not include the items in the trash (soft deletes), it is not necessary to compact the database until reaching the normal weekly database maintenance window. Users who need to undelete a document can do so without the necessity (and overhead) of having an administrator restore their mail file.

Changing the retention period for soft deletes

The retention period of soft-deleted documents can be set by changing the value in the "Softdelete expire time in hours" value on the database properties tab shown in Figure 8-22 on page 202.

Enabling quota enforcement

From the Domino Administrator, click the Configuration tab, expand the Server section, and click All Server Documents.
Select the Server document to edit, and then click Edit Server.
Click the Transactional Logging tab. In the Quota enforcement field, select one of these methods. Then click Save & Close; see Figure 8-23.

< Day Day Up >