|
Exchange Server supports transaction logging and numbers them sequentially. It starts naming them from E nn 00001.log and goes on till E nnffff0.log, where nn represents the storage group number. When all the log files are exhausted, Exchange Server gives 'JET_errLogSequenceEnd' error and causes different issues, as discussed below. You need to remove these log files while making sure that the databases are healthy. If not, you should restore them from backup or repair using eseutil utility or a EDB Recovery Software.
Exchange Server supports transaction logging and numbers them sequentially. It starts naming them from E nn 00001.log and goes on till E nnffff0.log, where nn represents the storage group number. When all the log files are exhausted, Exchange Server gives 'JET_errLogSequenceEnd' error and causes different issues, as discussed below. You need to remove these log files while making sure that the databases are healthy. If not, you should restore them from backup or repair using eseutil utility or a EDB Recovery Software.
For instance, you might come across these symptoms in a computer running Exchange Server 2000 or 2003:
1. The connected users experience failures when trying to logon to their mailboxes. The databases become inaccessible even when they are mounted. It specifically occurs in Exchange Server 2000 that is not using August 2004 Exchange 2000 Server post-Service Pack 3 update rollup or in original version of Exchange Server 2003. The application log shows event ID 1022.
2. The databases in computer running Exchange Server 2003 SP1 or SP2 or August 2004 Exchange 2000 Server post-Service Pack 3 update rollup get dismounted without displaying any warning. When you try to mount them, it shows an internal processing error and logs event 1159 and 9518 in application log.
Cause
Exchange Server has used all the available transaction log files of storage group.
Solution
To solve the given problem, you need to reset the log sequence by removing all the log files to a different location. But before you do so, you should ensure for databases' consistency. You should follow these steps:
1. Select the ' Don't mount this store at start-up' option to make sure that they don't mount at startup
2. Dismount the database that cannot be dismounted by killing the store
3. Mount the other storage groups by restarting the store
4. Try to repair the problematic storage group databases by running eseutil /r
5. Check for databases' consistency by running eseutil /mh
6. If they are consistent, move checkpoint and log files to a different location and mount the databases
7. If the databases remain inconsistent, you should delete the damaged databases provided you have a full backup to restore. If not, you can use a powerful EDB Recovery utility to repair and restore them.
EDB Recovery Software are well-designed and exclusive applications that allow you to extract all user mailboxes from a corrupted Exchange database and restore them safely.
Stellar Phoenix Mailbox Exchange Recovery is an advanced and non-destructive utility that uses powerful scanning algorithms to repair a damaged Exchange Server database. It is compatible with Exchange Server 5.5, 2000 and 2003. It is a safe EDB Recovery tool with impressive set of features. The tool extracts user mailboxes in individual .pst file format files.
|
