Hello 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 file for one database, then it remounted fine. Applied the same change to the others, and same result! Can anyone explain why this was?

The checkpoint file keeps track of which logs have been committed to the database and which have not. When you remove the checkpoint file and mount the database, a soft recovery is performed. All the logs are replayed and a new checkpoint is created. J

Hi John Thanks for answering. What I don't understand is that if I try and force a mount via the EMC, then we receive the message saying that log files are missing. In the Event Log, we also see this 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 ESEUtil /mh is also saying the same thing. Yet ESEUtil /ml states that all logs are present and intact. And how does removing the checkpoint file help? I understand what all log files are replayed, but we tried ESEUtil /r before removing the .chk file and this failed too.

Hi John, The following may the causes of missing log files, it is not because you try and force a mount via the EMC: 1. An online restore fails because log files are missing from the temporary folder specified in the Microsoft Windows Backup program under the temporary location for log files. 2. A hardware failure causes loss of log files in the log file sequence required for the restore. 3. After you repair the priv1.edb database by using Eseutil /p, you receive event 454 when you try to start the public information store. The error indicates that a problem is occurring when you try to replay the log files when the public information store is trying to mount. This error can occur if after you run Eseutil /p against priv1.edb, you do not remove the transaction logs. If you do not run Eseutil /p against pub.edb, the pub1.edb file is looking for a different set of log files than the priv1.edb file. Therefore, event 454 reports the files as absent. To your second question: Eseutil/r will work only when run from the folder in which the transaction log files exists, but when you don’t have all the transaction logs Eseutil/r(running this command is not a good idea unless you did not have valid backups and quarantined Exchange log file) will fail too. But when your remove the check point file, Exchange begins scanning log files, beginning with the oldest one 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 needs to be applied is encountered. So if the missing log had been recorded in disk, remove the checkpoint file, can help to resolve the problem. Here are the related articles for you: Source: ESE Event ID: 452 http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=452&EvtSrc=ESE&LCID=1033 How to Run Eseutil /R in Recovery Mode http://technet.microsoft.com/en-us/library/aa998074(EXCHG.65).aspx Exchange Transaction Logging in Exchange Server 2003 http://technet.microsoft.com/en-us/library/bb124452(EXCHG.65).aspx Best Regards, Evan

Hi John, The following may the causes of missing log files, it is not because you try and force a mount via the EMC: 1. An online restore fails because log files are missing from the temporary folder specified in the Microsoft Windows Backup program under the temporary location for log files. 2. A hardware failure causes loss of log files in the log file sequence required for the restore. 3. After you repair the priv1.edb database by using Eseutil /p, you receive event 454 when you try to start the public information store. The error indicates that a problem is occurring when you try to replay the log files when the public information store is trying to mount. This error can occur if after you run Eseutil /p against priv1.edb, you do not remove the transaction logs. If you do not run Eseutil /p against pub.edb, the pub1.edb file is looking for a different set of log files than the priv1.edb file. Therefore, event 454 reports the files as absent. To your second question: If existing transaction log files are not found by Eseutil when it tries to run recovery, it will create a new transaction log file, and try to attach the database to it. If the database is Inconsistent or in Dirty Shutdown state, the database will not be made startable. when your rename the check point file, Exchange cannot find the check point file, it will begin scanning log files, beginning with the oldest one 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 needs to be applied is encountered. Here are the related articles for you: Source: ESE Event ID: 452 http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=8.0&EvtID=452&EvtSrc=ESE&LCID=1033 How to Run Eseutil /R in Recovery Mode http://technet.microsoft.com/en-us/library/aa998074(EXCHG.65).aspx Eseutil /R Recovery Mode http://technet.microsoft.com/en-us/library/aa998075(EXCHG.65).aspx Exchange Transaction Logging in Exchange Server 2003 http://technet.microsoft.com/en-us/library/bb124452(EXCHG.65).aspx Best Regards, Evan

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?

Hi Smith, I think you have got the answer. Here is a related article for you: Understanding Transaction Logging http://technet.microsoft.com/en-us/library/bb331951(EXCHG.80).aspx If anything is unclear, please feel free to let me know and I will be glad to help. Best Regards, Evan