Fix Error 1018, 1019, 1022 in Exchange Server

Fix File Level Database Error 1018, 1019, 1022 in Exchange Server

The primary cause of Error messages 1018, 1019, and 1022 is corruption in the pages of Exchange Database Files. This article focuses on the detailed information about the Exchange server errors; the problems that result in these errors, the difference between the three and how to these fix file-level database errors.

Exchange server built-in functionality has the capacity to identify built-in Page-level damages, and the symptoms which relate to the database-damage are:

• 1018 JET_errReadVerifyFailure
• 1019 JET_errPageNotInitialized
• 1022 JET_errDiskIO

In fact, damage to MS Exchange database takes place at various levels. However, the most common possibilities of damage are: corruption in pages of EDB file, disordered B-tree structure, and damaged index of EDB file. If the Exchange database is affected by any one of these factors, then the corruption is classified into the following:

• Page Level
• Application Level
• Database level

Determine and fix the Page-Level integrity of the database with Eseutil /K switch. Similarly, Application and Database level damage as caused due to the problem in B-tree structure. Table or Index of EDB file is classified under Logical corruption. Refer the image below:

Figure 1: Illustrates cause and Level of Error 1018, 1019, 1022

While the prime objective is to resolve the error, it is necessary to understand the reasons behind these errors and the organization of pages in the EDB file. Logically speaking, an EDB file consists of sets of 4KB (where a set of 4 KB denotes multiples of 4) and numbered in a consecutive manner. Extensible Storage Engine or ESE stores all information in EDB files which are further organized in B-Tree and B+ Tree structure. The B-Tree structure consists of pages pointing to either the next adjacent pages or previous pages. In fact, due to fast traversal through the tree, the user gets instant search results, despite being a storehouse for a large amount of information. The instant search results are attributed to 3-levels of B-Tree, which are Root, Internal, and Leaf. This means, for a page of data having 50GB file, the attributes can read data in only four or five disks. However, the Tables, Charts, Indexes and other structures of EDB files are also the constituents of B+ Tree, and an Exchange Store (ESE) is a collection of multiple B+ Trees.

Figure 2: Illustrates Levels of B-Tree Infrastructure

As shown in the above picture, in a B+ tree, data is available on the bottom level or leaf nodes, and the upper two level of ESE tree comprises of structural information. If a leaf node is damaged, then the data damage is not immense. On the contrary, if the structural pages in a tree are damaged, then there is a loss of entire Table Data available in that structure. Applying the Eseutil/P or /D options may not repair the data available in the node, but there is a possibility of checking the integrity of the data with ISINTEG utility.

EDB files are also divided on page-basis. The first two pages are part of Database Header, and the third physical page of the database is its logical page. Here the page numbers and the Checksum value of the page are equally important. As and when we write ESE database to the disk, there is a mathematical calculation performed on the page, and this calculation is termed as Checksum. The Checksum value is written to the Header. When the ESE reads the page, as during the time of online backup or when the user conducts standard functions, it calculates the Checksum value and matches with the Header. In case the checksum value does not match, it indicates that there is corruption at the Page-level.

There are pages where no Checksum is computed, and EDB tags them as 'uninitialized pages.' The uninitialized pages are created to expand the space for more data, and because they do not contain any data, then these have zero value for checksum and page number. However, once the uninitialized page fills with data, it is converted to initialized state and cannot revert to uninitialized state even when there is no data. The reason is that the EDB sets a flag as a reminder that the page as checksum and page number.

Now that we have a fair idea of the structure of Exchange database let us examine the errors and their resolution.

Reasons for 1018 JET_errReadVerifyFailure

When a user performs an operation on Exchange database, one of the following reasons causes Exchange Server Error – 1018:

• Checksum value of Header does not match with the re-calculated value
• Data written on Hard disk is corrupt or written at an unassigned location
• Problem with NTFS file system

Sometimes, Exchange Server is also responsible for Exchange Server error -1018:

• Identifying a wrong checksum
• Creating a right Checksum but applying at an inappropriate location

ESE tries to access a page which it believes has data in it. In this case, a previous page of the database links to its next page and indicates the presence of valid data. This error is caused when the database file size increases in size, the new pages are initialized which are filled with zeroes. If the existing page points to these new pages, then the problem is with ESE database engine.

Second most prominent cause for Exchange Server error -1019 is File System Problem. The file system maps data into the database file which do not belong to the database.Since the error is not reported for days, weeks, or months, hence it is difficult to trace and resolve.

This is the most serious error amongst the three errors. As a generic error, it creates a problem with the database. The ESE attempts to read from a page which does not exist in the database yet there is a pointer to the page. The error is caused when:

• Any third-party utility truncates database
• File-based antivirus software removes or blocks portion of the file
• The user has denied the local system account permissions to open the filePoint to note is that the normal online backup halts because Exchange Server error -1022 stops it from proceeding.

Solutions to resolve Exchange Server Errors 1018, 1019, 1022:

1. Restore using Online Backup

When a page fails with Exchange Server Errors 1018, it is rendered unreadable, and if a page having pointers to other page is corrupt, the backup process halts. Since the backup terminates at this point, it is free from any corruption. Then the backup can be restored using a reliable backup media.

In case the backup is not up-to-date (in case the error is detected late), then the Exchange database may end up losing critical data. This is avoidable if the database can be repaired using the Eseutil command.

It is not easy to repair the database after it experiences the Exchange server error – 1022, due to severe corruption in the database. The restore method is also not a feasible option because the database backup may not be current and results in loss of database after backup restore.

2. Repair Database using Eseutil /p Switch

In this case, the error is resolved using the Syntax:

Syntax to check the repair count in the header after repair

In this case, the corrupt pages in the Logical database are removed, but a significant drawback is the Eseutil command creates empty spaces in place of corrupt pages in the database, thus leading to loss of database.

3. Offline Defragmentation of Exchange Database using Eseutil/d switch

Reverse this situation with Offline Defragmentation of the database and with the help of Eseutil/D. Use the following Syntax:

The drawbacks of performing an offline defragmentation of the repaired database are:

1. Eseutil does not fix corruption in EDB file instead it removes only the white spaces from the Exchange database.
2. As Eseutil removes white spaces of the database, the logical and physical number of the pages do not match with each other.

4. Repair Database using Isinteg

The Isinteg helps in correcting and synchronizing the Logical and Physical pages of the database.

The drawback of using the Isinteg syntax is that it may or may not work, and if the discrepancy is high, then the chances of database repair are further reduced.

5. Using Exchange Recovery Software

One of the most performing and reliable software to repair the Exchange Database is Stellar Repair for Exchange software which fixes the Exchange database and ensures that there is no data loss. Just perform the three main steps of Search  Scan  and Save EDB file to get the desired results.

Conclusion

Though the Exchange Administrators are experts in resolving the errors using Eseutil switch and Isinteg, there are errors like Exchange server error -1018, 1019, 1022, which result in Exchange database losses after the repair and defragmentation processes. A better option is to use an Exchange Recovery tool like Stellar Repair for Exchange. The software repairs the EDB files and exports it as PST. Additionally, it also exports the repaired EDB directly to Office 365 or Live Exchange server and facilitate reduction in Exchange downtime.

Was this article helpful?

YES0

NO0

About The Author

Anubhuti Sinha

Anubhuti is a tech enthusiast with deep expertise in Microsoft Exchange Server.