Posted by: B00M3R
Database, Database corruption, Exchange, Exchange databases, Exchange Tracking Center, Information Store, Transaction logs
In the first part of this corruption post I spoke of what happens when an Exchange database goes corrupt on you. I also mention it can happen at page level, database level or store level. I mentioned hardware as well which will cause problems. This post will concentrate on the 1018 error.
The common type as mentioned of database corruption is at the page level. You’ll get heaps of different error messages the can potentially relate to this type of corrupt database. The most common being 1018, now we have all seen the 1018 Jet_errReadVerifyFailure (havent we?) Most of the time this error indicates that the page has the incorrect checksum value or the page number is incorrect. Microsoft Exchange will begin reading the database page by processing the page number; this is so it knows its reading the correct data. If for some reason the number is different from the expected number, then yes you guessed it exchange generates the 1018 error.
Otherwise Microsoft Exchange will calculate a checksum value for the page then verify the calculated value and make sure it matches the stored checksum value. If it does match then the page is assumed to correct and valid otherwise, yes again the 1018 gets generated.
Should I take the 1018 seriously?
The 1018 is often a warning that bad things are on their way. Exchange is trying to tell you that the database has failed once and may go again. Normally they will be non fatal failures; however future failures could be worst and corrupt the store.
So if you haven’t worked it out already the 1018 is associated with an individual page within the database rather than the whole database. The 1018 is normally not fatal and some may take it as of no interest at all because Exchange has been known to generate this error with infrequently used data such as in a deleted items folder or just a plain old blank database.
What do I do with the 1081?
Try and find more about the error before trying to repair, first instinct is to fix but learn more about it first. This way you can try and determine exactly what data was affected and how fatal the failure is, also what’s the likelihood of it happening again.
In the next section we will look further at the 1018 but in the meantime check out some of the links on the 1018 error.