Greeting guys Last days a problem with an exchange 2007 sp2 installation is torturing me. The problem is that about a month ago an event 9558 has been registered on the servers (http://www.microsoft.com/technet/support/ee/transform.aspx?ProdName=Exchange&ProdVer=6.5.6940.0&EvtID=9558&EvtSrc=MSExchangeIS&LCID=1033). Since then, the server continued to function properly with the exception that backups are failing because a transaction log file is missing. A file that it was never written so it doesnt exist neither in backup nor in AV's quarantine.So the current problem is that i have about 15000 log files (i guess not commited) after that file. My questions are : Is there any way that i can commit these log files to the current database ?(i dont care about the data lost that should be in the missing log file i really care about the commitment of these 15000 files) If i cannot commit those how should i procceed ? Thank you very much Isaak

You can manually move logs that arent needed. Follow the procedure here to do that for 2007 and use the built-in toolbox utils: ( its under the User Action section) http://technet.microsoft.com/en-us/library/bb219028(EXCHG.80).aspx

Thank you very much for your response. My problem is that the missing file is required to bring the db in a consistent state or else backup wont let me take a valid snapshot . Its something like i have a missing log file but with future transaction files that have to be commited. So i dont wont to remove the transactions files without commiting them to the db first.

Information is committed to the store after the log is written. The transaction logs are really there for recovery purposes. Using the process above will tell which logs arent needed and are safe to remove.

Thanks again for your reply. But if i unmount the Database and eseutil /mh tells me that the database is in an incosistent state, will i be able to (hard) repair it and then replay the remaining logs, in case they weren't commited ? or do i lose all the info written in those transaction files ?

Hard repairs should be avoided unless you can not restore from backup. Here's the thing, at some point some positive action has to be taken. You obviously cant go one forever with no backups and the logs building. If you are not comfortable walking through the steps spelled out in that article, or have any concerns that something may go wrong, I would suggest an alternative plan of bringing up another store and moving all the mailboxes to it.

Thanks Andy Followed the link that you have sent me and all worked well. Thanks again Isaak