Exchange 2007 failure to mount error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment

Hi.  I have an exchange 2007 server and after a "compact" was done on it's virtual instance.  I seem to have come into a dirty shutdown state and now cannot mount it.

State: Dirty Shutdown
Log Required: 489316-489335 (0x77764-0x77777)
Log Committed: 0-489336 (0x0-0x77778)

Running recovery fails on this command:

eseutil /r e00 /l "E:\Program Files (x86)\Microsoft\Exchange Server\Mailbox\First Storage Group\bak" /d "E:\Program Files (x86)\Microsoft\Exchange Server\Mailbox\First Storage Group\Mailbox Database.edb" /a

After testing and trying to re-run the log files I get an error:

Operation terminated with error -1216 (JET_errAttachedDatabaseMismatch, An outstanding database attachment has been detected at the start or end of recovery, but database is missing or does not match attachment info) after 0.328 seconds.

All the log files check "Ok" on eseutil /ml E00

There is NOTHING on the web of how to bypass this or even just take a loss of the 5 hours it was down and get it mounted again.

I do not want to run a eseutil /p for fear of even more damage.  

Does anybody know how to get rid of the attachment inconsistency and get this mounted again.

I don't have enough disk space to even do all the defrags etc as it builds an entire db in-line.

crud...need some help:-(

Who is Participating?
Seth SimmonsConnect With a Mentor Sr. Systems AdministratorCommented:
iMonkey69Author Commented:
Holy crud.  You're magic. I think I had tunnel vision.  I DID see this, but one article switched on /a which errored.  This still has me in a "dirty shutdown" state.  

Have a next step on that?

Seth SimmonsSr. Systems AdministratorCommented:
couple things...

1) i noticed in the eseutil /r command you ran it shows the path as program files (x86) - are you running 32bit version of exchange or is that just happen to be a manual path created on that volume?

2) it's been a while since i've needed to do a database repair (since 2003 days) so trying to remember everything...if you notice the link i sent with the /d switch it specifies a path while you have the total database name.  without having a 2007 server in front of me at the moment, transaction logs are per storage group, not the database itself so it would be the path where the database group resides (notice the 4th screenshot in that article).  have you tried with /d using just the path to first storage group instead of directly to the .edb?
Simplify Active Directory Administration

Administration of Active Directory does not have to be hard.  Too often what should be a simple task is made more difficult than it needs to be.The solution?  Hyena from SystemTools Software.  With ease-of-use as well as powerful importing and bulk updating capabilities.

iMonkey69Author Commented:
I did get to the "path" only solution.  Have not managed to shake the dirty db.  I have the "required" logs, but they don't seem to be helping.  I'm not sure what triggers them.  I've separated them in a "back" folder with the E00.log file, but although it did complete with /i option, now I seem to be getting the following. Running with /a returns the same.  So, I'm not sure where the logs are supposed to be in or if that's a red herring?

Recovery has indicated that there might be a lossy recovery option.  Run recovery with the /a argument.

n terminated with error -528 (JET_errMissingLogFile, Current log file missing) after 0.219 seconds.
iMonkey69Author Commented:
An update to that.  Separating the required files in a back with the old E00.log returns the lossy error.  if they are in the regular log dir the /i and /a return completed, but the dirty state stays the same.

dang it. feels so close.  a /p will take 2 days I'm sure.
nashim khanExchange AdministratorCommented:

Please move the log file to other location and desable any third party antivirus service.And then try to mount the same.

Nashim Khan
iMonkey69Author Commented:
The end result was that I was lucky enough to have a backup from 12AM the previous night.  The virtual VHD file compact seems to have been the culprit to some degree.  Ultimately, I learned a whole lot with the eseutil command prompt.  I never did use the repair /p command although I started it on a copy to see how long, and holy cow....that's a risky proposition with a DB of any significant size.  I certainly could not wait for that.

From the backup (with logs) I managed to commit the logs and get to a "Clean State".  I copied that into the production directory after clearing out ALL other chk and log files and mounted it to allow fresh files.  It was unfortunate as while I had my current log files still, one in the middle of ~10 had an off time stamp, and from what I gather it's done at that point unless you want to wait 3 days for a /p run with zero guarantee's.  

I believe users were at risk of losing some email between I'd say 1-2am and 9am. Not a bad compromise being on a Saturday and the jury is still out if they get sent on a retry later.

Thanks seth2740, I think I was deep into tunnel vision and you gave me great perspective and a clearer head with a few tips to boot.  Much appreciated.

We're live and after 33 hours with 1 hour's sleep all systems are even better(all that maintenance while waiting;)

A Good lesson in validating your backups!!  Without that, 15 years of data would have been gonzo!!

iMonkey69Author Commented:
Sooo happy guys like this are out there in the wee hours when it counts!!

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.