This is a common Exchange error which generally occurs due to log files problems such as when some particular log files are missing from the sequence or do not match with other log files. Main reason behind this error is invalid log signature and log creation time mismatch. In situations where some log files are not present in database or corresponding header is unable to find matching file in the database, this error is displayed. However this error could also be seen in circumstances where database is restored multiple times, because at that time Exchange is left with mixed log streams. In this article few inbuilt utilities has been explained to fix this error.
How to Repair log files:
As log files are the main cause of this error, so to fix this error at first log files needed to be fixed. To fix log files in Exchange Server there is recovery mode, which use some inbuilt utilities like Eseutil /r , Eseutil /p helps to repair damaged Log files.
Repairing Log files using Eseutil /r :
Eseutil /r works in Recovery mode of Exchange Server. Recovery mode which is a process of playing transaction log files into database so as to repair Log files. In exchange normally two types of recovery are done.
1. Hard Recovery using Eseutil : This is less seen recovery mode of eseutility , which is used when transaction log files areto be replayed into online backup. Hard recovery can be done with Eseutil by using the Restore mode.
Doing troubleshooting when ESE engine is forced to replay the transaction logs, this is known as a hard recovery , hence Eseutil /r.
2. Soft Recovery using Eseutil : This recovery occurs when a database is re-mounted after unexpected stop of Exchange, or when transaction logs are to be replayed into offline backup of database.
This recovery process replays the logs after the last checkpoint. When Exchange Database is dismounted or stopped, log files start to pile up in the database, which could lead Exchange to dirty shutdown state because of missing transaction files.
After Software recovery when Mailbox store starts again, all of the unattached transactions files of those logs are written in the database, remounting those transaction files may cause a built-in soft recovery routine.
Controlling the Checkpoint File in Software Recovery
While performing soft recovery, Exchange at first check recent transactions files, and then after that from last checkpoint it reads pointers in E00.chk, on the basis of that information it knows which transactions files to commit and which to roll-back, so as to bring database in consistent state.
While running soft recovery, normally users want to delete/ move the checkpoint file as they want to safely rerun all transaction logs into database. Those checkpoint files could be controlled during a soft recovery, by adding the /S switch to the recovery command:
Eseutil /r E00 /S
Working of Eseutil /r :
Working with Eseutility in repair mode is not as easy task as it looks, you cannot run /r in ordinary situations, as improperly executed eseutil /r may result you opposite results. This solution is to be used when all other solutions has been failed to get the server working. In situations where you had restored Exchange database and you are unable to mount the store then also you can take help of Eseutil /r.
While performing recovery using Eseutil /r utility at first, take backup of Exchange database so that in case something bad happens, database could be restored from that.
Then navigate to the folder which is containing those transaction logs, and run:
eseutil /r e00 /i .
Note the sequence /r e00 /i should be correct. If your base log is e00 and not some other numberand your storage group is with multiple stores, in that case user have to dismount all stores before running the /r switch.
Repairing Log files using Eseutil /p :
If log files are not available, still you can bring your exchange database in consistent state, by executing /p switch of ESEutil. Syntax which could be used to recover Exchange database without log file is :
Note : Using this method to bring database in consistent stage is not as simple as it looks ,as this may lead user to data loss , in situations where Eseutil is not properly executed , or any structure improvement calls raised because of deletion of internal pages or if there are broken links between the table. In those situations user may need to rebuild database using offline defragmentation and correcting B-tree structure of database which obviously become a lengthy and complicated task with Eseutility.
An alternative to this complex process is going for professional Exchange recovery tools which can just calls for database file availability (healthy/offline/corrupt state) to get consistent DB. Exchange Recovery software repairs log files and recover Exchange database from Dirty shutdown state providing access to exchange data again.