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 Mike Lewis on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Exchange 2007 "Dirty Shutdown" State 1

Status
Not open for further replies.

JST2101

MIS
Nov 16, 2011
7
GB
Hi,

Not sure if this should be posted here or in the SBS Forum so apologies if it's incorrectly posted.

Our client has SBS 2008 and are using Exchange 2007.

Yesterday a colleague needed to shutdown the server. On reboot the Exchange Database was showing as being in a "Dirty" state.

We tried using the ESEUTIL/ISINTEG utilities but to no avail.

Eventually we managed to get the system up and running by copying and then deleting the LOG files from C:\Program Files\Microsoft\Exchange Server\Mailbox\First Storage Group.

Once the log files were removed the system came up again.

So my question is do we need to keep the log files?
If so do they need to be replayed to commit to the database?

Thanks in advance.


Jason.
 
The logs files are committed to the DB on a low priorty level. If the server doesn't hav a hight load the logs are usually committed to the DB rather quickly. They don't get purged until after a full backup takes place.

Look at the time you shut down the system and compare it to the latest e-mail you have in someone's inbox. If it's right around the same time I personally wouldn't even bother. Sounds like the last log file got corrupted.

I would keep the logs files just in case.
 
What probably happened is that the eseutil and isinteg did what they are supposed to do, but you failed to follow the instruction to delete the log files. If the eseutil had not "repaired" the database, you would not have been able to mount it.

When an Exchange server is shut down properly Exchange will commit all transaction log files to their appropriate databases before allowing the Information Store Service to be stopped. This is necessary for the databases to be in a consistent state. If the database is in an inconsistent state when the IS Service attempts to mount it, the IS Service will attempt to replay the log files to bring it into a consistent state. If this is unsuccessful the database will not mount and it will be necessary to run the eseutil to resolve the problem(s) with the database. You must always run the isinteg utility (with the -patch switch) after using the eseutil or the database will not mount. You must also delete the log files (as you did, I always copy them to another location first - just in case!). If the IS Service detects log files the eseutil told you to delete, it will not mount the DB.

One last thing: committing the log files to the database is one of the highest priority tasks in Exchange - next to message delivery and client access.

When all else fails, read the book!
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top