Database won't mount due to missing log file

smith1974 used Ask the Experts™

We're running Exchange 2007 SP1 in SCC config. All connected to EMC SAN. Unfortunately, due to some routine work last night, some of the LUN's went down without warning.

Once the LUN's came back up again, most of the mailbox stores remounted automatically. Unfortunately, there are about two where we can't manually mount the store.

The message is that there is a log file missing.

We ran ESEUtil /mh on the store and, yes, it's in Dirty Shutdown with missing log files. Also, events logged in the App Viewer stating this too.

Bizarrely, running ESEUtil /ml shows that all log files are present and intact.

So we renamed the checkpoint on one database, then it remounted fine.

Can anyone explain why this was?
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Pete LongTechnical Consultant

has you AV deleted/quaranteened the log file? This happened to me a while back  - I jumped through a lot of hoops to get the database back when I could have simply got the AV software to restore it?

Don't forget to exclude the locations of you logfiles in your AV after you restored them via the AV Console.


Definately not an AV problem
C++ 11 Fundamentals

This course will introduce you to C++ 11 and teach you about syntax fundamentals.

what is the exact event ID's you have received?

you may refer this link for some of the dirty shutdown events

this could happen may be the log file which was getting written was got damaged when your SAN gone down and it couldnt recoverable; so what you did was is hard recovery and again the checkpoint file started creating new series of log files.... can you compare the previous log files numbers with the current log files numbers...
refer the below link for the senarios:
(though its for ex2000 but the process happens same way)



It was Event ID 452:

MSExchangeIS (1312) Storagegroup1: Database F:\Database\A2 (mailserver).edb requires logfiles 126265-126268 in order to recover successfully. Recovery could only locate logfiles starting at 126343

So from what I understand, the error is saying that log files are missing, hence the database can't be mounted. ESEUtil /mh is also saying log files are missing.  Yet ESEUtil /ml is saying all logs are there and present.

And how did renaming the .chk file help? I guess the log files were actually present and fine, but how could Exchange think they weren't?
I dont know how exchange could not the find the files which were present (may be i guess it couldn't read the logs properly when u try to mount the database)

but renaming the .chk point file which fixed the problem for you due to when the checkpoint file is destroyed, Exchange can still recover and replay log files appropriately. But to do so, Exchange begins scanning log files, beginning with the oldest file available, instead of starting at the checkpoint log. Exchange skips data that has already been applied to the database and works sequentially through the logs until data that must be applied is encountered.

Typically, it takes only one or two seconds for Exchange to scan a log file that has already been applied to the database. If there are operations in a log file that must be written to the database, it can take anywhere from 10 seconds to several minutes to apply them. On average, a log file's contents can be written to the database in 30 seconds or less.

Did you try a eseutil repair ?


Thanks everyone...

Just one last question -

What is the difference in terms of which logs Exchange replays if the .chk has been destroyed or whether it's still there? Am I correct in saying that if the .chk file is still there, then it will only replay the log files from the point at which the .chk says that the log files have not been commited?

So, in our case, could it be a case that the .chk was saying that a log file had been commited, when really it hadn't (perhaps the outage happened at the point where this log file was about to be commited)? Therefore, trying to mount the database manually meant that Exchange was not attempting to read from this log file. However, when we deleted the .chk file, it did read the file and all was ok?
This article gives you some light on ur questions; yes your assumption is right when u deleted the .chk point file and it got recreated new .chk file it searches all old log files which is available and will commit the log files.

Hope your queries are clear now... do let us know if you have more queries

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial