Exchange Server database errors are some of the most troublesome events an Exchange administrator can face. File-level damage to your Exchange database can manifest itself in errors such as the -1018, -1019, and -1022 Joint Engine Technology (JET) database errors.
First (and most common) is the infamous -1018 error. This error most often rears its ugly head during a full backup of Exchange databases. The error's Detail field shows that the -1018 is a Read Verify Error. Simply put, the database engine tried—and failed—to verify information about a particular page in the database. (When the Extensible Storage Engine—ESE—reads a page from the database, it compares the page number and the page checksum—which are located in each page's 40-byte header—and verifies that the page requested was the page returned and that the page's checksum is valid. To calculate the checksum, the ESE uses a seed value, then XORs that value with the data in the page.) The -1018 error can have many causes, which I've discussed in past commentaries. More important than the cause, however, is how you decide to recover from it.
You really have only three options. The first option is to restore the database from backup. This option is the most drastic but might be the only solution if other methods fail. The second option is to use Eseutil (which comes with Exchange 2000 Server and Exchange Server 5.5) to attempt to repair the problem database. Be aware, however, that this method is likely to cause some data loss. (This method essentially eliminates the bad pages in the database; the severity of data loss depends on what information those pages stored.) The third option is data relocation. I prefer this option, which involves relocating mailboxes from the damaged database to a new database on the server or on another server. This option preserves data and doesn’t require a complete recovery operation. To determine which mailbox (if any) the page is part of, see the Microsoft article "XADM: How to Determine Which Mailbox Owns a Particular Page in a Database". You might also find the Esefile utility (which also comes with Exchange) useful. This utility provides a complete offline scan of every page in the database. This scan can detect bad pages as well as other transient problems that a -1018 error might indicate.
The -1019 and -1022 errors are less common than but as severe as the -1018 error. A -1019 error is similar to a -1018 error but indicates that the accessed page has returned an invalid page number (usually all zeros) rather than an invalid checksum. In other words, the ESE expected the page to be in use but found that the page wasn't initialized or was empty. The -1019 error is most often the result of file-system corruption that has caused regions of the disk to be erroneously mapped into the database file.
The -1022 error is the most indicative of major hardware problems, particularly disk subsystem problems. If the database engine requests a page from disk but instead receives an error from the I/O subsystem, a -1022 error results. This error doesn’t necessarily indicate database corruption but does tell you that the ESE couldn't access the Exchange database. To find the source of this error, start by looking in the System event logs and running disk diagnostics. Replace any defective hardware that you find.
The -1018, -1019, and -1022 errors are the most common errors that you'll encounter. As such, you should be familiar with each error and know how to recover Exchange databases effectively when these errors surface. For more information about the errors and how Microsoft recommends you recover from them, see the Microsoft article "XADM: Understanding and Analyzing -1018, -1019, and -1022 Exchange Database Errors".
