|
This Warning event indicates that the database engine is unable to read the log file header specified in the event description. This may be because of a mismatching log signature, a corrupted log file, or a corrupted log header.
The cause depends on the ESE error code in the Description section of the event. The most common causes are in the following list.
-
Error 530 = Jet_errBadLogSignature = Bad signature for a log file. A signature for log files is used only to make sure that we are replaying the “right” set of log files. For example, if Log 45 from another storage group ended up in the set of log files of another storage group, then ESE will detect a signature mismatch and not replay this log file. A part of each database header includes the signature of the current log file generation; if they do not match, then we error out indicating a mismatch.
-
Error 501 = Jet_errLog fileCorrupt = Log file corrupt. Error 1022 is returned from corrupting the header of a log file. Corrupting other areas of the log file returns 501 Jet_errLog fileCorrupt errors.
-
Error 1022 = Jet_errDiskIO = disk I/O error. The 1022 error is a generic error that appears whenever a disk I/O problem prevents Exchange from gaining access to a requested page in the database or to a transaction log. The most common reason for a 1022 error is a database file that was severely damaged or truncated. If this issue occurs, Exchange requests a page number that is larger than the number of pages in the database file, and a 1022 error results. This issue can occur because of issues in the file system or because of incorrect transaction log replay. In a log file, error 1022 is returned from corrupting the header of a log file.
|
|
To resolve the warning, use one of the following procedures:
-
Restore data from online backup.
-
If there is no valid backup, repair the database by running the Eseutil /p command, and then run the isinteg -fix command on the affected store repeatedly until you receive 0 fixes or the same result for fixes two times. After you repair the database by using the Eseutil /p command and isinteg -fix, the database may not be stable and reliable. Because the repair process deletes database pages, data loss is likely. If you have to run a hard repair on your production database, we recommend that you move the data out of the repaired database to a new database or rebuild the database using the Move Mailbox command.
For information about ESE error codes other than the ones explained in this topic, see the following Microsoft Knowledge Base articles:
For more information about ESE error 1022, see 314917, Understanding and Analyzing -1018, -1019, and -1022 Exchange database errors.
If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.
|