To avoid possible server hangs or crashes, it is recommended that Fixup be performed outside business hours to avoid impacting users. However, if Fixup must be run during business hours, which is often the case, follow the steps below to minimize the impact:
1. Load the Fixup database.nsf -C -O against the file.
* -C will only verify the integrity of the database and report errors to the log (database is not modified).
* -O runs on an open database otherwise open databases will be skipped.
If you run Fixup on open databases, Fixup takes the databases offline to perform the fixup.
This is the default if you run Fixup and specify a database name. Without this option, when you do not specify database names, Fixup does not run on open databases.
Important: If the report to the log contains a problem that has never been seen before, do NOT attempt to run Fixup during business hours.
2. If you choose to run Fixup during peak hours, consider running Compact -C instead. This copy-style compaction is not able to copy damaged objects and is used to resolve database corruption issues. This results in less recoverable data but reduces exposure to failures related to Fixup.
3. Fixup is designed to recover corrupt data. This utility manages data in an invalid state but occasionally is unable to manage data errors which can result in server hangs or crashes. This is why running Fixup -C is recommended.
4. When running Fixup while in production, it is important to monitor its state. Fixup -L (with the -C -O) will log detailed information to the console on Fixup's progress. If it is not making any progress ("Performing consistency check" is the first message reported), QUIT the Fixup process. Taking this action early may avoid a server hang.
5. Enable Transaction Logging. Transactional Logging provides improved data integrity, which reduces the exposure to corruption and eliminates the need to use Fixup on a regular basis.