Summary The information provided herein can help understand and analyze -1018, -1019, and -1022 Exchange database errors. This article describes the differences between these three errors and the problem of reporting these three errors.
MORE INFORMATION EXCHANGE includes the function of detecting file-level pages in the database. The most common three incorrects related to the file-level corruption related to the Exchange database are:
-1018 jet_errreadverifyfailure -1019 jet_errpagenotinitialized -1022 jet_errdiskio may occur in the Exchange database:
Page (File System) Level Database (Jet Database Engine) Level Application ESEFILE.EXE Utility You can detect errors in the database in the database. The Eseutil.exe utility can detect and fix the page level and database level problem. Isinteg.exe utility can detect and fix the application level problem.
Lower level damage (page level) can almost always lead to higher levels of problems (database or application level). Therefore, after using the Eseutil to repair the database, it is only used to use ISINTEG almost every time.
Data library-level and application-level corruption are related to the issue of Exchange code or third-party programs integrated with Exchange. Page-level damage is generally caused by drivers, firmware, or hardware, but the issues in Exchange may also cause page grading.
You will always find the root cause of the -1018 error is the underlying system of Exchange dependent, not the Exchange code itself. This rule has few exceptions. So far, the exception is only in the Exchange Report-1018 state, not because Exchange itself causes the -1018 error. For additional information, click the article number below to see the article in the Microsoft Knowledge Base:
237953 xadm: erroneous -1018 Error Returned During Online BACKUP
230215 XADM: Backup Checksuming Not Performed On Single Processor Compute Although -1019 and -1022 errors are mainly caused by defects in the underlying system, do not immediately eliminate errors in the Exchange code, resulting in a possible possible -1019 and -1022 errors. Sex.
Error-1018 is a most common error that indicates that the Exchange database is destroyed at the file system level. Therefore, this article will focus on the error-1018.
There are three basic situations that cause data damage on the disk:
The error data is written to the storage medium. The data is written to the error location in the storage medium. The data is damaged or changed after storage. Although it is difficult to prevent or correct all damage, it is still very easy to detect problems that have occurred. Exchange can detect data of incorrect and wrong position in its database file and report -1018 errors or -1019 errors. If the file is seriously damaged or some of the files are completely lost, or if the Exchange is trying to read the file, the -1022 error will be reported.
Exchange is how to calculate the verification and give the database page number To understand the working principle of the trigger -1018 and -1019 error, you must understand how the Exchange database stores the data page.
At the lowest logic level, you can view the Exchange database file as a set of 4 KB pages, which numbers in sequence. When reading and writing data from the Exchange database, it is performed on page sheet.
Each page containing the data stores its own page number, and has a checksum that is drawn by all data on the page. The checksum value itself is the only part of the page not included in this calculation. The checksum algorithms, including the checksum algorithms used by Exchange, are well understood and quite simple. They are specially designed to make two different pages into the same verification, even if there is only one difference between the two pages.
Although the checksum test is sufficient to determine whether the page is changed after writing, the checksum test is not enough to ensure that the page is in the correct position. Therefore, in addition to the checksum, Exchange also adds its own page numbers for each page.
The pages of the top two 4-KB in the database are reserved as the "title" as the database. When you stop in the database, you can use the eseutil utility
/ MH switch see this title. The title contains information for identifying the entire database.
After these two headings, all other pages in the database are data. The data pages share a common structure. Each page has its own page title, which contains identification information about this specific page, which is then the actual data.
Because the first data page in the Exchange database is after the first two headings page, the 3rd physical page in the database is the first logic page. The fourth physical page is the second logic page, and so on.
The logical page number in the database is mapped directly to the physical page number through the following formula:
Logical Page Number = Physical Page Number - 2 Due to the logical and physical page structure of the database files, Exchange can easily determine if the logical page in the file is in the correct physical location.
The page that does not calculate the checksum in the database is only "not initialized page". They are extended in the extended database size to accommodate more data to create spaces. The checksum and page numbers of uninited pages are zero. Under normal circumstances, each byte of the uninitialization page is filled with "0x00" characters, but the database upgraded from Exchange Server 4.0 or Exchange Server 5.0 may not be the case.
After the uninitialization page is used for the first time, it will no longer return an initialization state, even if it is emptied. Instead, set a tag on the empty page to indicate that it can be reused. This page still has a page number and checksum (even if it is empty).
What causing -1018 error When there is one of the following cases in the initialized page in the database file, Exchange will report a -1018 error:
The checksum stored on the page do not match the verification and calculation results executed when the page is read. In the case of a given page in the physical location of the database file, the page number stored on the page does not match the page number on the page. If Exchange executes one of the following, it may need to be responsible for the -1018 error generated by yourself:
Constructs a page with error checksum. Constructing a page correctly, but tells the operating system to write page to an error location. After the system administrator encounters -1018 errors, if the administrator runs the diagnostic hard disk test on the server and these test reports are not problematic, the administrator may determine the problem because the hardware has passed initial analysis.
However, once again, Microsoft or hardware suppliers should be responsible for damage to damaged database files by further research discovery, hardware, firmware, or device drivers.
For a variety of reasons, conventional diagnostic tests cannot detect all of these temporary errors. Problems in firmware or driver software may exceed the diagnostic capabilities of the diagnostics. Diagnostic tests may not be able to fully simulate long run or complex loads. Moreover, the addition of diagnostic monitoring or debug logging can cause a sufficient degree of change to the system, so that the problem cannot be reproduced.
Exchange generates checksum and writing to the database file is very simple and stable. This is another reason, further indicating that the root cause of -1018 errors may be unlike Exchange issues. The checksum and the error page detection mechanism are simple and reliable, and since Exchange is basically not moved, only some smaller modifications are performed to adapt to the database page format change between the database version. It is to be further illustrated that the checksum is generated when the page is written to the disk, and all other data (including the page number itself) is written to the page. After Exchange adds the checksum to the page, the Exchange Command Microsoft Windows operating system writes the page into the disk by using the standard, published Windows Application Programming Interface (API).
For a page, its verification may have been generated correctly, but this page will be written to the wrong location on the hard disk. This may be due to temporary memory errors, such as "bit flip". For example, suppose Exchange builds a new version on page 70. This page does not encounter an error, but the copy of the page number used by the disk controller or operating system is randomly changed. This problem may occur if the 70 (binary 100110) is changed to 6 (binary 000110) by unstable memory cells. The checksum of this page is still correct, but now this page has an error in the location of the database. When Exchange detects that the logical page number does not match the physical location of the page, the -1018 error is reported. If Exchange is written in the page itself, you may have another type of page number error (caused by Exchange). But this causes other errors, not -1018 errors. If Exchange is written to No. 71 on page 70, then check and calculate correctly on this page, the page will write to the location of 71 and can pass page number and check and test.
Often, single-1018 errors reported in the Exchange database do not cause the database to stop, and other symptoms do not cause other symptoms other than displaying -1018 errors. This page may be in a folder that does not regularly (eg, "Send Mail" or "deleted mail" folder), or in an attachment that is rarely opened even empty.
Although single-1018 errors may result in a wide range of data loss, it will still be concerned because a -1018 error proves that your storage system has not reliably stored or retrieved data. Although -1018 errors may never have a temporary issue, but this error is likely to be an early warning, indicating a problem that will become more and more serious. Even if the first -1018 error is on a blank page of the database, you don't know which page will be damaged next time. If a critical global table is destroyed, the database will not be able to start, and the database repair may not succeed, or can only be partially successful.
After recording -1018 errors, before discovering and eliminating the root cause, you must take into account this possibility of failing or further random damage to the database.
Recovering Exchange from -1018 Extraverse page will be a fully unreadable page to prevent further problems in the database from the page to prevent the database of random data by -1018 errors.
The page that the failed failure is not repaired or saved with the page-1018 error. It must be erased from the database. You can use three ways to erase the page from the database:
Restore the database from the online backup. Use the Eseutil.exe / D switch to make a downline fragmentation of the database. Use the Eseutil.exe / P switch to fix the database.
Restoring the database from an online backup If the -1018 error is found during the online backup, the backup will stop. This ensures that the damaged page does not exist on the last successful backup. If loop record is disabled, you can restore the most recently available full backup, and then scroll forward the database from later transaction logs. Using the Eseutil.exe "/ D" switch for database offshorting This method is valid when the -1018 error is present on the blank page. If the -1018 error occurs only during online backup or online maintenance of the night, it indicates that this page is very much accessed or even a blank page. Offline Debris Collection will discard all blank pages and auxiliary indexes in the database.
Use the Eseutil.exe "/ P" switch to repair the database Use this method not to repair the corrupted page, but the damaged page will be deleted. If the page involved is a "leaf-level page", some data will be lost. The leaf-level page in the database is a page carrying the actual data. The internal page is only carrying structure and logic information. In most cases, if the internal page is lost, Eseut can reconstruct the table completely. However, most of the pages in the database are leaf-level pages.
ESEUTIL's repair feature can run normally, and in most cases, the database can be reduced to the running state at least a minimum data. However, if many pages are damaged, or if the key system table is lost, data loss can be disastrous, and the database may not be repaired.
Repairing the database is usually a declaration with a backup restore and a database, because the repair is longer than the restore, and the risk is large. Select the repair only in the following cases:
You don't have a backup. - Or - You cannot scroll forward from backup. A backup copy of the current database file is required before fixing or restoring the database. If the restore cannot be successful, you can fix an existing database. If the repair is unsuccessful, but the database previous copies can still start, you may be able to save the data that will be lost if there is no previously startable copy.
Important: After repairing the database, you must check the repair count in the database title. If the count is greater than zero, you must use the ISINTEG utility to fix the database level in the information storage level. If this is not done, the user may encounter problems, such as unable to open the mail or attachment, or the reference in its mailbox points to the no longer existing content.
To check the fix count, check the screen output generated when running the following command:
ESEUTIL / MH [Database File Name] To make a comprehensive ISINTEG fix after repairing Exchange 2000, the "Information Store" service must be running, but the database to be repaired must be uninstalled. Run the following command for database repair:
Isinteg -s [server name] -fix -test allTests To stop the information storage service after fixing Exchange Server 5.5, you must stop the information storage service. Depending on the need to repair the dedicated database or a public database, use the appropriate switch (
-Pri or
-Pub) Run the following command line:
Isinteg -Pri | Pub -fix -Test AllTests
Note: You can run Eseutil and esefile on the original database file without taking care of their file system location. Database files don't even need on the Exchange server. However, when running Isinteg, the database must be on the fully configured Exchange server because isinteg runs in the information storage level and uses the information storage service to access the database.
For additional information, click the article number below to see the article in the Microsoft Knowledge Base:
244525 XADM: How to run Eseutil on a computer without Exchange Server
Recovering from -1019 Error When the page that should be used is not initialized or empty, the -1019 error will be reported to the -1019 error (JET_ERRPAGENOTITIZED). If the page number field on the page in use is 0x00000000, the -1019 error is reported instead of -1018 errors, even if the checksum testing of this page is not passed. The method of correcting the -1019 error is the same as the method of correcting -1018 errors. Note that -1019 may be discovered after discovering -1018 issues, because the -1019 problem is not detected by online backup.
Although the root cause of -1018 errors is likely to be outside Exchange, if the logical pointer or link between the page is invalid, the -1019 error may be caused by Exchange.
However, the more common cause of the -1019 error is that the file system is damaged, or the page maps to the database file that is not that the file.
Restore from -1022 Errors If Exchange requests a page in a database to the operating system, an error does not return the page data, and the result will appear (Jet_ERRDiskio). -1022 Error is a general error that this error occurs whenever the disk input / output (I / O) problem allows Exchange not accessing the page in the database it requested.
-1022 Error The most common reason is that database files are severely damaged or trimmed. If this problem occurs, Exchange will request a page number that is larger than the number of pages in the database file, which will cause the -1022 error. This problem may occur because of the issues in the file system or because of the inappropriate replay of the transaction log.
Exchange 2000 includes a wide range of preventive measures to prevent transaction log playback that may damage the database, but in Exchange Server 5.5, it is possible to play an incomplete log file and corrupt the database. For example, if the reproduction starts from the log 9, this problem may occur if it is forced from the log 10. If the administrator deletes checkpoint files and logs 9, it may be forced to play back. If a transaction in the log 9 will extend the size of the database, the log 9 is not reproduced into the database, and the reference to the new page added to the database in the log 10 will result in the -1022 error. Placing incomplete transaction log sets to frequent symptoms brought by the database also include sudden crash, stop (hang) and access conflicts.
Understand and investigate the root cause of -1022 errors complicated than investigating -1018 or -1019 errors. If this error is caused by database corruption in the file system, you need to check or fix the file system and restore Exchange from the backup. Although the repair database is still an option, the ability to repair success is not large compared to other errors, because the -1022 error tends to indicate large area damage.
So far, the most common cause of the unharacked database is -1022 error is that another application allows the file to open, so that the information storage service cannot access these files. In these cases, you may also see the -1032 error (Jet_ERRFILEACCESSDENIED). Restart all Exchange services or restart the server to lock.
Third-party procedures, such as virus scanners, may prevent Exchange from accessing Exchange data. When configuring a file-level virus scan, you always have to exclude the Exchange data file from the file scan operation. Several viral scanners use the Exchange Virus Scan Application Programming Interface (API) to scan the mail and attachments in the information store.
Analysis of -1018 and -1019 Errors This part of the information is mainly facing technical support staff and supplier personnel involved in the root cause analysis.
After the administrator discovers -1018 or -1019 error, the administrator needs at least three items: What is the possibility of repairing success on the damaged page How to repair the original cause of the damage - 1018 and -1019 error When the service is started in the command line, it may exist in the application's event log, or in the output of the Exchange utility (such as ESEUTIL). When you use
The eSeutil / g command runs the database integrity check, may not report -1018 errors in the application event log. In this case, the damaged page is probably blank.
In most cases, the form of reporting makes you can determine which page reports this error. You can also use the esefile to scan the entire database to determine the damaged page. For additional information about eSefile, click the article number below to see the article in the Microsoft Knowledge Base:
248406 XADM: ESEFILE Support Utility for Exchange Server 5.5 And Exchange 2000 The following example is a typical-1018 error description in the application event log in various Exchange versions, and includes detailed analysis of each error.
MSEXCHANGEIS (248) SYNCHRONOUS READ Page Checksum error -1018
((1: 3106 1: 3106) (0-310013) (0-312215))) occured.
Please restore the databases from a prepvious backup.
In the above example, the numbers in the parentheses should be explained below:
(1: 3106 1: 3106) On behalf of the requested page (page 3106), and page numbers actually written on the discovered page (page 3106). The "1:" representative This is the database 1, which is priv.edb in Exchange Server 5.5. Database 2 is Pub.edb. (0-310013) Represents the DBTIME value in the current write page. The DBTime value is a 64-bit value written on each page, which is approximately related to the time since the page changes. (0-312215) Represents the current dbtime value of the entire database: If this page is changed now, it is probably a dbtime value written to this page when changing. The DBTIME value already on this page should always be smaller than the current DBTIME value. Suppose the page number is read correctly from the page, and
The dbtime value is also reasonable (the first
The dbtime value is smaller than the second), indicating that this page is not fully replaced by a page outside the database or another different page.
You can use Esefile to output this page with a command with the following:
ESEFILE / D DATABASE.EDB 3106> 3106.txt Since this page seems to be completely maintained on the structure, you may be able to use Eseutil to view more logical information on this page. You can view page structure information from the Exchange 2000 and Exchange Server 5.5 database using Eseutil's Exchange 2000 version.
WARNING: When using the Eseutil's Exchange 2000, do not use any modes that may write to the database on the Exchange Server 5.5 database. For insurance, please use only
/ M switch, must not use
/ P,
/ G or
/ R. Moreover, please don't copy Eseutil.exe and Ese.dll's Exchange 2000 to Exchange Server 5.5, and you should copy these files to a remote server and provide an explicit command line of the database you want to test. Naming Convention (UNC) path. A command similar to the following will output the logical information of this page to the text file:
Eseutil / m //exchange1/date/date/Priv.edb / p3106> 3106.txt
Initiating File Dump Mode ...
Database: priv.edb
Page: 3106
Pgnothis <0x02360004, 4>: 3106 (0x00000c22)
Objidfdp <0x02360018, 4>: 19 (0x00000013)
Ulchecksumparity <0x02360000, 4>: 4269350574 (0xfe791eae)
** COMPUTED CHECKSUM: 157180847 (0x095e63af)
DBTIMEDIRTIED <0x02360008, 8>: 310013 (0x000000000004BAFD)
CBFree <0x0236001c, 2>: 436 (0x01b4)
IBMICFREE <0x02360020, 2>: 3608 (0x0e18)
ITagmicfree <0x02360022, 2>: 3 (0x0003)
CBuncommittedFree <0x0236001e, 2>: 0 (0x0000)
Pgnonext <0x02360014, 4>: 3108 (0x00000c24)
PGnoprev <0x02360010, 4>: 3088 (0x00000c10)
Fflags <0x02360024, 4>: 2050 (0x00000802)
Leaf Page
PRIMARY PAGE
From this output, you can see that the page is a leaf-level page, that is, it has actual data above. If this database is repaired, the repair process will at least cause loss of this page data. For additional information about how to find the table or mailbox to which the page belongs, click the article number below to see the article in the Microsoft Knowledge Base:
262196 xadm: how to determine Which Mailbox OWNS A Particular Page IN A Database This page is not listed in the leaf-level page of this page in the ESEUTIL output. Most internal page or structural pages can be fully refactored by the replication process.
This page may also be displayed as "blank page" in the output content. If this is the case, the offline fragmentation will discard the damaged page from the database.
Keep in mind that if a page is completely replaced by data blocks that do not belong to the database file, the ESEUTIL output content may be meaningless.
Here is another error example:
MSEXCHANGEIS ((247)) SYNCHRONOUS READ Page Checksum error -1018
Occurred. (0 - 16815256).
Please restore the databases from a prepvious backup.
In this example, page numbers actually read from (3688618977) page do not match the requested page, which means that the page title area of the stored page number has been destroyed. This page number is even possible that there is no existence at all in the database. If you want to determine if it belongs to this, multiply by page numbers by 4,096, then compare this value to the byte size of the database file. In this case, the page number is unlikely that the number originally written in Exchange unless the size of the database is 15 TB (3,688,618,971 x 4,096 = 15, 108, 583, 305, 216). Also pay attention to the first one
The DBTime value has repeated this page number mode. If 3688618971 is converted to a hexadecimal (using Calc.exe in scientific counting mode), it will become 0xdbdbdbdb. In Exchange 2000 and Exchange Server 5.5, 8 bytes
The dbtime value is kept in the 4-byte page number value stored. Therefore, you will know that at least twelve continuous bytes in two different fields are overwritten by a particular mode. If you use Esefile to view this page directly, you may find that the entire page is overwritten by 0xDB mode. Another common invalid byte mode is 0xFF. If the above error is this situation, then
The value of DBTIME will be 4294967295.
The page information provided in the following error is the byte offset in the file in the file, not the page number:
Information Store (2160) The Database Page Read from The File
"D: /exchsrvrr/mdbdata/priv.edb" at offset 897024 (0x00000000000DB000)
For 4096 (0x00001000) BYTES FAILED VERIFICATION DUE TO A Page Checksum
Mismatch.The EXPECTED CHECKSUM WAS 2651583211 (0x9E0BF2EB) and the
Actual Checksum WAS 2651582996 (0x9E0BF214) .The Read Operation Will
Fail with error -1018 (0xfffffc06) .if this condition Persists Then
Please restore the database from a previous backup.
You can convert the first offset to page numbers, the method is to delete three zero, subtract 1, and convert the results into a decimal number. In this case, 0x00000000000dB - 1 = 0xDa = 218 (decimal). You can use this decimal page number for esefile or eseutil.
Note: To take into account two headings in the database, minus 1, not to reduce 2, because the offset is from 0x0 instead of starting from 0x1. To check the title page with Esefile or ESEUTIL, point to No.1 and Page 0.
The Exchange database title is actually only a single page. The second page is the "shadow" copy of the title. After using the database is completely closed, use
ESEFILE / D TEL FOR THEFILE The validations reported for No.1 and page 0 should always be the same. If the title is rewritten during the crash, Exchange will use a copy of the title with clean checksum when restarting.
In the previous example, both checks are actually very close, only two characters are different. When the checksum is close, it indicates that the changes to this page are very small: maybe only one bit is wrong. Very likely that this page still contains enough logical structure, it is worth using
ESEUTIL / M / P analysis.
The expected verification in the error message is actually read from the page because the page is now in the database. The actual checksum in the error message is the checksum that Exchange re-dynamically calculates when reading this page.
If the actual checksum on the page is 0x89AbcDef, the page is included in the 0x00 character. If the actual checksum is 0x76543210, the page contains 0xFF characters.
Here is an example of a -1019 error:
Information Store (3928) The Database Page Read from The File
"D: /exchsrvrr/mdbdata/priv.edb" at offset 1675264 (0x000000000019000)
For 4096 (0x00001000) BYTES FAILED VERIFICATION BECAUSE IT Contains
NO Page Data.The Read Operation Will Fail with Error-1019 (0xffffc05).
IF this conputing persists1 Please restore the database from a
Previous Backup.
In a typical operation, if a page can report -1019 errors or -1018 errors, -1019 errors will be prioritized. Keep in mind that as long as the page number written on the page is 0x00000000, the -1019 error will occur, but Exchange considers that this page is in use. If the file system maps a data block by zero to the database file, or Exchange has an error and specifies a unused page as "in use", it will result in -1019 errors, but it is difficult to prove that it is. This error has caused this error which reason.
From the previous mistake, you can't see that this page is in an uninteremered state, or is in other states. This page must be checked for further check using Esefile and Eseutil. In this example, the page number is a decimal number 408 (launched from 0x199).
You can use Eseutil to further check this page.
The PGNothis value should match the page number of the query, and if the checksum on the page is wrong,
Ulchecksumparity value will report an additional
** Calculated checksum. You can use esefile
The / D switch checks the original page to determine if it is not initialized (all 0x00 characters).
False-1018 error When the page on the disk is correct but the I / O system does not correctly retrieve this data correctly, "false" -1018 errors occur. This error is usually temporary, and it is difficult to find out the cause. But even "false" -1018 errors also need to be highly valued. The reliability of the storage system still has problems, and the system may have a risk of other problems or faults.
If you have temporary read errors on your system, please use esefile.
/ D switch or
ESEUTIL / M / P inspection Every page involved. If you use any utility to scan the entire database, you can cause the I / O system tense, which may result in more erroneous.
Exchange Server 5.5 Service Pack 2 (SP2) adds a feature that can help identify temporary read errors. Exchange will reread 16 times after reading the verification failure. If the page is successfully read after several attempts, it indicates that the system has problems in reliable reading from the disk. Even if you read 16 readings, you can't assert that the page is corrupt. Use Esefile or ESEUTIL to perform a secondary test.
The database zero-adjustment database zero adjustment is used to mask information deleted in the Exchange database so that it cannot be recovered or read by direct checking database files. For additional information about database zero adjustment, click the article number below to see the article in the Microsoft Knowledge Base: 223161 XADM: Information ON ESE ZEROING If the database zero adjustment, the blank page or part is empty page Some parts may be overwritten by a particular character mode, but this page still does not return to an uninteremetled state.
