Shulou(Shulou.com)06/02 Report--

Microsoft Exchange error

Failed to load database "xxxx".

Xxxx

Fail

Error:

Exchange was unable to mount the specified database. The specified database: WIN2003\ xxxx\ xxxx; error code: MapiExceptionCallFailed: Unable to mount database.

(hr=0x80004005, ec=-515)

First of all, I declare that I am using exchange server 2007.

There are similar errors, such as 544 and 455 errors, mainly due to the loss of log files in the database or errors. It can be solved in the following ways.

The program eseutil.exe is used here, which is\ bin\ eseutil.exe in the installation directory of ex.

Okay, let's do this to recover the log files.

First turn off the antivirus software, mainly to prevent it from scanning the directory installed by ex to cause file locking and other problems, and then in the directory where the database in question is located, such as

\ exchange\ mailbox\ firststroagegroup directory is the directory where the database is located, so run cmd on this folder, and then type eseutil-p "xxx.edb" in the command window

Then run eseutil-mh "xxx.edb", check the status in the displayed results = Clean shutdown or state=cleanshut;, and then we proceed to the next step to run eseutil / r

E00, run after you will see a lot of log files, here will finally remind you that the last log file is such as 0ad, missing log file 0ae, which means that the loss of the 0AE.LOG file, never mind, do the following, (note) although after the loss of 0ad data, but also better than not loading the database! Come on, go on:

Find the latest LOG file in the\ exchange\ mailbox\ firststroagegroup directory and rename it to the first three characters of the LOG file, such as the LOG file whose full name is "e000000000ad"

Change it to "E00". Similarly, if it is "e010000000ad", change it to "E01". At this time, you will find that the file E01 is duplicated in this folder. Back up the original file.

Delete it, and then rename 0AD to E00, all right, it's done, go to EMC to load this database to try, is it OK to milk?

Haha, other databases also operate in this way, and OWA can access Gaga normally again!

The following is the official statement given by Microsoft, which is actually the same as mine, but only as a roundabout point:

Restore the Exchange log file using one of the following methods:

Method 1: if the Exchange log file is quarantined

Restore the Exchange log to the folder that contains the production log file.

Start the Microsoft Exchange Information Store service. If no other log files are missing, the database will be mounted. If other log files are missing, check to see if the missing log files are located in

In the quarantined folder of the antivirus program. If the log file is not in the quarantined folder, see method 2.

If the Exchange log file is deleted, the storage group database must be restored by backup. The log file must then be replayed. To restore an available database, perform the following steps:

Method 2: if the Exchange log file is deleted

Move all inconsistent databases to the backup folder.

If you created a new E00.log file, move the new E00.log file to the backup folder. In addition, move the E00.chk file to the backup folder.

Copy all existing log files to the backup folder. Note that the log file must be copied. Do not move log files.

Rename the latest E00*.log file to E00.log.

Restore the database by backup. Then replay the log file. This keeps the database in a consistent state. However, E00.log files copied to the backup folder are not included in the database. Despite the existence of a

Fixed data loss, but now you have a database that can be mounted.

Note:

If the database cannot be restored by backup, run the repair utility on the database to keep the database in a consistent state

Start the MicrosoftExchange Information Store service.

If you ran the eseutil / p repair command on the affected database but did not delete the log files, perform the following steps:

To determine if the eseutil / p command was run, do the following:

Click start, click run, type cmd, and then click OK.

Type the following command at the command prompt:

Copy the code

C:\ programfiles\ exchsrvr\ bin\ eseutil / mh "c:\ programfiles\ exchsrvr\ mdbdata\"

The above syntax assumes that the following conditions are true:

The Exchange Server program files are installed in the c:\ program files\ exchsrvr folder.

The database is located in the c:\ program files\ exchsrvr\ mdbdata folder.

Read the repair count property. If the repair count property is 0 (zero), the eseutil / p command is not run. If the repair count property is not 0, the eseutil / p command is run on the database.

If the public and private databases are in a consistent or cleanly closed state, you can move the transaction log files to another folder. To determine whether the database is in a consistent state or clean off

In closed state, please perform the following steps:

To determine whether the database is in a consistent or clean closed state, do the following:

Click start, click run, type cmd, and then click OK.

To check the private information store, type:

Copy the code

C:\ programfiles\ exchsrvr\ bin > eseutil / mh "drive:\ programfiles\ exchsrvr\ mdbdata\ priv1.edb"

To check the public information store, type:

Copy the code

C:\ programfiles\ exchsrvr\ bin > eseutil / mh "drive:\ programfiles\ exchsrvr\ mdbdata\ pub1.edb"

The syntax in steps 2 and 3 assumes that the following conditions are true:

The Exchange Server program files are installed in the c:\ program files\ exchsrvr folder.

The database is located in the c:\ programfiles\ exchsrvr\ mdbdata folder.

Review the results of the consistency check. If the database is in a consistent state (state = clean shutdown), all log files have been committed to the information store. If the database is in an inconsistent state (status =

Dirty close), the database may not be damaged. The log file may not have been submitted to the database.

If the status shows clean shutdown, move all log files in all mdbdata directories to the backup folder.

Load the database.

If you ran the eseutil / r restore command with the incorrect log file base name, run the command successfully using the correct switch. The basic names of commonly used log files are e00, e01,

E02 and e03. For example, the following command contains the correct base name of the log file:

Copy the code

Eseutil / r e00

ESE 455-1811 (0xfffff8ed): missing current (Exx.log) transaction log file to send feedback

The Microsoft Exchange Database Troubleshooter tool detected one or more ESE 455 events with error code-1811 (0xfffff8ed) in the application log. This event list

Indicates that the current transaction log (exx.log) is missing, inaccessible, or has a mismatched signature.

explain

This error may be caused by the following reasons:

Error 1811 corresponding to JET_errFileNotFound. The problem may occur in Exchange log files with mismatched signatures and internal log generation numbers (LGeneration). Pass

Often, Exchange log files are E00.log files. If the E00.log file has mismatched signatures, the information store may not be loaded even if the database is consistent.

The antivirus program isolated or deleted the current Exchange log file.

The eseutil / p repair command was run for the affected database and the log files were not deleted.

The eseutil / r restore command was run with the incorrect log file base name, for example, eseutil / r Exx.log, where Exx.log is the three-character log file base name.

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.