Best Practice #1: Understanding Exchange databases
The
Extensible Storage Engine (ESE) and its associated files are probably the least understood components of Exchange for many administrators. This can unfortunately lead to a number of misconceptions and bad backup and restore practices.
Here are a few basic database concepts all administrators should understand before creating a disaster recovery plan:
- Database: In Exchange 2000/2003, the database is comprised of two files -- an .edb (rich text data) and .stm (native content) files. Databases can be either mailbox stores or public folder stores.
- Transaction logs: Before data is written to the database, it is first written to a sequential
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by Exchange professionals today working with Exchange, Outlook and other related technologies.
Margie Semilof, Editorial Director
Premium Access
Register now for unlimited access to our premium content across our network of over 70 information Technology web sites.
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States.
Privacy
Dig Deeper
-
People who read this also read...
- set of transaction logs. These logs are not only essential to the performance of Exchange, but they are also a key ingredient in an Exchange disaster recovery plan.
- Consistent database: When a database is dismounted, or the information store service (store.exe) is shut down, all logs are committed to the database. After all logs have been committed, the header information in the database is flagged as "consistent."
- Inconsistent database: When a database is stopped prior to all transactions being committed (because of a power outage, for example), the header of the database is not flagged and is therefore regarded as "inconsistent." To make the database consistent, the transactions that were not committed must be replayed into the database. A database must be consistent in order for it to be mounted.
Best Practices Checklist: Exchange Server disaster recovery planning
Home: Introduction
Best Practice #1: Understanding Exchange databases
Best Practice #2: Building your plan around the technology at hand
Best Practice #3: Keeping e-mail in perspective
Best Practice #4: Configuring server hardware for disaster recovery
Best Practice #5: Configuring Exchange for disaster recovery
Best Practice #6: Simulating a disaster
Best Practice #7: Learning from others' mistakes and successes
Best Practice #8: Considering offsite storage and remote recovery
Best Practice #9: Familiarizing yourself with the right resources
| ABOUT THE AUTHOR: |
|
Richard Luckett, Vice President and Senior Consultant, Ajettix Security
Richard Luckett is a Microsoft Certified Systems Engineer on the Windows NT 4.0, 2000 and 2003 platforms and has been certified on Exchange since version 4.0. He is the co-author of Administering Exchange 2000 Server, published by McGraw Hill, and has written four Exchange courses, Introduction to Exchange 2000, and Hands-on Exchange 2003, Ultimate Exchange Server 2003 and Exchange Server 2003 Administrator Boot Camp for Global Knowledge Inc. Richard is currently Vice President and Senior Consultant for Ajettix Security, where he is the head of the Microsoft security practice.
|
|
