Article ID: 975978 - Last Review: December 28, 2009 - Revision: 1.0

When you recover an Exchange Server database on an Exchange Server 2003 server, the Exchange Server database cannot be mounted

View products that this article applies to.

System TipThis article applies to a different operating system than the one you are using. Article content that may not be relevant to you is disabled.

Expand all | Collapse all

SYMPTOMS

When you recover an Exchange Server database on a Microsoft Exchange Server 2003 server, you experience that the database cannot be mounted. Additionally, the following event messages are logged in the Application log:

Event ID : 452
Source : ESE
Type : Error
Generated : 8/14/2009 10:23:09 AM
Machine : Exch-Ser-Name
Message : MSExchangeIS (6640) SG07: Database S:\SG07DB\MB03DBSG07.edb requires 
logfiles 27974-27995 in order to recover successfully. Recovery could only locate 
logfiles starting at 27994.

Event ID : 454
Source : ESE
Type : Error
Generated : 8/14/2009 10:23:09 AM
Machine : Exch-Ser-Name
Message : MSExchangeIS (6640) SG07: Database recovery/restore failed with 
unexpected error -543.

Event ID : 9518
Source : MSExchangeIS
Type : Error
Generated : 8/14/2009 10:23:09 AM
Machine : Exch-Ser-Name
Message : Error 0xfffffde1 starting Storage Group 
/DC=edu/DC=ohsu/CN=Configuration/CN=Services/CN=Microsoft 
Exchange/CN=ORGExchange/CN=Administrative Groups/CN=Exchange Administrative Group 
(xxxxxxxxxxx)/CN=Servers/CN=EX-MB03/CN=InformationStore/CN=SG07 on the Microsoft 
Exchange Information Store.

Storage Group - Initialization of Jet failed.

Back to the top

CAUSE

This issue occurs because the referenced transaction log in the E07.chk file has increased beyond the log files that are required in the header file of the Exchange database.

Back to the top

RESOLUTION

Before you can resolve this issue, you must verify that you have this specific issue and that all transaction log files that are required by the database are present and readable. To do this, follow these steps:

Open a command prompt and dump the database header by using the following command:
Eseutil /mh <path to .edb file>
This command shows you that the database is in a "Dirty Shutdown" state. The database requires the transaction log files that resemble the following: 27974-27994 (0x6d46-0x6d5a)

Note The transaction log numbers and names are only examples. Your transaction log numbers and names will differ.

Obtain a dump header of the E07.chk file by using the following command:

ESEUTIL /MK <Path to E07.chk>

The output of this command resembles the following :

Extensible Storage Engine Utilities for Microsoft(R) Exchange Server
Version 08.02
Copyright (C) Microsoft Corporation. All Rights Reserved.

Initiating FILE DUMP mode...
Checkpoint file: E07.chk

LastFullBackupCheckpoint: (0x0,0,0)
Checkpoint: (0x6D5A,55,1FF)
FullBackup: (0x6D5A,8,16)
FullBackup time: 08/14/2009 07:05:20
IncBackup: (0x6C00,8,16)
IncBackup time: 08/13/2009 03:15:17
Signature: Create time:05/06/2009 12:40:17 Rand:2702634 Computer:
Env (CircLog,Session,Opentbl,VerPage,Cursors,LogBufs,LogFile,Buffers)
( off, 652, 32600, 16384, 32600, 2048, 2048,2000000000)

Operation completed successfully in 3.588 seconds.

Note In this case, the header of the checkpoint file is located in the 0x6D5A (Decimal=27994)transaction log file.

Verify that all transaction logs required by the .edb database are present and readable. To do this, follow these steps:

Open a command prompt in the directory that contains the transaction log files for the storage group.
Use the following command to dump the sequence of transaction logs in this directory.
Eseutil /ml E0X
Note This command verifies that all transaction logs are readable and that there are no gaps in the sequence of log files.

In this case, you see the output resembles the following:

Extensible Storage Engine Utilities for Microsoft(R) Exchange ServerVersion 
08.01Copyright (C) Microsoft Corporation. All Rights Reserved.Initiating FILE DUMP 
mode...

Verifying log files...
Base name: e07

Log file: S:\SG07Log\E0700006D45.log - OK
Log file: S:\SG07Log\E0700006D46.log - OK
Log file: S:\SG07Log\E0700006D47.log - OK
Log file: S:\SG07Log\E0700006D48.log - OK
Log file: S:\SG07Log\E0700006D49.log - OK
Log file: S:\SG07Log\E0700006D4A.log - OK
Log file: S:\SG07Log\E0700006D4B.log - OK
Log file: S:\SG07Log\E0700006D4C.log - OK
Log file: S:\SG07Log\E0700006D4D.log - OK
Log file: S:\SG07Log\E0700006D4E.log - OK
Log file: S:\SG07Log\E0700006D4F.log - OK
Log file: S:\SG07Log\E0700006D50.log - OK
Log file: S:\SG07Log\E0700006D51.log - OK
Log file: S:\SG07Log\E0700006D52.log - OK
Log file: S:\SG07Log\E0700006D53.log - OK
Log file: S:\SG07Log\E0700006D54.log - OK
Log file: S:\SG07Log\E0700006D55.log - OK
Log file: S:\SG07Log\E0700006D56.log - OK
Log file: S:\SG07Log\E0700006D57.log - OK
Log file: S:\SG07Log\E0700006D58.log - OK
Log file: S:\SG07Log\E0700006D59.log - OK
Log file: S:\SG07Log\E0700006D5A.log - OK
Log file: S:\SG07Log\E07.log - OK

No damaged log files were found.

Operation completed successfully in 0.578 seconds.

Note Make sure that all log files that are required by the database are present in the transaction log file directory.

After you do this, rename the .chk file to E07.chk.old and then mount the database again. Therefore, the database ignores the .chk file and reads all required log files into itself.