In this post, we will discuss about Exchange Error 1018 which usually occurs when the database gets corrupted on the page-level. The Exchange Server has a built-in facility which helps in determining and fixing any damages which that take place in the database at file-system level. If the EDB file is corrupt at page level, the exchange database is commonly hit by the 1018 JET_errReadVerifyFailure error (probably during online backup creation).
Depending on what went wrong, the Exchange Server Database may get corrupted at various different levels. For instance, at times the index is dis-ordered or the EDB file is corrupt. Based on the type of failure, DB corruption of Exchange Server can be classified as Logical Corruption and Physical Corruption.
Resolve Exchange 2007 Error 1018 from Physical Corruption
Meanwhile, to verify the file-system damage to database, one can use Eseutil. All you need to do is to apply the/mh switch. It will automatically scan the header of the DB for the point where checksum value stability determines integrity of the database.
How to Verify Exchange Database Page Corruption?
For a layman user, Exchange Database looks like yet another system-file saved with .edb file extension. However, at the logical level, an EDB file consists of 4KB pages (or even multiples 4KB, depending on the OS and the version of Exchange in use). In order to keep the I/O operations minimal, these pages are organized in a B-tree structure. Some of these pages might contain data while others may have pointers which link one page to another. Having such a structure ensures that once a query is raised, traversal is faster and you obtain quick results. Further, indexes and tables manage data using a separate B-tree structure, which is called B+ tree.
The header occupies the first two pages of Exchange database EDB file. This means the first logical page of the database is indeed its third physical page. Mentioned below is the formula which helps you in calculating the Logical Page number of EDB file:
Depending on what went wrong, the Exchange Server Database may get corrupted at various different levels. For instance, at times the index is dis-ordered or the EDB file is corrupt. Based on the type of failure, DB corruption of Exchange Server can be classified as Logical Corruption and Physical Corruption.
Resolve Exchange 2007 Error 1018 from Physical Corruption
Meanwhile, to verify the file-system damage to database, one can use Eseutil. All you need to do is to apply the/mh switch. It will automatically scan the header of the DB for the point where checksum value stability determines integrity of the database.
| Fix Exchange Errors & Restore Mailboxes with Microsoft Exchange Recovery Software |
For a layman user, Exchange Database looks like yet another system-file saved with .edb file extension. However, at the logical level, an EDB file consists of 4KB pages (or even multiples 4KB, depending on the OS and the version of Exchange in use). In order to keep the I/O operations minimal, these pages are organized in a B-tree structure. Some of these pages might contain data while others may have pointers which link one page to another. Having such a structure ensures that once a query is raised, traversal is faster and you obtain quick results. Further, indexes and tables manage data using a separate B-tree structure, which is called B+ tree.
The header occupies the first two pages of Exchange database EDB file. This means the first logical page of the database is indeed its third physical page. Mentioned below is the formula which helps you in calculating the Logical Page number of EDB file:
The checksum value of database is as important as its page numbers. While writing transaction to the disk, a mathematical calculation takes place. This calculation for the page is known as Checksum. The header of EDB file holds this value and when the database is read, either while creating online backup or while performing a general task, this value is calculated all over again. If both the values, the one stored in the header and the re-calculated one, don’t match the page is deemed to be corrupted.
Understanding Exchange Error 1018
The 1018 error usually occurs because of the following reasons:
- The checksum value stored in the header of the database doesn’t tally with the checksum value calculated while writing database to the disk.
- There is either some error with NTFS file system or the data is being written to an incorrect location on the hard disk.
Fixing the Exchange Error 1018
Now that it’s clear how and why the Exchange Error 1018 JET_errReadVerifyFailure is generated, we can try fixing it using the ESEutil tool. This is an open source command-line tool designed by Microsoft to help in the resolution of page-level EDB Corruption. Here is a step-by-step procedure involved in repairing the database.
Note: We are considering the case of physical corruption, and to resolve it we need to take a backup and restore the data. When data is restored from online backup, you can be rest assured that it doesn’t have any corrupt page, because if there’s a damaged page the online backup procedure will be automatically terminated with error 1018.
So, the first step towards fixing the error is to restore data from an online backup.
Using ESEUTIL to Repair Database
Eseutil/p switch is the best way to resolve file-system level damage in the database. If the damage prevails in the leaf page of the EDB file, it will result in data loss. However, if there is a damage in the internal page, the DB loses its structure information, which results in reconstruction of the table.
Syntax used while repairing Exchange EDB file using Eseutil/p switch is:
Once the repair process is initiated, the corrupt files are removed and the good data is left behind. However, mounting this server to database isn’t possible directly until you defragment it and correct the logical numbering of pages
Offline Defragmentation of Database
Once the corrupt pages are eliminated from the DB, some white space will be left behind. This can be removed through offline defragmentation of DB. This syntax for this procedure is mentioned below:
Offline Defragmentation of Database
Once the corrupt pages are eliminated from the DB, some white space will be left behind. This can be removed through offline defragmentation of DB. This syntax for this procedure is mentioned below:
Correct The B–Tree Structure
The index of the database is disordered during the repair and defragmentation process. However, you can easily correct it using Isinteg utility. The utility corrects the logical and physical numbering of the database, in turn making it mountable on the server
Conclusion
The above solution is lengthy, and requires you to be a pro in operating Eseutil. In order to recover EDB file database after ESE database, page or application level corruption, it is best to use the Exchange Recovery software. It is easy to use, offers a simplistic approach towards recovering private and public folder data from offline/corrupt EDB file.
0 comments:
Post a Comment