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
d:\checkpoint\
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 :
“eseutil/p<database_name>”
D:\Program Files\Exchsrvr\Bin>eseutil/p
“D:\Exchsrvr\Mailbox Store(SERVER).edb”
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.
0 comments:
Post a Comment