{"id":282,"date":"2013-12-02T04:12:53","date_gmt":"2013-12-02T04:12:53","guid":{"rendered":"http:\/\/www.itcrumbs.com\/?p=282"},"modified":"2019-02-07T04:39:45","modified_gmt":"2019-02-07T04:39:45","slug":"why-exchange-databases-might-remain-dirty-after-eseutil-r-recovery","status":"publish","type":"post","link":"http:\/\/www.itcrumbs.com\/?p=282","title":{"rendered":"Why Exchange Databases Might Remain Dirty After ESEUTIL \/R Recovery"},"content":{"rendered":"

http:\/\/blogs.technet.com\/b\/mspfe\/archive\/2012\/09\/06\/why-exchange-databases-might-remain-dirty-after-eseutil-r-recovery.aspx<\/a><\/p>\n

 <\/p>\n

You\u2019re trying to recover your Exchange database from the \u201cdirty shutdown\u201d state to \u201cclean shutdown.\u201d  You use ESEUTIL \/R and after several ill-fated attempts the databases remain dirty.  What\u2019s happening?  Danijel Klaric. a Microsoft Premier Field Engineer based in Germany<\/strong>, sheds some light on why the Exchange 2007\/2010 databases might remain dirty after a seemingly \u201csuccessful\u201d ESEUTIL \/R recovery, and provides pointers on how to solve this.  Enjoy his article!<\/em><\/p>\n

\n

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.<\/p>\n

Both customers are using Exchange 2010 with Native Data Protection<\/a>, and have enabled a seven day lag on one of their database copies to enable their admins to recover items past the \u201csingle item recovery\u201d 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.<\/p>\n

The Symptom<\/h4>\n

They thought they were following appropriate Microsoft guidelines to use logs needed to recover the database from the \u201cdirty shutdown\u201d state to \u201cclean shutdown\u201d, so that the database would be usable as a recovery database for extracting the needed content.<\/p>\n

1) Collect the database and the required logs<\/h5>\n

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.<\/p>\n

2) Check database state<\/h5>\n

Run the following: eseutil \/mh "c:\\DBRecovery\\Mailbox Database 0436312751.edb"<\/em><\/strong><\/p>\n

\"eseutil<\/a><\/p>\n

Check the database header for log files generation needed for the recovery, in this case: Log Required 124-124 (0x7c-0x7c) <\/em><\/strong>which means file E000000007C <\/strong>. <\/em>These log files are needed at a minimum to recover the database to a clean shutdown without data loss.<\/p>\n

Side note: <\/b>If you try to recover the database with only \u201cLog Required\u201d logs and NOT \u201cLog Commited\u201d logs it will throw the following error:<\/p>\n

\"Side<\/a><\/p>\n

You can continue with the recovery using \/a<\/b>. And the last committed transaction will be removed from the database and the database will have a clean and consistent state. Otherwise just add the log files mentioned in the \u201clog committed\u201d <\/i>field to your log directory and this error will disappear.<\/p>\n

3) Check consistency of needed logs<\/h5>\n

Before starting to apply the logs you would like to, it\u00b4s important to check if all logs are consistent and available. If you need to handle a large number of logs and have used the Windows Explorer to copy the files, occasionally I\u2019ve seen that some files are missing when sorting them in the Windows Explorer view.<\/p>\n

To ensure that you will not fail afterwards when performing the recovery, take a moment and check these. Use eseutil \/ml<\/strong> together with your log directory path and log prefix, in my example E00.<\/p>\n

Log file check within directory: eseutil \/ml c:\\DBRecovery\\E00<\/i><\/b><\/p>\n

\"Log<\/a><\/p>\n

4) Recover database state to \u201cclean shutdown\u201d<\/h5>\n

After they finished both checks successfully, they started the recovery using:<\/p>\n

eseutil \/R E00 \/l "c:\\DBRecovery" \/d "c:\\DBRecovery\\Mailbox Database 0436312751.edb"<\/i><\/b> <\/b>
\"eseutil<\/a><\/p>\n

It failed with an Error \u201c-1216\u201d. They did some Internet research and found that this could be fixed by using the \u201c\/i"<\/i><\/b><\/p>\n

So their next try was:<\/p>\n

eseutil \/R E00 \/l c:\\DBRecovery \/d "c:\\DBRecovery\\Mailbox Database 0436312751.edb" \/i<\/i><\/b> <\/i><\/b><\/p>\n

\"eseutil<\/a><\/p>\n

And YES<\/b> it results in \u201cOperation completed successfully in 0.140 seconds.\u201d<\/i> Then they checked the Application event log and YES,<\/b> there is no Error.<\/p>\n

\"Application<\/a><\/p>\n

Their last check before mounting the database was eseutil \/mh "c:\\DBRecovery\\Mailbox Database 0436312751.edb."  <\/i><\/b>After all that work – STILL a \u201cdirty shutdown\u201d \"Sad.<\/p>\n

Note:<\/b><\/p>\n

The get quick access to their data, they executed the eseutil<\/i> <\/b>command using \/P<\/i><\/b> for a repair to get the database into a clean shutdown. Microsoft strongly discourages using eseutil \/P<\/i><\/b> because it may lead to data loss. The \/P<\/strong> should be a measure of extreme desperation when there\u2019s no way at all to recover your database via \/R<\/strong>.<\/p>\n

Troubleshooting Steps \u2013 How did we solve it?<\/h4>\n

They showed me their eseutil command:<\/p>\n

eseutil \/R E00 \/l "c:\\DBRecovery" \/d "c:\\DBRecovery\\Mailbox Database 0436312751.edb\u201d \/i<\/i><\/b><\/i><\/p>\n

I saw three things I wouldn’t expect to see:<\/p>\n

    \n
  1. \u201c\/i\u201d<\/i><\/b> is a parameter for skipping missing log stream attached databases. In older versions of Exchange one log stream was used per storage group. As a storage group could have contained multiple databases, the \u201c\/i\u201d option was provided when only one out of multiple databases has to be recovered.   As Exchange 2010 doesn\u2019t use storage groups any more, this parameter shouldn\u2019t be used any more. <\/li>\n
  2. \u201c\/d\u201d<\/i><\/b> parameter with the fully qualified path to the EDB file.  You HAVE to use the directory path and NOT the full path to the edb file. <\/li>\n
  3. They also didn\u2019t specify a system path, so the actual path of the cmd prompt is used. This directory is used to check for, or to create, an E0x.chk file. I always recommend specifying the same path as the edb and log directory to keep the files together, and ensure that the files you expect to be used are the ones which are always used.<\/li>\n<\/ol>\n

    First, I asked them to remove the \u201c\/i\u201d<\/b> parameter and to try it again, they told me that this resulted in the previously mentioned error:  \u201c-1216 (JET_errAttachedDatabaseMismatch)\u201d.<\/p>\n

    Checking the EventLog after removing the \u201c\/i\u201d<\/b> parameter, it stated that the database file has not been found at path \u201cC:\\DBRecovery\\Mailbox Database 0436312751.edb\\Mailbox Database <\/i>0436312751.edb" <\/i>which makes sense.<\/p>\n

    \"Checking<\/a><\/p>\n

    After removing the file name and ending \u201c\\\u201d, and optionally adding the system directory parameter to the command, we ran eseutil<\/strong> \/R E00 \/l \u201cc:\\DBRecovery\u201d<\/strong> \/s \u201cc:\\DBRecovery\u201d \/d \u201cc:\\DBRecovery\u201d.  <\/b><\/i>Running this modified command, everything worked as expected and the database ended up in a \u201cclean shutdown\u201d without any error message.<\/p>\n

    \"eseutil<\/a><\/p>\n

    Note:<\/b> If the database still stays in \u201cdirty shutdown\u201d, check the specified system directory for an e0x.chk<\/strong> file from your previous attempts. This checkpoint file can be safely removed for this recovery process if only logs that are needed for your recovery exist in the log directory. Following that, the command should complete successfully.<\/p>\n

    So why was this happening?<\/h4>\n

    I was wondering why two different customers would make the \u201csame\u201d mistake using eseutil \/r,<\/i><\/b> so I started some Internet research and found sites providing examples using \u201ceseutil \/r \/d\u201d<\/i><\/b> with the full path to the edb. This will simply not work.  Most of these mention that sometimes this will not work \u2013 and recommend using \/p<\/i><\/b> to perform a repair of the database. As mentioned, this shouldn\u2019t be the recommended way as long as the edb file and the required logs exist and are available to be used.<\/p>\n

    Another possible misunderstanding would be that eseutil<\/i><\/b> also incorporates another \u201cMODES OF OPERATION\u201d which use \u201c\/d\u201d<\/i><\/b> as a parameter \u2013> Database defrag. So if you use \u201ceseutil \/d\u201d<\/i><\/b> to defrag a database you have to specify a complete file path.<\/p>\n

    Hope this helps. And after reading through this, just sit back and use the ESEUtil parameter which you should try out with your Exchange 2007\/2010 server (without any risk):  \u201ceseutil \/ESE.\u201d  <\/i><\/b>And give them their credits providing such a solid database \"Smile\".<\/p>\n

    Thanks goes to Alexandre Costa and James Cameron reviewing this content.<\/p>\n","protected":false},"excerpt":{"rendered":"

    http:\/\/blogs.technet.com\/b\/mspfe\/archive\/2012\/09\/06\/why-exchange-databases-might-remain-dirty-after-eseutil-r-recovery.aspx   You\u2019re trying to recover your Exchange database from the \u201cdirty shutdown\u201d state to \u201cclean shutdown.\u201d  You use ESEUTIL \/R and after several ill-fated attempts the databases remain dirty.  What\u2019s 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 […]<\/p>\n","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-282","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/posts\/282","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=282"}],"version-history":[{"count":1,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/posts\/282\/revisions"}],"predecessor-version":[{"id":685,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=\/wp\/v2\/posts\/282\/revisions\/685"}],"wp:attachment":[{"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=282"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=282"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/www.itcrumbs.com\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=282"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}