Analyzing Exchange Server Database Corruption

Microsoft has published an excellent support article, "XADM: Understanding and Analyzing -1018, -1019, and -1022 Exchange Database Errors." Finally, Microsoft admits that Exchange Server database corruption exists! I'm being facetious, but this important topic needs more attention, and this new article is a valuable source of useful information.

The Microsoft article is an excellent effort by Microsoft Product Support Services (PSS) and the Exchange Server development team to educate administrators about the most common errors that occur in an Exchange Server database. The article's fairness and honesty about Exchange Server database errors surprised me. Every database engine technology (e.g., Microsoft SQL Server, Oracle, Lotus Domino) is subject to potential errors, but it's refreshing to see a company help customers understand, diagnose, and possibly prevent them.

If you work with Exchange Server deployments, you've likely encountered database engine errors. I met my first -1018 Exchange Server database error in 1996 while working on an Exchange Server deployment for a customer. When these database errors began to surface, the customer expressed great concern. (Obviously, whenever your Exchange Store experiences one of these errors, you have great cause for concern.) Corruption to Exchange Server's database typically occurs on one of three levels: page-level, Extensible Storage Engine (ESE)/JET-level, and application (Exchange Store)-level. The key to understanding Exchange Server data storage is that each level is merely an abstraction of the previous level, from raw data on disk (page level) to a B-tree database structure (ESE/JET level) to folders, tables, and messages (application level).

When you understand this layered approach, you can more easily understand the relationship of the potential levels of damage to the database--and you can choose the most appropriate repair tools. The utilities that Microsoft provides with Exchange Server detect and repair damage at these three levels. ESEFILE detects problems at the page level. ESEUTIL detects and repairs problems at both the page level and ESE/JET level. ISINTEG detects and repairs problems at the application level.

The article also provides an excellent discussion of how Exchange Server calculates and stores a checksum for each database page to ensure data integrity. When reading a page, the database engine validates the checksum to determine whether the page has become corrupt. You can use the ESEUTIL program (with the /M and /pn switches) to view the checksum for a page. The article concludes with a discussion about how to analyze and recover from -1018, -1019, and -1022 errors.

Exchange Server database corruption might occasionally frustrate you, but with this article, Microsoft is trying to help you understand and correct it. No other messaging system (e.g., Domino, Novell GroupWise) goes to this extent to ensure the integrity of your data. If you want to get your propeller spinning over a detailed explanation of the types, causes, and recovery from database corruption, take some time to read the complete article.

End of Article