Elaborating Error 1018, 1019, 1022 in Details
Overview »
This section aims at providing information about Exchange Server error message -1018, -1019, and -1022. Also, it explains the difference between all these errors and what kind of problem in database results in this kind of these errors.
Detailed Information »
In Microsoft Exchange Server, there is built-in functionality to identify EDB file-level damage to the pages. Amongst the various symptoms that inform about this sort of damage to the DB, three of the very famous errors are:
Nevertheless, damage to database of Exchange Server can take place at different levels. Possibility is the pages in the EDB file are corrupt, or the B-tree structure is dis-ordered, or the index of EDB file is damaged. Depending upon the scenario, DB corruption is classified as:
Using Eseutil.exe /K switch, page-level integrity of database can be checked out and fixed. In order to detect database and application level inconsistency, Isinteg utility is available for help free of cost by Microsoft.
Page level damage that generally occurs due to issues with Operating System, drivers, hardware is categorized as Physical Corruption. On the other hand, Database and Application Level damage caused due to problem in B-tree structure, table or index of EDB file comes under Logical Corruption.
Exchange Server error messages discussed in this article are caused due to page-corruption of EDB file. Amongst all, -1018 is the mostly-encountered error and thus there is more discussion done in this section on its cause and recovering from it. The other two errors: -1019 and -1022 are generally caused because of bug in the application (Exchange Server) but not in every case.
In order to understand reason for errors -1018 and -1019, it is important to understand how pages are organized in Exchange database .edb file.
At a logical level, an EDB file is a set of 4KB (or multiple of 4) pages that are numbered in a consecutive manner. The ESE database is an organized in a B-Tree structure that comprises of pages pointing to next adjacent pages or possibly to the previous pages. Due to faster traversal to the tree, the search operations are reverted with quick results. In single page of the ESE DB, there can exist 200 page points (approximately). This means for an EDB file of around 50GB size, the tree will be only three levels high (Root, Internal, and Leaf). However, tables, indexes, and other structures of EDB file creates separate B-trees that are known as B+ Tree.
Meanwhile, the first two pages in the EDB file are held in reserve for the Database Header. When the DB is in offline mode, Eseutil /MH switch can be used to view the header. Now because data is stored in EDB file after 2 header pages, the third physical page of the database is its first logical page.
Nevertheless, along with page numbers, the checksum value of the page is also important. When ESE database is written to the disk, a mathematical calculation is carried out on page which is known as Checksum. The checksum value thus received is written to the header. Now each time the page is read by ESE at the time of online backup or while some common operations, the checksum value is calculated and matched with the one saved in header. If Checksum mismatch, there is possibility that the page is corrupt.
Pages in EDB file for which no checksum is being computed is tagged as an 'uninitialized' pages. The pages in this category include those which are being created in order to create space for more data. These kind of pages have zero value for checksum and page number.
Once an uninitialized page is utilized, it cannot return back to the same state (i.e. it will now be counted as an initialized page). Even if it is emptied, a flag is set for it as a reminder that the page has checksum and page number and thus can be utilized when required.
An initialized page in EDB file if reported with -1018 error, there could be following reasons responsible for it:
Moreover, Exchange Server itself could be responsible for this error by »
When error -1018 is encountered and hardware test is executed, it might not report any issue. However, for this, faulty firmware or hardware could be responsible if a detailed investigation is done. Ordinary diagnostics are unable to detect the problem because issues with firmware or with any application driver are excluded from such tests.
In addition to this, the algorithms for creating checksum and for writing pages to the EDB file are quite simple. Similarly, the mechanisms for page and checksum check are same till release of Exchange Server. Then, there is possibility is a correct checksum is created for the page but its location on hard disk is not correct. This happens because of Transient Memory Error.
A page failed with error -1018 is completely unreadable and if a page with pointers to other page is corrupt, it might leave entire EDB file inaccessible. However, a corrupt page cannot be repaired but can be removed from database. It is a four step process:
Step 1 ) Restore Database and LOG Files from Online Backup
At the time of backup creation, ESE database recalculates the checksum and thus if error -1018 occurs, the online backup process terminates. This ascertains that the backup do not contain any corrupt page. Using any reliable media (NTBackup or Windows Server Backup), online backup can be restored.
Step 2 ) Repair Database using Eseutil /p Switch
If this method is adopted, damaged page is directly discarded. Now, if a leaf page is corrupt, the data loss will occur as this page consists of data. The internal pages of EDB file contain only the structural information. In case an interior page is lost, a table is reconstructed. Nevertheless, the fact is EDB file has maximum number of leaf pages in it.
So, before starting up repairing the database with Eseutil, make a copy of original DB so that in case any data loss happens, original file is available with data saved in it.
An Important Note: Once the Exchange 2007 error 1018 repair process is complete, check the repair count and if it is zero, then perform offline defragmentation of database using Eseutil /D. After this run Isinteg utility to repair DB at application level. If these tasks are not performed post repair process, problems while mounting DB to Server, opening mails or mailboxes can be encountered.
Syntax to Repair EDB with Eseutil is:
To check the repair count in header after repair, the syntax is:
Before Repair Process »
After Repair Process »
Step 3 ) Offline Defragmentation of DB Using Eseutil /D switch
To remove the white space from database created due to discarded corrupt pages, perform offline defragmentation of the repaired database. The syntax for this is:
After Defragmentation »
Step 4 ) Repair Information Store Using Isinteg
Now, to correct physical and logical numbering of pages in EDB file, Isinteg utility should be run against the defragmented database. The syntax is:
After Application Repair »
When an uninitialized page is expected to be in use, error -1019 can occur. The page in use will have checksum and page number 0x00000000. The process to fix this error is similar to that shared for -1018. However, it has to be noted that it is hard to be detected soon as it cannot be diagnosed by online backup.
The error JET_errPageNotInitialized can be caused by the application itself due to logical links or pointers between the pages are not valid. This warning message is likely to occur if there are issues with NTFS file system.
Exchange database grows continuously and thus it requests for new pages to the Operating System. In case, the request is responded with an error instead of a new page, error -1022 is generated. Basically, the disk I/O problem is restricting the successful access to the page.
Another reasons for this error is severe damage to EDB file. In this case, the number of pages requested is more than the number of pages that already exist in database. This is because of wrong transaction log replay due to deletion of checkpoint file or the log files from which relay has to start.
Diagnosing and fixing -1022 error is difficult from Exchange Server error messages -1018 and -1019. Also, repairing would not work here as it indicates severe damage to the database. To recover data, restore the most recent backup.
Recovery from EDB file affected due to above mentioned errors is possible with Exchange Recovery software. The solution restores offline/corrupt EDB file to PST, MSG, EML, and another Server.
