Lotus Domino 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 third-party backup utility to recover your databases
IMPORTANT: Enabling transaction logging can improve server performance in most cases. 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.
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 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.
IMPORTANT: Transaction logging works with databases in format ODS 41 or higher but not with databases that use formats from earlier releases (ODS 20 will not work). After you enable transaction logging, all databases are automatically logged. To check database formats, use the Files tab in Domino Administrator.
NOTE: To use all of the features of transaction logging and recovery, you need a third-party backup utility that supports Domino transaction logging.
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.
A transactional log is a binary file where transactions are written. The transactional log has a .txn file extension. These .txn files should never be deleted. The maximum size of each log extent (.txn file) is 64 MB. You can have several .txt logs based on the size specified in the Server document. The maximum total of .txn files is 4 GB.
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: - 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.
- 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.
- 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.
- In the "Use Directory on" field, choose the server's Domino Directory.
- Click Server Configuration, and then click Current Server Document.
- Click the Transactional Logging tab.
- Complete these fields, and then save the document.
| 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. Default is 192MB. 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.
|
In most cases, disabling Transaction Logging (on a server or database level) is not recommended because you lose all of the benefits of transaction logging (there are no ill side effects of disabling, you simply lose the benefits). One of the benefits of transaction logging is fast server restart. Disabling transaction logging will cause Fixup to run on the database (or all databases on the server), creating the potential for slow restart.
After you set up transaction logging, all databases that are in Domino Release 5 or higher format are logged. You can disable transaction logging of specific databases.
Attachments are transactionally logged; however, attachments are logged redo only. Therefore, if the database is recovered using media recovery you will get back the last copy of the attachment (once they are done they stay done). If, however, the server crashes with uncommited attachment updates, they will not be undone since an undo record is never created for them .
Views are not logged, so after media recovery, you will need to rebuild views.
First, perform any of the following:
- When creating a new database, choose "Disable transaction logging" on the Advanced Databases Options dialog.
- For an existing database, choose "Disable transaction logging" on the Database Properties box, Beanies tab.
- In Domino Administrator, select a database on the Files tab, choose Tools - Database - Advanced Properties, then choose "Disable transaction logging"
- Use the Compact task with the -t parameter.
Second, ensure that all users have closed the database. Next, use the DBCACHE command with the "flush" parameter to close the database in the database cache. Finally, open the database.
Backups are essential for recovering from a media failure, which is a failure of the server's disk or disks. If you have a third-party backup utility, you should:
- Schedule daily incremental backups of the transaction log. Use the backup utility daily to back up the transaction log.
- Schedule archiving of transaction log files. If you use the archive logging style, use a third-party backup utility to schedule archiving of log files.
- Schedule weekly full database backups. Each week, it is recommended to run the Compact task with the option to reduce file size. Because this compaction style changes each database's DBIID, you should schedule compaction with a full database backup.
Corrupted databases don't occur frequently when you use Release 5 or higher databases and transaction logging. When you use transaction logging to log changes to Release 5 or higher databases, a server automatically uses the transaction log to restore and recover databases after a system failure, for example after server failures or power failures. If a disk failure occurs, you use the transaction log along with a certified backup utility to restore and recover the databases.
Transaction logging is an integral part of recovering from system and media failures. A system failure causes the server to stop and requires you to restart the server. During restart, Domino automatically performs database recovery. The system uses the transaction logs to apply or undo database transactions not flushed to disk for databases that were open during the system failure.
Domino also runs the Fixup task on databases that use formats from earlier releases, databases that are in Release 5 or higher format but have transaction logging disabled, and on corrupt databases if you have the "Auto fixup of corrupt databases" field in the Server document set to Yes.
Causes Fixup to run on databases that are enabled for transaction logging. Fixup -j should only be run if a database is corrupt and you have no backup of the database to roll forward from.
Without this -j option, Fixup generally doesn't run on logged databases. The Fixup task interferes with the way transaction logging keeps track of databases. If you are using a backup utility certified for Domino, it's important that you schedule a full back up of the database as soon after Fixup finishes as possible.
The TRANSLOG_Status NOTES.INI parameter is used to enable transaction logging for all databases on the server. "0" is disabled, "1" is enabled. |
No comments:
Post a Comment