Legal Information |
|
In Exchange, the generic term database refers to a single information store, either a mailbox store or a public folder store. The entire contents of an Exchange database is a combination of the database files on the hard disk and the recent changes made to that database that exist in a memory cache.
In this description, the phrase database files refers specifically to the files that exist on hard disk. These files may not contain the latest transactions (or changes) that were made to that mailbox store or public folder store. For disaster recovery processes, it is important to understand the distinction between database and database files. For example, if a server running Exchange experiences a loss of power, the database transactions that exist in memory are lost before they are written to the database files on the hard disk.
For this reason, all transactions are also recorded to log files. This is beneficial because, if transactions are lost, those transactions can be retrieved from the log files and restored to the database files on the hard disk. This automatic process is known as soft recovery.
Multiple mailbox stores and public folder stores replace the private information store and public information store used in previous versions of Exchange. Exchange 2000 mailbox stores and public folder stores are organised into storage groups. Each storage group corresponds to an instance of the Exchange 2000 Extensible Storage Engine (ESE). The ESE is a method that defines a very low application programming interface (API) to the underlying database structures in Exchange.
You can create a maximum of four storage groups per Exchange server. A storage group includes
There is also a difference in the files used to store Exchange data. In previous versions of Exchange, the private information store and public information store contained one file each (Priv.edb and Pub.edb, respectively). With Exchange 2000, each Exchange 2000 database is contained in two linked files - the .edb and the .stm.
The .edb file contains folders, tables, and indexes for messaging data and MAPI messages and attachments. The .stm file contains native Internet content. When performing backup and restore procedures, you must always treat these two files as one.
You can create multiple databases within a storage group to distribute user mailboxes across multiple databases. If you dismount one database for restoration purposes, the other databases in the storage group continue to remain online. E-mail services are not interrupted for users who have mailboxes on the databases that remain online.
Note All storage groups are managed by the Exchange Information Store service. The Exchange Information Store service mounts all non-damaged databases unless an individual database is unable to shut down cleanly. If a database cannot shut down cleanly, the other databases in the same storage group are prevented from shutting down cleanly as well because transactions are logged sequentially for all the databases in a storage group.
If you cannot perform a soft recovery against a database in a storage group, logs that are more recent than the time the database was cleanly shut down are prevented from being replayed into the other databases in the same storage group. This particular problem prevents the other databases in the same storage group from mounting until you can perform a soft recovery on the failed database. Furthermore, this problem occurs only if databases or log files become damaged or inaccessible. For administrative tasks or restoration processes, you can manually dismount a database at any time without affecting any of the other databases in the same storage group.
For information about how to mount databases before restoring a damaged database, see Microsoft Knowledge Base article Q264228, ôXADM: Storage Group Does Not Mount with -1216.öThe information in this article applies to:
Search Knowledge Base | Feedback |