IBM Support

Notes/Domino Best Practices: Transaction Logging

Product documentation


Abstract

The following document is a draft checklist for Domino Best Practices – Transaction Logging. The document includes references, links and Best Practice guidelines.

The Transaction Logging process captures database changes and writes them sequentially to the transaction log. This improves performance and ensures data integrity of databases by committing to the transaction log first before writing to the Notes database. If a critical failure occurs and the server is restarted the databases will be automatically recovered without the need for a consistency check or you can use the transaction log and a third-party backup utility to recover your databases when archival logging is used. Its main purpose is three-fold: to improve performance on the Domino server through sequential writes to the transactional logs, better data integrity by avoiding inconsistencies and data corruption, and faster server restart and crash recovery.

Content


This document is one in a series of documents included in the Domino Best Practices Master Checklist (#7008523).

Intended Audience
This checklist is designed for Notes/Domino administrators, Notes/Domino application designers and IT managers with intermediate to advanced Domino experience who wish to better leverage Domino Best Practices within their environment. It is not possible to provide an all encompassing list of best practices that focus on the nuances of every environment. If you wish to pursue a more in-depth and/or tailored discussion regarding your specific environment, please engage ISSL Consulting Services.

This is a living document and will continue to evolve over time.


What is Transaction Logging?
A Transactional Log is simply a binary file where transactions are written. The transactions are saved in log extents that have a .TXN extension. Each log extent is 64 MB and will fill before a new extent is created or a spare one reused. Multiple log extents collectively can grow to a maximum size of 4 GB with circular logging or available disk space for archive logging.

Transaction logging keeps a sequential record of every operation that occurs to data. If a database becomes corrupted, you can "roll back" the database to a point before it was corrupted and replay the changes from the transaction log.

A single transaction is a series of changes made to a database on a server. For example, a transaction might include opening a new document, adding text, and saving the document.





Transaction Logging Checklist - START HERE
(Return to Notes/Domino Best Practices Master Checklist, #7008523)







Benefits
(Return to top of Transaction Logging checklist)

Transaction logging provides three main benefits:

- In most situations, you no longer need to run the Fixup task to recover databases following a system failure. Excluding Fixup results in quicker server restarts, since Fixup must check every document in each database, while transaction log recovery applies or undoes only those transactions not written to disk at the time of the system failure.

- 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.

- Using transaction logging simplifies your daily backup procedure. You can use a third-party backup utility to perform daily incremental backups of the transaction logs, rather than perform full database backups.

Prior to Transaction Logging, all database specific transactions and operations, creating, modifying, or deleting documents, updating views or changing database attributes, required that the operation commit to database before being considered successful. Waiting for commits to complete as opposed to returning from the operation and trusting the operating system would write the data was the only way to ensure that Fixup could recover the database in the event of a system failure.

Lotus Domino is a very disk intensive application with modifications occurring on different parts of a database or across multiple databases. The data must be accessed and modified across the disk subsystem and this can soon become a bottleneck for most systems. Although today’s Server Raid adapters are highly optimised they are not always tuned for a typical Domino workload that consists of random read and write requests with no apparent pattern. Repositioning the heads in this random manner added to the total time required to complete a transaction. Modern Server Raid adapters have substantial memory cache facilities available to speed up disk IO operation but Domino can not operate in a “trusted” mode but must confirm that the commits have completed successfully to ensure data integrity.

Transaction logging allows Domino to write to the disk IO in a sequential highly optimized way that can easily be automatically optimised by most Server Raid adapters. This is why you need a separate disk subsystem to optimise it for Domino workload.

Transaction logging allows Domino to post transactions to a series of log files before allowing updates to a database. Once the data is posted to the log it is considered a commit as the data is now stored in persistent storage. This action allows the domino operation to complete and continue. The transactions and the data are written to the actual database from the logs at some point in the future. In the event of a system failure the transaction log recovery can apply or undo only those transactions not written to disk at the time of the failure.

One of the biggest benefits of writing to the log first and then writing to the database is that all writes to log files are sequential in nature. Therefore, there is less head movement on the data disks, resulting in faster commits to disk.





Viewing Transactional logging statistics
(Return to top of Transaction Logging checklist)

Transactional logging statistics can be viewed by typing the following command at the Domino console:

SHOW STAT DATABASE.RM.*

The following information will be outputted:

____________________________________________________________________
Current State Stats:

Database.RM.Current.K.Restart.Redo.Hold = 54783
(Changes are sitting on log but not in database(s) yet or Transactions recorded in the log but not yet written to the NSF files on disk (in KB). This is the amount of data the server would have to replay after a crash.)

Database.RM.Current.K.UnCommited.Undo.Hold = 0
(Changes held back by long running transaction(s) or Changes held back by long-running transactions. This helps determine long-running transactions. This is roughly how far back in the log Recovery Manager would have to scan through logs to undo transactions (in KB).)

Database.RM.Current.MaxChkptScan.msec = 16
(Internal Domino statistic.)

____________________________________________________________________
Stats from Last Checkpoint Taken:

Database.RM.LastChkpt.Avg.K.Logged.PerTran = 2
(Indicates transaction size (how large transactions are))

Database.RM.LastChkpt.Interval.Sec = 99001
(Time since last checkpoint in seconds (Ex. 27 hours. This is an Idle machine)

Database.RM.LastChkpt.K.Logged = 17067
(Amount of data logged since last checkpoint (in bytes). Value is generally close to value of Database.RM.Sys.M.Chkpt.Interval.)

Database.RM.LastChkpt.Time =
(07/07/1999 09:31:10 PDT Time of checkpoint)

Database.RM.LastChkpt.Total.DBs = 41
(Databases open or in DBCache at time of checkpoint)

Database.RM.LastChkpt.Trans = 7261
(Actual (true) Transactional Logging type transactions (API calls that did DB updates))

____________________________________________________________________
Stats from Peak Checkpoint (Most Transactions/Sec):

Database.RM.Peak.Avg.K.Logged.PerTran = 1
(Indicates transaction size (how large transactions are))

Database.RM.Peak.Interval.Sec = 168
(Time since peak checkpoint (in seconds))

Database.RM.Peak.K.Logged = 17092
(Amount of data logged in checkpoint interval (in bytes). Value is generally close to value of Database.RM.Sys.M.Chkpt.Interval.)

Database.RM.Peak.Time = 06/01/1999 08:14:47 PDT
(Time of checkpoint)

Database.RM.Peak.Total.DBs = 14
(Databases open or in DBCache at time of checkpoint)

Database.RM.Peak.Trans = 10237
(Actual Transactional Logging type transactions (API calls that did database updates))

Database.RM.Peak.Trans.PerMin = 3656
(Transactions per minute during peak checkpoint interval)

____________________________________________________________________
Stats from Server Restart:

Database.RM.Restart.Duration.Sec = 34
(Time to apply the incomplete changes after a crash (in seconds) or time to replay changes from transaction log upon restart (in seconds). Zero if clean startup.)

Database.RM.Restart.K.Applied = 22735
(Amount of incomplete changes detected and applied in KB (Ex. 22MB in 33 sec.) or amount of data replayed during restart (in KB))

Database.RM.Restart.Time = 06/01/1999 08:11:59 PDT
(Time the server was started)

Database.RM.SinceChkpt.K.Logged = 6904
(internal)

Database.RM.SinceChkpt.Trans = 2593
(internal)

____________________________________________________________________
Summary Stats:

Database.RM.SinceStartup.Aborts = 2
(If this number is high, (usually caused by some corrupt database or Notes in DB, check Miscellaneous Events in the log (LOG.NSF))

Database.RM.SinceStartup.Critical.Log.Times = 0
(Shows how many times your system ran critically log full. If non-zero, consider increasing log size or Number of times that Domino filled the allocated log space. If greater than zero, consider increasing log size. Should be zero. If circular and >0, the system has a long-running transaction)


Database.RM.SinceStartup.Log.Recs.Analyzed = 60771
(internal)

Database.RM.SinceStartup.Log.Recs.Applied = 24734
(internal)

Database.RM.SinceStartup.Log.Recs.Read = 93658
(internal)

Database.RM.SinceStartup.Log.Recs.Written = 1105304
(internal)

Database.RM.SinceStartup.M.Logged = 473
(How much log has been written in MB or Amount of log space used (in MB). Highly useful — can be used to determine average log volume per day by dividing by the number of days since startup)

Database.RM.SinceStartup.Trans = 212551
(Actual Transactional Logging type transactions (API calls that did database updates) or number of transactions since server was started.)

____________________________________________________________________
Global Settings:

Database.RM.Sys.Logged = Enabled
([Enabled | Disabled] If Disabled, command does not show Recovery Manager statistics. Recommend leaving Enabled.)

Database.RM.Sys.Log.Type = Circular
([Circular | Archive] Logging style. Defined in Server document, Transactional Logging tab.)

Database.RM.Sys.M.Chkpt.Interval = 16
([5 | 16 | 500] Checkpoint size/interval (in MB). Defined in Server document, Transactional Logging tab, Runtime/ Restart performance)

Database.RM.Sys.M.Log.Size = 1489
(Maximum size of log. Defined in Server document, Transactional Logging tab, Use all available space on log device=No, Maximum log size.)

Database.RM.Sys.M.Redo.Limit = 49
(Recommended maximum Redo. Hold limit before Domino forces write of changes to NSF files on disk. Hold span before aggressive flushing occurs.)

Database.RM.Sys.Phase = Normal
([Normal || Media Recovery] Displays whether media recovery is occurring. Standard value is ‘Normal’. Would show if Media Recover was under way)

____________________________________________________________________
Supporting Information:

The maximum of the first two numbers Restart.Redo.Hold and UnCommited.Undo.Hold will show the amount of "Active" log necessary for undo (i.e. space needed in log for crash recovery). To monitor logging volumes, dump these stats periodically and watch SinceStartup.M.Logged.



(Return to top of Transaction Logging checklist)

Refer to the following document: Frequently asked questions about Transaction Logging (#7003410)





Hardware considerations
(Return to top of Transaction Logging checklist)

Dedicated RAID1 Array

It is absolutely essential to place the transaction log directory on a separate physical device devoted solely to transaction logging. Part of the performance improvement you will gain from transaction logging depends on having a separate disk, which allows fast writes to the transaction log files. Putting the transaction log on the same drive as other files — the operating system, the Domino executables, the Domino data, the OS pagefile, etc. — can result in a significant performance degradation even in comparison with an R4 server, since the server must read from and write to these files as well. This activity causes contention for the disk head — for example, the server might be reading information from a database while the logger tries to write a change to the transaction log. This can limit or remove the performance gains from transaction logging. Even in an environment with a storage area network (SAN), or an environment with a large physical drive logically addressed as multiple drives (for example, AS/400 or S/390 systems), it is still crucial that the logical transaction logging drive maps to a separate, dedicated physical drive. Each Domino server requires its own transaction log drive, including partitioned servers. The rule of thumb is “one log device per data directory, and one data directory per log device.”

Mirroring the log drive is also crucial, as losing a log drive or encountering a hardware failure risks losing log extents that may not have been backed up, and it also panics the server. RAID0 does not have a mirrored disk, making the log drive a single point of failure. RAID5 can offer mirroring, but has performance degradation due to extra write operations compared to a RAID1 log disk. Note that the media strategy for the transaction log disk is independent of the general server and Domino data strategy — a company could use RAID5 for the operating system and Domino data, but use a RAID1 disk array for the transaction log. Note also that in clustered environments, losing the log disk causes clients to fail over to a cluster member.

The disk size will depend on the logging style that you choose. With circular logging, the server uses a maximum of 4 GB of disk space. A typical mail server logs about 1 GB per day. You can determine how much data your organization is logging by using the transaction logging statistics provided by the Recovery Manager task (discussed later). Under circular logging, the recommendation is to use a 4 GB disk. Disk space is inexpensive and having the maximum space ensures that the server does not need to commit changes to disk under suboptimal conditions.

With archive logging, Domino uses all available space on the log disk (even if you set “Use all available space on log device” to No in the Server document). Archive logging depends on having a third-party backup utility to back up log extents and make them available for re-use. Domino re-uses extents when possible; if no re-usable extents are available, Domino creates a new extent. Therefore, disk sizing depends on how often an organization backs up its log extents. Typically, a 9 GB disk array will be more than sufficient to allow administrators to postpone backups until off hours. Backup products can allow you to specify that log extents should be backed up at a certain time (3:00 AM, for instance) unless the log disk is becoming full (for example, more than 70 percent full), in which case the utility should perform an immediate backup.

Dedicated Controller

Dedicating a controller or controller channel for the log disk avoids controller contention. Avoiding contention for the controller helps maximize the performance boost you get from transaction logging. While not mandatory, dedicating a controller or channel is strongly recommended.





System-level benefits of implementing Transaction logging
(Return to top of Transaction Logging checklist)

Transaction logging also has significant system-level benefits. At the operating system level all file and disk operations are carried out by the OS kernel in either "kernel mode" or "privilege mode"

This requires a context switch to the kernel thread to handle the task of moving data to and from disk. The longer the disk operations take, the more time the system spends waiting for I/O to complete and the less time the system spends doing the work of the application in this case, Domino.

Transaction logging improves the overall I/O throughput of Domino as it reduces kernel time and increases user (application) time. The reduction in time spent in kernel mode reduces the overall CPU cycles required to do the same work. Domino can then use those cycles. Transaction logging improves overall Domino server transaction throughput, which potentially allows the same server to support more users.

In short, using transaction logging:

* Streamlines data directory I/O
* Reduces kernel mode time and increases user mode time
* Increases user-perceived server responsiveness
* Increases server transaction throughput

Coupling this with the backup and archiving benefits of transaction logging, transaction logging makes your server run like it never ran before





What is considered a Transaction?
(Return to top of Transaction Logging checklist)

A transaction is a single API call. It includes creating, modifying, reading (unread marks change) or deleting documents. A transaction is considered COMPLETE when the change has been saved to disk by the user. For example, if a user makes a change to the database, and does not save that change before the server crashes, that transaction is not considered COMPLETE. The transaction would have been COMPLETE only if the user had saved the change before the server had crashed. COMPLETE transactions are "commited" to the transactional log.

IMPORTANT: Enabling transaction logging may improve server performance. Transaction logging saves processing time and cycles 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.





Benefits of Transaction Logging
(Return to top of Transaction Logging checklist)

Data integrity
Transaction logging ensures that once a change is accepted for a database, it is preserved and recoverable even if the server crashes. Before Domino allows an update to a database, it waits for the logging subsystem (logger) to write to the transaction log. With a properly functioning, backup product, even a server disk failure does not lose data — administrators can restore a backed-up database and roll changes forward to the present time with backed-up transaction logs. This gives Domino true enterprise-class reliability.


Faster restart and replay of changes
In an unlogged environment, Domino uses Fixup on restart to check for database notes that are in an inconsistent state. Fixup is a time-consuming task that presents a serious risk of data loss; the task deletes inconsistent notes and notes that reference the inconsistent note. On a large server, restarting Domino after a crash could take hours. In a logged environment, running Fixup is unnecessary. Domino uses the log to determine the state of the databases on disk relative to the state of changes captured in the transaction log and replays changes, bringing Notes to a consistent state. If necessary, Domino can undo a transaction to bring a database to a consistent state. For example, if several transactions update a note, but only a subset were captured in the transaction log before the crash, Domino can undo those transactions to return the note to a consistent state. Fixup is no longer necessary. This greatly speeds restart — replaying changes is very fast, typically bringing the server up in 30 seconds to 2 minutes.


Easier backup
In an unlogged environment, backup is complicated and difficult. Most organizations use either file-level copies to tape or to a network device (with the server either shut down or still running) or a replication strategy. Both methods have shortcomings. File-level copies from a running server risk capturing a database in an inconsistent state, ensuring that Fixup runs on the restored database. Copies from a downed server are consistent but require server downtime. In both cases, changes to the database in the backup window (generally 24 hours in an environment with daily backups) are lost in the event of media failure. Replication addresses these issues, but database corruption or the propagation of a database deletion can result in unrecoverable data.

With transaction logging, full database backups can be less frequent and on-line. Administrators can recover a database by using an older NSF backup and the logs. With the third-party backup software used in conjunction with Domino’s transaction logging, the administrator replays changes to roll the backup forward to the present time (or a specified earlier time, which can be useful in the event of database corruption) — either on the same server or on a separate server. The R5 database format (ODS41) allows online operations, and capturing a database backup generates relatively little server overhead.


Data recovery
In addition to point-in-time recovery (described above), organizations with transaction logging and a working backup product can recover data even in the event of a complete server loss. There is no window for data loss since changes are captured in the transaction log before being updated in the database.


Server performance
Using transaction logging should improve server performance.

Transaction logging improves performance by optimizing disk I/O. Domino R4 had “write-through” changes — a change to a database forced the server to attempt to write the change immediately to disk, regardless of how busy the server was at that point. Many operating systems would shield changes in the file cache, preventing the writes from going immediately to disk for performance reasons but introducing a window for data loss in the event of a server crash. In R5, it is no longer necessary to write immediately to disk since changes are in the transaction log. By batching I/O, the server can devote more cycles to applications, instead of being in kernel mode to perform disk I/O.

Logging captures all changes made to a database by a user, server, or application, except for changes to views and full-text indexes. In the event of a crash, the Updall/Update tasks can rebuild views or full-text indexes, so it is not necessary to log changes in order to achieve recoverability.

Transaction log files, called extents, are 64 MB in size and are filled sequentially — Domino fills one extent before writing data to a new one. Logging writes changes in a consecutive stream of records to the transaction log files. Records are in a proprietary byte stream format, preserving security. By writing changes consecutively to a dedicated disk, disk head movement is minimal, improving performance. While writes to the disk are constant, reads are rare, so head search time is minimized.





Database Instance ID (DBIID)
(Return to top of Transaction Logging checklist)

When you enable transaction logging, Domino assigns a Database Instance Identifier (DBIID) to each Domino database. When Domino records a transaction in the log, it includes the DBIID. During recovery, Domino uses the DBIID to match transactions to databases (it identifies which database the changes should be applied to). The DBIID is stored in the file header, along with the database ID and the Replica ID. Note: There is no relation to the Replica ID or the DBID.

Some database maintenance activities, such as compaction with options, cause Domino to assign a new DBIID to a database. From that point forward, all new transactions recorded in the log use the new DBIID; however, any old transactions still have the old DBIID and no longer match the database's new DBIID. As a result, Domino cannot restore these old transactions to the database.

To avoid losing data, you should immediately perform a full database backup whenever a database receives a new DBIID. When you perform this backup, you capture all the database transactions up until that point and ensure that Domino needs only the new transactions (with the new DBIID) to restore the database. If the DBIID changes and a backup is not taken after the fact, the database cannot be successfully restored (backup will have the old DBIID and the transactional log will not "know" the old DBIID.

NOTE: The DBIID has no relation to the REPLICAID or DBID.

Domino assigns a new DBIID to Domino databases when:

You enable transaction logging for the first time.
- System logging is disabled then re-enabled.
- The database is compacted using copy-style compaction.
- The database has had Fixup -J applied to it.




Important Notes
(Return to top of Transaction Logging checklist)
  • If a database is logged, the default for Compact with no switches is -b (lowercase)
  • If a database is un-logged, the default for Compact with no switches is -B (uppercase).
  • Compact with no switches and Compact -b (lowercase b) are the only times Compact does not change the DBIID.
  • The DBIID changes when a database is copy-style compacted because a copy-style essentially creates an entire new NSF with a new structure, which basically does not match the structure in the logs for the "old" NSF anymore. Note: -L, -c, and -i are switches that enable copy style compaction. -B at times uses copy style compaction.
  • Compact -B may change the DBIID. This option uses in-place compaction unless there is a pending structural change in which case copy-style compacting occurs. So when using this option and transaction logging, do full database backups after compacting completes.

Note: For additional information on the compact tasks switches refer to:
Switches for COMPACT Server Task for Domino (#1084388)
  • Fixup is forced on the database (fixup -j)
  • You move a Notes database from one logged server to another logged server or from an unlogged server to a logged server.

NOTE: Changing the log path or maximum log size (after initial set up and use) does not trigger a DBIID change.

With transaction logging, each transaction is transferred to its database not directly, but by posting sufficient information to complete the transaction to a high-speed access sequential log file. The transaction is finally posted to the database at some later time. Data in the log, but not yet posted to the database, can be recovered in the event of a server failure.

Sequential disk access to a dedicated physical disk is noticeably faster than random disk access.

Transaction logging disk optimization: For optimal performance, transaction logs should be placed on a separate physical disk device. If you place the logs on the same device as the databases, you lose the benefit of sequential access, and there is no performance improvement or very little.



Transaction Field options

(Return to top of Transaction Logging checklist)

Field Enter
Transactional Logging Choose Enabled. The default is Disabled.
Log path Path name location of the transaction log.
The default path name is \LOGDIR in the Domino data directory, although it is strongly recommended to store the log on a separate, mirrored device, such as a RAID (Redundant Array of Independent Disks) level 0 or 1 device with a dedicated controller.
The separate device should have at least 1GB of disk space for the transaction log. If you are using the device solely for storing the transaction log, set the "Use all available space on log device" field to Yes.
Maximum log space The maximum size, in MB, for the transaction log. Minimum value, which is also the default, is 192MB for Domino version prior to 8.5. Starting with Domino 8.5, the minimum allowed value is 500MB. Maximum is 4096MB (4GB). Domino formats at least 3 and up to 64 log files, depending on the maximum log space you allocate.
Use all available space on log device Choose one:
    • Yes to use all available space on the device for the transaction log. This is recommended if you use a separate device dedicated to storing the log. If you choose Yes, you don't need to enter a value in the "Maximum log space" field.
    • No to use the default or specified value in the "Maximum log space" field.
Automatic fixup of corrupt databases Choose one:
    • Enabled (default). If a database is corrupt and Domino cannot use the transaction log to recover it, Domino runs the Fixup task, assigns a new DBIID, and notifies the administrator that a new database backup is required.
    • Disabled. Domino does not run the Fixup task automatically and notifies the administrator to run the Fixup task with the -J parameter on corrupt logged databases.
Runtime/Restart performance This field controls how often Domino records a recovery checkpoint in the transaction log, which affects server performance.
To record a recovery checkpoint, Domino evaluates each active logged database to determine how many transactions would be necessary to recover each database after a system failure. When Domino completes this evaluation, it:
    • Creates a recovery checkpoint record in the transaction log, listing each open database and the starting point transaction needed for recovery.
    • Forces database changes to be saved to disk if they have not been saved already.
Choose one:
    • Standard (default and recommended). Checkpoints occur regularly.
    • Favor runtime. Domino records fewer checkpoints, which requires fewer system resources and improves server run time performance.
    • Favor restart recovery time. Domino records more checkpoints, which improves restart recovery time because fewer transactions are required for recovery.
Logging style Choose one:
    • Circular (default) to continuously re-use the log files and overwrite old transactions. You are limited to restoring only the transactions stored in the transaction log.
    • Archive (recommended) to not re-use the log files until they are archived. A log file can be archived when it is inactive, which means that it does not contain any transactions necessary for a restart recovery. Use a third-party backup utility to copy and archive the existing log. When Domino starts using the existing file again, it increments the log file name. If all the log files become inactive and are not archived, Domino creates additional log files.



How to disable Transaction logging for a specific database

(Return to top of Transaction Logging checklist)

See technote, Transaction Logging on Domino Servers (#7003543).





Recommendations for Transaction logs on a SAN
(Return to top of Transaction Logging checklist)

Important recommendations for using SAN or NAS for transaction logging:
  • Use a separate file system, separate pathway, and separate disks for the transaction logs.

  • Use RAID 1/0 (Stripe mirror) or mirrored pair (RAID 1), rather than RAID 5.

  • Use the fastest, most reliable disks available.

  • Configure the device with a Hot Spare available in case a disk physically fails; and

  • Do not share the disk controller (SAN and NAS) with any other users, if possible.

  • If using a SAN/NAS or separate disk system, then consider the following:

  • Use larger disk block size and matching Stripe size (transaction logging writes fixed sequential 4k blocks to 64 MB or greater files).

  • Because the transaction log files are opened in a synchronous mode, OS file system cache is not used. NVRAM cache in the disk subsystem helps.

  • Use 2 GB Fibre Channel rather than 1 GB. Have dedicated channels and avoid using data switches. Make sure you have adequate I/O capacity for transaction logging.

  • Placement and type of the transaction logging

  • If the logs are placed on a SAN, they should be placed on dedicated devices within the SAN. Each DPAR should have its own HBA connection to the SAN. The use of switches should be avoided.

  • The performance of data transfer from the server must be monitored closely to ensure optimal transfer of data into the SAN. The speed of committal of transactions into the logs on SAN will greatly determine the performance of the server as a whole. If you have configured the Domino servers for failover and/or load balancing, we recommend the following configuration:

  • Running circular or looping linear style transaction logging on userfacing servers for optimal performance and faster recovery after an outage.

  • Running archival style transaction logging on the non-user-facing cluster mate to perform back up or restore activities.

  • If possible use a cluster member or a separate offline system for recovery or restore activities






INI file options
(Return to top of Transaction Logging checklist)

RM_NO_LOG_LARGE_OBJECTS=1
No attachments larger than 1 MB are logged into the mail.box database


To disable logging on the schedule databases (busytime.nsf, clubusy.nsf) and the log file:

MailBoxDisableTXNLogging
This disables logging of mail.box.

Schedule_DisableTXNLogging=1
Log_DisableTXNLogging=1 (Available in 7.0.2+)

These parameters do not automatically disable transaction logging of these databases. The parameter means that NEW instances created by the SERVER on server startup will be CREATED without Transaction Logging enabled. It does not disable Transaction Logging if it is already enabled for these databases. It also does not automatically disable Transaction Logging if the databases are created manually. It does not override manually enabling Logging for these databases once they have been created.




(Return to top of Transaction Logging checklist)

What is Transaction Logging?
What is transaction logging? Date published
Transaction Logging on Domino Servers
Domino R5 and higher 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, you can use the transaction log and a ...
06 Aug 2005
Optimizing server performance: Transaction logging
The Performance page lists resources for Lotus Software products.
08 Mar 2005



SAN drives
Storage Area Networks (SAN) Date published
Should Transactional Log Extents (.TXN Files) Be Directed to a Storage Area Network (SAN)?
A customer has transactional logging enabled on their Domino R5 or 6.x server and has the transactional log extents (.TXN files) as configured in the Server document, placed on a Storage Area Network (SAN) . Is it recommended to direct .TXN files to a ...
29 May 2005
Statement of Support for Domino on SAN and NAS equipment
With the rising use of Storage Area Network (SAN) and Network Attached Storage (NAS) equipment in corporate environments, IBM Lotus software would like to provide guidelines for deploying Lotus software products on this equipment in a manner that will be ...
03 Aug 2005


Circular vs Archive Logging
Circular Logging vs. Archive Logging Date published
Circular versus Archive transactional logging
On a Domino server, what is the difference between "Circular Logging" and "Archive Logging" settings of the Transactional Logging?
04 Jan 2006
Checkpoints in circular logging
When is a checkpoint created? When will this checkpoint be released? Is there anyway to force a checkpoint?
01 Apr 2005
What Happens When Changing from Archive to Circular Mode in Transactional Logging?
What happens when the transactional logging mode is changed from Archive to Circular? Are there any adverse affects to the Domino server?
15 Nov 2005
DBIID's Reassigned After Clean Restart with Linear-Style Transaction Logging
When linear-style transaction logging is enabled on a Domino 6.x server, you find that new DBIID's are reassigned to databases upon a clean shutdown of the server. Why does this occur?
27 Apr 2005
Checkpoints in circular logging
When is a checkpoint created? When will this checkpoint be released? Is there anyway to force a checkpoint?
01 Apr 2005


General Resources
General Resources Date published
How Do Transaction Logs Become Corrupt?
You are performing a database restore and applying the transaction logs to the database to roll it forward. The restore fails because of a corrupt transaction log. How did this happen?
11 Feb 2005
How to clean up corrupt Domino server transaction logs after a failure
A Domino administrator would like to clean up transaction log (.txn) files.
22 Jun 2006
Domino 7 Performance Tuning Best Practices to Get the Most Out of Your Domino Infrastructure
Performance tuning, or optimization, is the process of modifying a system's configuration in order to improve its efficiency at meeting specified functional goals. The systems in question can be a single application, one Domino server, a collection of ...
21 Sep 2006
What are the .dad files located in the transaction log directory?
On your Domino server, you have one or more files in the Transaction Log directory that have a .dad file extension. What are these files?
04 Jan 2006
How Does Recreating the Transaction Log Control File (.lfh) Affect Transaction Logging?
A customer recreated the transaction log control file (.lfh) using the NOTES.INI parameter translog_recreate_logctrl. How does this affect transaction logging on the Domino server?
25 Feb 2005
Is it Possible to Enable Transactional Logging for Shared Mail in Domino 6?
Information about shared mail and transaction logging.
14 Sep 2004
Domino Transaction Logging Backups Using the DP for Domino
How does Domino transaction logging backup work with Data Protection for Domino?
28 May 2004
More on Domino 6 transaction logging
This follow-up to the LDD Today article, "Assessing the impacts of new Transaction Logging features," focuses on Domino 6 transaction logging, presenting and explaining results we obtained testing performance on different protocols and platforms.
03 Jan 2003


Known Issues
Domino server exhibits slow performance when routing mail with transaction logging enabled
In rare cases, and when transaction logging is enabled on the Domino server, when a Notes user sends a message with a large attachment to multiple Notes users, performance on the Domino server may slow down.
28 Jun 2006
Archived Transactional Log Grows Beyond the Maximum Log Space Specified in the Server Document
When Transactional Logging is enabled with the Logging Style set to Archived and the Maximum log space set to a specific size (ex. 500 MB), the transactional logs continue to grow beyond the size specified in the Maximum Log Space field of the Server ...
16 Nov 2005
Linear transaction logging cannot create more than 64 GB
You are using linear logging, and find that you cannot use more storage area than 64 GB. You may see the amount allocated to storing the data to be what you have for storage minus 64 GB. For example, if you had 94 GB allocated for storage, your actual ...
30 Oct 2005
Can the Transactional Logging setting on MAILBOX.NTF be disabled?
A customer would like to disable Transactional Logging on MAILBOX.NTF in the Database Properties, Advanced, "Disable Transactional Logging" check box. But when the setting is "disabled" by putting a check in the box and the Database Properties box is ...
14 Sep 2004


Redbooks
Server crashes when setting the maximum log space to be used by Linear transaction logging to 65536 MB
When configuring transaction logging for Linear style with a log space size of 64GB (65536 MB), the server will crash.
12 Oct 2006
Domino server exhibits slow performance when routing mail with transaction logging enabled
In rare cases, and when transaction logging is enabled on the Domino server, when a Notes user sends a message with a large attachment to multiple Notes users, performance on the Domino server may slow down.
28 Jun 2006
Domino for IBM Eserver xSeries and BladeCenter Sizing and Performance Tuning
This Redpaper provides performance tuning techniques and best practices available for Lotus® Domino 6.5 running on IBM Eserver® xSeries® and BladeCenter™ systems. We describe the Domino network design, operating system, and disk I/O subsystem, with hints and tips to help you investigate and solve performance bottlenecks on your server.
01 May 2004




Google chatter, Forums and blog comments

Google chatter, Forums and blog comments
Transaction Logging - Is it Worth It
Answer from Richard Schwartz - The other potential benefit is that transaction logging can allow you to do incremental backups, but only if you invest in backup software that is built to take advantage of it. This can save you considerable time in backups and restores; and it can reduce the cost of your backup media.
22 May 2006
Transaction logging is far from pointless
Comment from Bruce Stapley - I'd characterise a tool like that as being closer to a godsend than pointless, but your opinion may vary.
04 Feb 2006
RE: Advice on RAID config for maximum Domino performance
Answer from Richard Schwartz - If you do want transaction logging, then set up a four drive RAID-5 array for OS, program files, swap, temp and data; and set up a mirrored pair for the logs.
20 Jun 2006

Document information

More support for: IBM Domino
Transactional Logging

Software version: 6.5, 7.0, 8.0, 8.5, 9.0

Operating system(s): AIX, IBM i, Linux, Solaris, Windows, z/OS

Reference #: 7009309

Modified date: 24 July 2015


Translate this page: