ESE 474 -1018: Unrecoverable Error Detected in Database

Explanation

An ESE 474 event with a -1018 error can occur because of a defective hard disk subsystem hardware component, or because of outdated or incompatible drivers and or firmware in the hard disk subsystem.

After encountering a -1018 error, diagnostic hardware tests run against the server may report no disk subsystem hardware issues, and the assumption might reasonably be that Exchange Server is responsible for the issue.

Extensive investigation by Microsoft and the hardware vendors has determined that subtle issues with the disk subsystem hardware components, supporting drivers and or firmware, are responsible for most -1018 errors.

Exchange reports a -1018 error when an initialized page in the database file is found with either of the following conditions:

• The checksum that is stored on the page does not match the result of the checksum recalculation that is performed as the page is read.

• The page number that is stored on the page does not match the page number that should be on the page, given the page's physical location in the database file.

Exchange might be responsible for self-generating a -1018 error if one of the following scenarios occurs:

• Exchange builds a page that has the wrong checksum.

• Exchange builds a page correctly, but tells the operating system to write the page to the wrong location.

Exchange generates a checksum for a page that is about to be written to disk after all the data has been written to the page. This includes the page number itself. After Exchange adds the checksum to the page, Exchange instructs the Windows operating system to write the page to disk by using standard, published Windows-based APIs.

Transient memory errors may cause the page to then be written to the wrong location on the hard disk.

Even though the page checksum is correct, Exchange reports a -1018 error because the logical page number does not match the physical page number.

A single -1018 error that is reported in an Exchange database generally does not cause the Exchange database to stop or result in a symptom other than the presence of the -1018 error itself. The affected page might be in a folder that is infrequently accessed, such as the Sent or Deleted Items folders, or in an attachment that is rarely opened, or even empty.

Although a single -1018 error is unlikely to cause extensive data loss, -1018 errors are a problem because they can indicate that the storage system did not reliably store or retrieve data at least once. The -1018 error is an early warning of an issue that will probably become progressively worse. Even if the first -1018 error is reported for an empty page in the database, it is unknown which page might be damaged next. If a critical global table is damaged, the Exchange database may not start, and database repair might be unsuccessful or only partly successful.

After a -1018 error is logged, consider and plan for the possibility of imminent failure or additional random damage to the database until you find the root cause of the error.

User Action

Before you try to correct the ESE 474 -1018 error(s) logged in the Application log, make sure that the disk subsystem of the server is stable.

To troubleshoot the disk subsystem, do the following:

1. Open the Application log, and search for ESE 474 events. In each event, note the full path of the affected database. After you compile a list of affected databases, note the drive letters referenced in the database paths. This information will enable you to target your troubleshooting efforts directly toward these physical disks.

2. Review the System log, and make sure that there are no disk read, write, or time-out errors being logged.

3. Use manufacturer provided disk subsystem diagnostic utilities, and contact the disk subsystem hardware vendor for more help in verifying the integrity of the disk subsystem.

Having corrected any issues with the disk subsystem, or having otherwise verified its stability, use the following methods to recover from the -1018 error. These methods are listed in preferred order or usage:

First Method   Move mailboxes from the database(s) referenced in the ESE 474 event(s) from the Application log. Either move the mailboxes to an existing, known good store(s), or create a new Mailbox Store(s) specifically for this purpose. When all mailboxes have been moved, delete the corrupted Mailbox Store(s).

To move mailboxes (Exchange 2000 Server or Exchange Server 2003)

1. In Active Directory Users and Computers, select the user or users whose mailboxes you want to move.

2. Right-click the user list you selected in the previous step, and then click Exchange Tasks.

3. In the Exchange Task Wizard, on the Available Tasks page, click Move Mailbox, and then click Next.

4. Carefully read and follow the remaining steps in the wizard.

To move mailboxes (Exchange Server 2003 only)

1. In Exchange System Manager, expand Servers, expand the server from which you want to move mailboxes, expand the Storage Group from which you want to move mailboxes, expand the Mailbox Store that contains the mailboxes that you want to move, and then click Mailboxes.

2. In the details pane, right-click the user or users whose mailboxes you want to move, and then click Exchange Tasks.

3. In the Exchange Task Wizard, on the Available Tasks page, click MoveMailbox, and then click Next.

4. Carefully read and follow the remaining steps in the wizard.

To move mailboxes using the Exchange Management Console for Exchange Server 2007 only

1. Start the Exchange Management Console.

2. In the console tree, expand Recipient Configuration, and then click Mailbox.

3. In the result pane, click the mailbox or mailboxes that you want to move.

4. In the action pane, click Move Mailbox.

5. In the Move Mailbox Wizard, on the Introduction page, select the server, storage group, and mailbox database to where you want to move the mailbox, and then click Next.

6. On the Move Options page, select an option for handling corrupted messages in a mailbox, and then click Next.

7. On the Move Schedule page, specify when the move should occur, and then click Next.

8. On the Move Mailbox page, review the summary to confirm the mailbox moves, and then click Move.

9. On the Completion page, click Finish.

For more information about supported scenarios for using the Move Mailbox wizard and the Move-Mailbox cmdlet, see "Moving Mailboxes" (https://go.microsoft.com/fwlink/?LinkId=85754) in the Exchange Server 2007 product documentation.

Second Method   Restore the database(s) from a known good backup. For more information about how to restore Exchange Server databases, see the following articles:

• Exchange Server 2007 "Disaster Recovery" (https://go.microsoft.com/fwlink/?LinkId=85802)

• "Exchange 2003 Disaster Recovery Operations Guide" (https://go.microsoft.com/fwlink/?linkid=30250)

Third Method   Use Eseutil to perform a hard repair of the affected database(s). This method should only be performed if the previous two methods have failed. After you run the hard repair, you must also perform an offline defragmentation of the repaired database, and run the Isinteg tool to repair logical corruption. These steps can be performed by using the Exchange Database Troubleshooter Repair Task. This will automatically run the Eseutil /P, Eseutil /D, and Isinteg regimen for you.

For More Information

For more information about this issue, see the following Microsoft Knowledge Base articles and Exchange Resources:

• 314917, "Understanding and analyzing -1018, -1019, and -1022 Exchange database errors" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=314917)

• 867626, "New error correcting code is included in Exchange Server 2003 SP1" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=867626)

• 259851, "Ramifications of running the eseutil /p or edbutil /d /r command in Exchange" (https://go.microsoft.com/fwlink/?linkid=3052&kbid=259851)

• "Exchange Server Error –1018" (https://go.microsoft.com/fwlink/?LinkId=85807)