Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations Chriss Miller on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Database repair - eseutil /p stops responding 1

Status
Not open for further replies.
Nov 20, 2003
51
DK
This weekend our AntiVirus program quarantained the edb.log file causing our Exchange 5.5 immediately to crash.

After restoring the edb.log file from the quarantaine, we ran eseutil /mh which informed us, that both information stores where inconsistent.

Running eseutil /r we could re-establish the public information store, but the private store is still inconsistent.

When starting eseutil /p on the private information store, the utility checks the database integrity, finding several inconsistencies, scans the database up to 100%, but stands still when starting repairing the database!!

The only indication for a problem is an event 136/ese97 "(2248) The database engine lost one page of bad data", which is not described anywhere on the net.

Can someone help me in this matter. Unecessary to tell, that urgent help is required....

Thanks in advance for your help

/Markus
 
Depending on the size of your database and the amount of corruption, the repair could take _many_ hours. The standard is 4-6 gigs per hour, plus an hour or so with complications. I wouldn't necessarily trust the progress bar. How long have you waited?

The error you got isn't unusual. It just means that there is some data that will be lost in the repair process. The loss will probably be quite insignificant, but it's hard to say.

I recently read of someone hitting Ctl+C during a very stalled repair and all of a sudden things started moving along again. Don't ask....

What exactly are the events that occur when you try and start the Information Store? If you have any more information (ie event codes, errors, etc) post them.

Let us know how things are looking.

ShackDaddy
 
I agree with Shack. Personally I'd leave it 24 hours before assuming a problem.
 
Jeps, we did that (almost) 8½ hours in the first time, tried the Ctrl+C but got back to the command promt right away, and tried the repair again, this time for approx. 14 hours.... But, no result from either attempt.

The database has a size of small 13Gigs, which with a "normal" throughput shouldn't be an abnormal operation?!

Starting the IS results in application event 1120 & 5000 informing us, that the database is inconsistent - Nothing new here...

The repairing process creates two files repair.edb (384MB) and repair.txt (1.14GB), which have this size from start to end and do not change the whole time.
 
Well, if the store is too corrupted to repair, you might still be able to extract the bulk of your email from the store. Are you ready to look at 3rd party solutions, like Ontrack's PowerControls? You're probably all over this already.

ShackDaddy
 
Hi ShackDaddy,

thanks for your reply once again. And, yes, I allready abandonned all hope, deleted the information store (after taking another backup), created a new one, and restored the mailboxes from our backup.

But still, there are some mails, contacts, appointments etc. from between our last backup and the crash the day after, which we are very interested in.

So, your tip was very welcome, I already downloaded the first version which I'm going to try right away. ;-)

Markus
 
If you have confusion on the error codes, the utility Error.exe can be found on the Exchange CD. this translates the codes into Jet messages. Then search in these, not the obscure codes.

I would suggest that the DB is inconsistent as the logs dont relate to the actual content of the DB. So when you start the IS service, they dont match. Any Old logs wont be replayed into the new DB post defrag, as this is viewed as a different file (new signature etc).

You dont say what AV software you are using, but change the jobs to add an exclude to all \exchsrvr\ directories. this should be handled from within an exchange aware program, not on the file system.
E.g. if using NetShield, exclude scanning on these folders, and use Groupshield within Exchange to do that information.
(Tip: if you install these in the same dir, you only need to update one to update the other - Netshield can be scheduled)

Good Luck!


 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top