From: Virginia, USA
Here is the fix for this error, I had been waiting to solve this problem since a long time
I would like to say thanks for all of you who had input to this problem, and
especially to Jim MCBee
for excellent explanation, which took care of my problem
below if Jim post
this worked for me ===========>4) If that does not do it, run ESEUTIL /P against the database, than I was able do offline defragment.
Posted by Jim McBee (Member # 26998) on July 16, 2005, 10:45 PM:
As you have found, you have corruption in your database. This is probably preventing online backups from running,
too. First of all, here is a really good article that will help you understand what is (or may have happened) to your
database. Based on what you put in your posting, I would have expected to see a -1018 error, but I did not. I'm
hoping that this is all relevant to you.
Understanding and analyzing -1018, -1019, and -1022 Exchange database errors
Do you know when this corruption occured? If recently, the best bet is to restore from the last good backup. Then
let the transaction logs replay. Of course, that assumes you have a recent good backup and that you have been
doing online backups, and that you have all of your transaction logs since before the corruption occured.
Here is a quick rundown on what I would do.
1) Make sure the store is dismounted. It probably is already.
2) Perform an offline backup of the EDB, STM, and LOG files (first rule of data recovery is "Do No Further Harm".)
3) Run ESEUTIL /D against the database. That might actually fix it. Doubtful, but there is a small chance that the
corruption is in the whitespace of the database that is discarded during the /D.
4) If that does not do it, run ESEUTIL /P against the database
5) Run ESEUTIL /K again to make sure the corruption is cleared up.
>Follow these Steps:
>Start the Information Store service. Mount all the stores
in System Manager.
>After 5 seconds, dismount all the stores from System
Manager (but let the IS
>service be running).
>When you do this, the store status will be updated for the server
6) Run isinteg servername -fix -test alltests against that database. You may need to run it several times until it reports no
7) Try and remount the database. Run a full online backup of the entire storage group since doing a /P or a /D
resets the log file signature, so you need new backups from this point foward.
The problem with doing any sort of repair of a corrupted database is that you just don't know how damaged the
database really is. It could be one page (and only part of one message), or it could be thousand's of pages and
thousand's of messages.
How do you keep this from happening again? Page-level errors almost always are storage-level problems.
1) Do a good backup
2) Update the BIOS of the computer
3) Update the firmware of any of the SCSI controllers
4) Make sure you have a recent version of the disk adapter device driver.
Hope this helps a little. Good luck!
I love reading Jim;s exchange server 2003 24seven, book as well, excellent source
< Message edited by consultOz -- 18.Sep.2005 4:22:46 AM >
Oz Casey Dedeal
MCITP (EMA),MCITP (EA), MCITP (SA),
MCSE 2003 M+ S+, MCDST
Security+, Project+ ,Server+