The database is removed when you mount a blank information store in Exchange 2000 Server or in Exchange Server 2003 (843092)


The information in this article applies to:

  • Microsoft Exchange Server 2003 Enterprise Edition
  • Microsoft Exchange Server 2003 Standard Edition
  • Microsoft Exchange 2000 Enterprise Server
  • Microsoft Exchange 2000 Server

SUMMARY

In the past, you may have frequently mounted stores with blank databases in Microsoft Exchange 2000 Server or in Microsoft Exchange Server 2003 to troubleshoot a particular database. For example, you may have used this method in situations where existing databases do not mount. However, before you use this method, you may want to consider the following scenario. If the production store appears to be corrupted, you may want to restore the mailbox store from a backup. If you restore the mailbox store in question, you do not see messages that were in the mailbox store before you mounted the blank store. You only see the messages that were generated after you mounted the blank store. Although you apparently restored the mailbox store correctly, you did not receive any part of the data from the backup.

SYMPTOMS

Real-life example 1



The following scenario illustrates what the problem with mounting the blank store could entail.

Suppose that you have the following:

Server name: SERVERA
Storage Group name: SG1
Mailbox stores in SG1: MBX1, MBX2, MBX3

Suppose that the mailbox store MBX2 would not mount for some reason, and that you want to troubleshoot this problem.

In this scenario, one of the troubleshooting steps that you took is that you moved out the databases for MBX2. You moved both the .edb and .stm files, and then you mounted the blank store. The blank store mounted. Therefore, you know that you have database problems. At this point, it is not important if the original database files were in the "Clean Shutdown" state or in the "Dirty Shutdown" state.

Then, suppose that you go ahead and restore the MBX2 database from the backup that was done before you moved out the databases for MBX2. Now you are restoring only the MBX2 store. After the MBX2 store is restored, it replays through the log files on the hard disk. The MBX2 store replays both the logs restored from the tape and the logs created since the last online backup was done.

The result is that the MBX2 store is restored without any errors, but it contains e-mail messages only from the time period after you mounted the blank store up to the present. None of the e-mail messages that were on the tape that you were trying to restore are there, but the restore completed without any errors.

Real-life example 2



Suppose that you have the following:

Server name: SERVERA
Storage Group name: SG1
Mailbox stores in SG1: MBX1, MBX2, MBX3

Suppose that the mailbox store MBX2 would not mount for some reason, and that you want to troubleshoot this problem. You check the database state, and it is "Clean Shutdown."

In this scenario, one of troubleshooting steps that you took is that you moved out the databases for MBX2. You moved both the .edb and .stm files, and then you mounted the blank store. The blank store could not mount successfully, but after you performed some more troubleshooting, you managed to mount the blank store.

Suppose the cause was a permissions issue in the Active Directory directory service. You then dismounted this blank store, removed its database files, brought in the original MBX2 database files, and then mounted MBX2 successfully.

Suppose that the problem is that the MBX2 database became corrupted three days after you moved out the databases for MBX2. Therefore, you go ahead and restore the MBX2 database from the backup that was done before your original troubleshooting. Now you are restoring only the MBX2 store. After the MBX2 store is restored, it replays through the log files on the hard disk.

The result is that MBX2 is restored without any errors, but it contains e-mail messages only from the time period when you mounted the blank store. The only e-mail messages that will be there are those that were delivered to the blank store while it was up.

CAUSE

In Exchange 2000 and in Exchange 2003, this problem occurs if you restore a particular store without deleting all the transaction logs first. When you mount a blank store, it records the createDB transaction in the transaction logs. Then when you restore the same store, it plays through the logs off of the backup in addition to the logs in the transaction log directory.

In this scenario, the restore does bring back all the old data, but as you play through the logs in the production transaction log directory, you eventually hit the createDB transaction. This causes you to unknowingly mount blank databases again. The createDB transaction is then completed with the rest of the logs. Therefore, you only have the mail from the time period after you mounted the blank database.

To summarize what occurs:
  1. Restore runs and is completed. The restored database is on the hard disk.
  2. Hard recovery starts. Logs are starting to replay in the database.
  3. The log that has the createDB transaction is also replayed. This creates the new database, as intended.
  4. Replay of any logs after that log is completed. That gives you only the mail that was received after the blank database was created.
The createDB transaction is just another transaction for your database engine. It is replayed the same as any other transaction.

Note This createDB transaction behavior did not occur in Microsoft Exchange 5.5 or in earlier versions of Exchange. It only occurs in Exchange 2000 and in Exchange 2003.

RESOLUTION

Solution if there is only one mailbox store and one public store



This problem is fairly easy to resolve if you are running Exchange 2000 or the Standard edition of Exchange 2003, or if you are running the Enterprise edition of either product that only has one public store and one mailbox store. You would just select the This database can be overwritten by a restore option so that the database can be overwritten by a restore in Exchange System Manager (ESM). This is the store that we are trying to restore that has been started with blank databases. In the scenario that is described earlier, this would be MBX2.

Restore the store in question. Make sure to click the Last backup set check box to select it. Then dismount all the stores, delete the transaction logs and the checkpoint file, and then try to mount the stores. The restore will complete, but when you try to mount the store, all the following events are logged in the application event log:

Event 1

Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery Event
ID: 494
Description: Information Store (1352) Database recovery failed with error -1216 because it encountered references to a database, 'C:\Program Files\Exchsrvr\mdbdata\mbx2.edb', which is no longer present. The database was not brought to a consistent state before it was removed (or possibly moved or renamed). The database engine will not permit recovery to complete for this instance until the missing database is re-instated. If the database is truly no longer available and no longer required, please contact PSS for further instructions regarding the steps required in order to allow recovery to proceed without this database.

Event 2

Event Type: Error
Event Source: ESE
Event Category: Logging/Recovery
Event ID: 454
Description: Information Store (1352) Database recovery/restore failed with unexpected error -1216.

Event 3

Event Type: Information
Event Source: ESE
Event Category: General
Event ID: 101
Description: Information Store (1352) The database engine stopped.

Event 4

Event Type: Error
Event Source: ESE BACKUP
Event Category: Callback
Event ID: 904
Description: Information Store (1352) Callback function call ErrESECBRestoreComplete ended with error 0xFFFFFB40.

Event 5

Event Type: Error
Event Source: ESE BACKUP
Event Category: Recovery
Event ID: 903
Description: Information Store (1352) Restore from directory c:\temp\First Storage Group ended with error (Error returned from a callback function call (0xFFFFFB40).

At this point, you can run the eseutil /r eXX /i command and then successfully mount the stores in ESM. "eXX" stands for the base log file name. For example, "e00" is the base log file name in the first storage group. After you run eseutil /r eXX /i, you should see all your old data, as expected.

Solution if there are multiple mailbox stores or public stores



The solution that is described earlier is valid, given its simpler environment. However, you may be running the Enterprise edition of Exchange 2000 or of Exchange 2003 to take advantage of the capability of having multiple stores in one storage group. If you want to apply the solution that is described earlier, you would have to dismount all the stores in the storage group just so that you could restore a single store. Again, this would have to be done only if one of the stores was started with blank database files since the last backup.

Important Typically, you can restore a single database store without having to dismount the other database stores in the storage group. However, in this particular case, you must dismount all the stores in the storage group before you restore the single store.

In this scenario, we recommend that you select the This database can be overwritten by a restore option so that the database can be overwritten by a restore in ESM. Then restore the store in question. Make sure to click the Last backup set check box to select it. Then dismount all the stores in the storage group, and then delete the transaction logs and the checkpoint file from their respective directories. Then run the eseutil /r eXX /i command, and then mount all the stores in ESM. All the stores should mount successfully, and the restored store should now contain all the old data.

Note This issue does not occur in Microsoft Exchange Server 2003 Service Pack 1 (SP1). In Exchange 2003 SP1, if the database .edb and .stm files are already there at the beginning of the recovery process with a different database signature because of an offline or online restore from a backup, the database files will not be deleted. The key to the new behavior is that the createDB process does not delete the old databases from the restore because they have a different database signature. For additional information, click the following article number to view the article in the Microsoft Knowledge Base:

836993 How to obtain the latest updates and service packs for Exchange Server 2003


MORE INFORMATION

For additional information, click the following article numbers to view the articles in the Microsoft Knowledge Base:

271987 Overview of Exchange Server database architecture and database engine

326052 White Paper - Disaster Recovery for Microsoft Exchange 2000 Server

For additional information about Exchange 2000 Server Database Recovery, visit the following Microsoft Web site:

Exchange 2000 Server Database Recovery

Modification Type:MinorLast Reviewed:7/12/2005
Keywords:kbprb kbinfo KB843092
©2004 Microsoft Corporation. All rights reserved.