Hi Running Exchange 2007. I restored a database from our backup system to an RSG, however it won't mount since the restore is missing some log files. I've tried ESEUtil /cc, ESEUtil /r etc. ESEUtil /mh shows that a couple of log files (the last ones) are missing that aren't in the restore set. What I found was that running an ESEUtil /p on the recovered database allowed the DB to mount and I could provide the user with the information they needed from the restore. This raised a question though - will missing the last couple of log files for a database cause much of an issue? I know that sometimes if you're missing log files and you hard repair this can cause major problems to a database, but if it's just a couple of the last ones? Will this make much of a difference, esp to an RSG DB? Or could one of those log files be information relating to the attachment table or something which could corrupt a major part of the DB if it was missing?

Missing a few logs in and of itself will not cause the DB to become corrupt per se (however if say an AV product deletes or moves a log before its committed it will certainly cause it to come down in an inconsistent state) You may however experience some data loss and it really comes down to how many logs have not yet been played into the database and the content of the logs. One you Repair a database pre-existing logs cannot be played into the DB If you run a /P against a production database you are going to want to then run an ESEUTIL /D to defrag the DB and then ISINTEG -fix -test -alltests until there are 0 errors (you will usually need to run this a minimum of 2 times) Then as soon as possible I would recommend that you move the mailboxes into a new store and kill off the store you did the /P against. If you are running a /P against a DB for mounting into an RSG for data recovery, you dint necessarily HAVE to run the Eseutil /D nor ISINTEG against the DB, however if you get questionable results or errors during recovery then you will want to fall back and at least run ISINTEG until you have 0 errors. P.S. if you want to check out an interesting and cool EDB utility take a look at Lucid8's DigiScope http://www.lucid8.com/product/digiscope.asp since can Open, Repair, and then Browse, Search, Export Mailboxes, or an items to PST, XML and MSG from offline EDBs for Exchange 2010, 2007, 2003, 200 and 5.5 and even Recover data directly into another production Exchange server (Even cross version) Troy Werelius www.Lucid8.com

1. Missing a few logs in and of itself will not cause the DB to become corrupt per se (however if say an AV product deletes or moves a log before its committed it will certainly cause it to come down in an inconsistent state) 2. You may however experience some data loss and it really comes down to how many logs have not yet been played into the database and the content of the logs since logs can contain state actions as well, i.e. take action against a message such as delete, read, unread, etc 3. Once you Repair a database pre-existing logs cannot be played into the DB 4. If you run a /P against a production database you are going to want to then run an ESEUTIL /D to defrag the DB and then ISINTEG -fix -test -alltests until there are 0 errors (you will usually need to run this a minimum of 2 times) Then as soon as possible I would recommend that you move the mailboxes into a new store and kill off the store you did the /P against. 5. If you are running a /P against a DB for mounting into an RSG for data recovery, you dint necessarily HAVE to run the Eseutil /D nor ISINTEG against the DB, however if you get questionable results or errors during recovery then you will want to fall back and at least run ISINTEG until you have 0 errors. P.S. if you want to check out an interesting and cool EDB utility take a look at Lucid8's DigiScope http://www.lucid8.com/product/digiscope.asp since can Open, Repair, and then Browse, Search, Export Mailboxes, or an items to PST, XML and MSG from offline EDBs for Exchange 2010, 2007, 2003, 200 and 5.5 and even Recover data directly into another production Exchange server (Even cross version) Troy Werelius www.Lucid8.com