%1 (%2) %3The database page read from the file “%4” at offset %5 for %6 bytes failed verification due to a page checksum mismatch. The expected checksum was %8 and the actual checksum was %9. The read operation will fail with error %7. If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.

Details
Product: Exchange
Event ID: 474
Source: ESE
Version: 6.5.0000.0
Message: %1 (%2) %3The database page read from the file “%4” at offset %5 for %6 bytes failed verification due to a page checksum mismatch. The expected checksum was %8 and the actual checksum was %9. The read operation will fail with error %7. If this condition persists then please restore the database from a previous backup. This problem is likely due to faulty hardware. Please contact your hardware vendor for further assistance diagnosing the problem.
   
Explanation

ESE Event ID 474 indicates that a database page read failed verification due

to a page checksum

mismatch. This essentially means that the particular database page

referenced within the information store file named (such as priv1.edb) is

corrupt.

Here are possible symptoms:

  • Users cannot send or receive e-mail messages.
  • You cannot start Microsoft Outlook on your client computer.
  • Online backups fail to complete with a -1018 checksum error.
  • Online defragmentation reports a -1018 checksum mismatch error.

This error is typically the result of a hardware malfunction. The

associated checksum mismatch -1018 error indicates some type of hardware error

99% of the time.

   
User Action

After a system administrator encounters a -1018 error, if the administrator

runs diagnostic hardware tests against the server and these tests report no

issues, the administrator might conclude that Exchange must be responsible for

the issue because the hardware passed the initial analysis. However, in case

after case, further investigation by Microsoft or hardware vendors uncovered

subtle issues in hardware, firmware, or device drivers that are actually

responsible for damaging the database file.

Ordinary diagnostic tests might not

detect all of the transient faults for several reasons. Issues in firmware or

driver software might fall outside the capabilities of diagnostic programs.

Diagnostic tests might be unable to adequately simulate long run times or

complex loads. Also, the addition of diagnostic monitoring or debug logging

might change the system enough to prevent the issue from appearing again.

The first step is to use one of the three methods below to move the existing

datbases to new hardware:

  • Obtain new hardware and install a second server in the Adminstrative Group

    and use Move Mailbox to move the mailboxes to the new server.

  • ExMerge the mailboxes out to .pst files and then ExMerge in to a new

    machine with the same name.

  • If there is no backup and Move Mailbox is not an option, the last resort

    will be to repair the database using Eseutil /P and Isinteg -fix. You

    will still need to ExMerge out all the data after the repair and ExMerge back

    into new hardware.

The second step is to diagnose and correct the original hardware problem by

checking the System log, and running extensive tests from the hardware

manufacturer on the hardware, firmware, raid controllers, and device drivers.

Then you can use Move Mailbox to move the users back, or restore from online

back to the repaired machine.

Definitely do not simply repair the existing database or restore from online

backup until the hardware errors have been diagnosed and corrected. You

must diagnose and correct the hardware errors before repairing, restoring,

moving your mailboxes back, or ExMerging your data back or the ESE Event ID 474s

and -1018 errors will come back because the root cause has not been fixed.

Related:

Leave a Reply