You’re trying to recover your Exchange database from the “dirty shutdown” state to “clean shutdown.” You use ESEUTIL /R and after several ill-fated attempts the databases remain dirty. What’s happening? Danijel Klaric. a Microsoft Premier Field Engineer based in Germany, sheds some light on why the Exchange 2007/2010 databases might remain dirty after a seemingly “successful” ESEUTIL /R recovery, and provides pointers on how to solve this. Enjoy his article!
Normally I wouldn’t think that this following topic would ever be a problem, but as I faced the issue two times in the last three weeks, I thought it would be good to shine some light on the subject.
Both customers are using Exchange 2010 with Native Data Protection, and have enabled a seven day lag on one of their database copies to enable their admins to recover items past the “single item recovery” period, or to recover deleted folder structures. Remember that single item recovery doesn’t preserve the folder structure as mails moved to the dumpster are stored in a flat hierarchy.
The Symptom
They thought they were following appropriate Microsoft guidelines to use logs needed to recover the database from the “dirty shutdown” state to “clean shutdown”, so that the database would be usable as a recovery database for extracting the needed content.
1) Collect the database and the required logs
First grab a copy of the edb file and needed logs (i.e. logs needed from database perspective and logs they would like to roll forward to). This can be accomplished by suspending the database copy, and then copying the needed files to a separate location or create a snapshot of the volume which can be reverted to at a later time.
Źródło: http://blogs.technet.com/b/mspfe/archive/2012/09/06/why-exchange-databases-might-remain-dirty-after-eseutil-r-recovery.aspx