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

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?

Regards,
C

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?

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.

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.

Hi,

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

Regard's
Nashim Khan

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!!

Regards,
C

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

C