Tài liệu Module 4: Creating and Managing Storage Groups and Stores docx

Contents
Overview 1
Introduction to Storage Groups and Stores 2
ESE Features in Exchange 2000 7
Creating and Managing Storage Groups
and Stores 23
Database Considerations 30
Introduction to Indexing 36
Lab A: Creating Storage Groups and
Multiple Exchange 2000 Databases 46
Lab B: Building a Full-Text Index 54
Review 60

Module 4: Creating and
Managing Storage
Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Information in this document is subject to change without notice. The names of companies,
products, people, characters, and/or data mentioned herein are fictitious and are in no way intended
to represent any real individual, company, product, or event, unless otherwise noted. Complying
with all applicable copyright laws is the responsibility of the user. No part of this document may
be reproduced or transmitted in any form or by any means, electronic or mechanical, for any
purpose, without the express written permission of Microsoft Corporation. If, however, your only
means of access is electronic, permission to print one copy is hereby granted.

Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual
property rights covering subject matter in this document. Except as expressly provided in any
written license agreement from Microsoft, the furnishing of this document does not give you any
license to these patents, trademarks, copyrights, or other intellectual property.

 2000 Microsoft Corporation. All rights reserved.

Microsoft, Active Directory, BackOffice, Jscript, NetMeeting, Outlook, Windows, and Windows
NT, are either registered trademarks or trademarks of Microsoft Corporation in the U.S.A. and/or
other countries.

Other product and company names mentioned herein may be the trademarks of their respective
owners.

Program Manager: Steve Thues
Product Manager: Megan Camp
Instructional Designers: Bill Higgins (Volt Technical), Jennifer Morrison, Priya Santhanam
(NIIT (USA) Inc), Samantha Smith, Alan Smithee
Instructional Software Design Engineers: Scott Serna
Subject Matter Experts: Krista Anders, Megan Camp, Chris Gould (Global Logic Ltd),
Janice Howd, Elizabeth Molony, Steve Schwartz (Implement.Com), Bill Wade (Wadeware LLC)
Technical Contributors: Karim Batthish, Paul Bowden, Kevin Kaufman, Barry Steinglass,
Jeff Wilkes
Graphic Artist: Kimberly Jackson (Independent Contractor)
Editing Manager: Lynette Skinner
Editor: Kelly Baker
Production Manager: Miracle Davis
Build Manager: Julie Challenger
Production Support: Marlene Lambert (Online Training Solutions, Inc)
Test Manager: Eric Myers

Courseware Testing: Robertson Lee (Volt)
Creative Director, Media/Sim Services: David Mahlmann
Web Development Lead: Lisa Pease
CD Build Specialist: Julie Challenger
Localization Manager: Rick Terek
Operations Coordinator: John Williams
Manufacturing Support: Laura King; Kathy Hershey
Lead Product Manager, Release Management: Bo Galford
Lead Product Manager, Messaging: Dave Phillips
Group Manager, Courseware Infrastructure: David Bramble
Group Product Manager, Content Development: Dean Murray
General Manager: Robert Stewart

Module 4: Creating and Managing Storage Groups and Stores iii

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Instructor Notes
This module provides students with an overview of the storage capability in
Microsoft
®
Exchange 2000 through the use of storage groups and stores.
Students will learn how to create and manage storage groups and stores, as well
as the various file types involved, and how data is written to databases.
After completing this module, students will be able to:
!
Explain the benefits of using multiple storage groups and stores, and
demonstrate how to mount and dismount stores.
!
Describe the Extensible Storage Engine (ESE) features in Exchange 2000

that allow you to manipulate data.
!
Create and configure storage groups and stores to fit various business needs.
!
Explain how to plan multiple stores and storage groups, and identify ways to
improve the reliability of the restoration process.
!
Describe the benefits of full-text indexing and identify the tools you can use
to troubleshoot indexing.

Materials and Preparation
This section provides the materials and preparation tasks that you need to teach
this module.
Required Materials
To teach this module, you need the following:
!
Microsoft PowerPoint
®
file 1572A_04.ppt

Preparation Tasks
To prepare for this module, you should:
!
Read all of the materials for this module.
!
Complete the labs.
!
Practice delivering the class with the PowerPoint slides, taking special note
of the animation slides.
!

Practice the demonstrations.

Presentation:
120 Minutes

Lab:
60 Minutes
iv Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Module Strategy
Use the following strategy to present this module:
!
Introduction to Storage Groups and Stores
In this section, you will help the students gain an understanding of the
purpose of storage groups and stores. Showing students how to mount and
dismount a store will help them to learn this process.
!
ESE Features in Exchange 2000
In this section, you will help students to understand where files are stored
and the various file extensions that ESE uses. Make sure students
understand how to use log files and circular logging.
!
Creating and Managing Storage Groups and Stores
The focus of this section is to present a more in-depth discussion of what
storage groups and stores are and how best to manage them. Your
explanation of how storage groups and stores can be configured to match
the requirements of the users accessing them, as well as the need for
security, will help students to determine how best to manage their own

storage groups and stores. The discussion of how to move transaction log
files and database files will enable students to place them where it is most
appropriate.
!
Database Considerations
In this section, you will lead a discussion of how various clients send
messages to Exchange 2000 and how that information is written to the
database. Your presentation of how to plan multiple storage groups and
stores will assist students in using this feature more efficiently. The points
that you present to students on how they can improve the reliability of their
backup process will add to their capability in this area.
!
Introduction to Indexing
In this section, discuss the advantages of full-text indexing and the search
architecture that provides the functionality. In addition, you will lead
students in a discussion of the process for creating and changing the
properties of an index, and how to use the various tools available for
troubleshooting.
Module 4: Creating and Managing Storage Groups and Stores v

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Customization Information
This section identifies the lab setup requirements for a module and the
configuration changes that occur on student computers during the labs. This
information is provided to assist you in replicating or customizing Microsoft
Official Curriculum (MOC) courseware.

The labs in this module are also dependent on the classroom
configuration that is specified in the Customization Information section at the

end of the Classroom Setup Guide for course 1572A, Implementing and
Managing Microsoft Exchange 2000.

Lab Setup
The following list describes the setup requirements for the labs in this module.
Setup Requirement 1
The labs in this module require Exchange 2000 and a custom MMC. To prepare
student computers to meet this requirement, perform one of the following
actions:
!
Complete the labs for Module 2, “Installing Microsoft Exchange 2000,” in
course 1572A, Implementing and Managing Microsoft Exchange 2000.
!
Install Exchange 2000 at D:\Program Files\Exchsrvr on each server into an
organization named Northwind Traders. Components installed are Microsoft
Exchange Messaging and Collaboration Services, Microsoft Exchange
System Management Tools, and Microsoft Exchange Instant Messaging
Service. Have the students create a custom MMC in the C:\Documents and
Settings\All Users\Desktop that is saved as your_firstname Console. The
MMC contains the Active Directory Users and Computers snap-in and the
Exchange System snap-in.

Setup Requirement 2
The labs in this module require a custom OU, a user account for each student, a
mailbox for each student, an Outlook profile, an account named
Jonyour_servername, and for the Domain Admins group to be delegated full
control of the organization. To prepare student computers to meet this
requirement, perform one of the following actions::
!
Complete the labs for Module 3, “Administering Microsoft Exchange

2000,” in course 1572A, Implementing and Managing Microsoft Exchange
2000.
!
Create an organizational unit in Active Directory that is named
your_servernameOU for each server in the classroom. Create a user account
in each server’s OU for each student. The account is a member of the
Domain Admins group and has a mailbox on the student’s Exchange server.
Create an Outlook profile for each student on their own server that opens
their mailbox. Delegate the full administrator role on the Northwind Traders
organization. Create an account named your_servername with a mailbox in
the default mailbox store of each server in the classroom.

Important
vi Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Lab Results
Performing the labs in this module introduces the following configuration
changes:
!
A storage group named Executive Storage Group is created.
!
A mailbox store named your_servername Executive Mailbox Store is
created.
!
Full-text indexing is enabled on the default mailbox store of each server in
the classroom.

Module 4: Creating and Managing Storage Groups and Stores 1

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview
!
Introduction to Storage Groups and Stores
!
ESE Features in Exchange 2000
!
Creating and Managing Storage Groups and Stores
!
Database Considerations
!
Introduction to Indexing


Storage groups and stores in Microsoft
®
Exchange 2000 provide the containers
in which you store data. You have great flexibility in configuring these
containers to fit your environment and to efficiently handle data.
At the end of this module, you will be able to:
!
Explain the benefits of having multiple storage groups and stores, and
demonstrate how to mount and dismount stores.
!
Describe the Extensible Storage Engine (ESE) features in Exchange 2000
that allow you to manipulate data.
!
Create and configure storage groups and stores to fit your various business

needs.
!
Explain how to plan multiple stores and storage groups, and identify how to
improve the reliability of the restoration process.
!
Describe the benefits of full-text indexing and identify the tools you can use
to troubleshoot indexing.

Topic Objective
To provide an overview of
the module topics and
objectives.
Lead-in
In this module we are going
to define storage, discuss
how it works, and identify
the tasks you will perform as
an administrator.
2 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##
#

Introduction to Storage Groups and Stores
!
Overview of Stores
!

Overview of Storage Groups


Exchange 2000 supports multiple message databases on each server. Creating
multiple databases enables greater scalability, efficient management, increased
reliability and a reduction of backup and restore times.
Topic Objective
To provide an introduction to
the concepts of storage
groups and stores.
Lead-in
A message database is
used to store messages on
a server.
Module 4: Creating and Managing Storage Groups and Stores 3

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview of Stores
Exchange 2000
.stm .edb
Store


A store is a database that houses data. Exchange 2000 can support multiple
stores on each server. Stores have no programmed size limit, so you can use
multiple stores to enhance the flexibility of backup and restore tasks.
There are two types of stores in Exchange 2000, mailbox stores and public
information stores. A mailbox store contains user data and a public store
contains public folder (or shared) data. Each store is a logical database that has

an associated streaming store file containing native Internet content. Each store
consists of the following database files:
!
The streaming database file (.stm).
The .stm file contains common Internet formatted content, such as native
Multipurpose Internet Mail Extensions (MIME) content, that protocols other
than the Messaging Application Programming Interface (MAPI) protocol
places in the store.
!
The rich text database file (.edb).
The .edb file contains data placed in the store through MAPI, as well as the
database tables that define mailboxes, messages, folders and attachments.

Because the .stm file only contains raw document content, which is referenced
by the corresponding edb file, the streaming database and rich text database
files that comprise a particular database are inseparable.
Topic Objective
To define stores and explain
how to mount and dismount
stores.
Lead-in
A store is a database that
houses data.
4 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Benefits of Multiple Message Databases
The benefits of multiple message databases include:
!

Increased system reliability because a failure in one database does not affect
users in another database.
!
Faster and more flexible backup scheduling is possible because databases
are typically smaller.
!
Decreased recovery time in the event of hardware failure because each
database can be restored individually.


Exchange 2000 Enterprise Server supports multiple mailbox and public
information stores per server while Exchange 2000 Server supports only one
mailbox store per server, but multiple public information stores. The mailbox
store on Exchange 2000 Server is limited to 16 gigabytes (GB) in size.

Mounting and Dismounting Stores
When the information store service is running, stores can be individually
mounted and dismounted.
You can choose the Mount Store or Dismount Store commands to bring the
store online or take it offline. This is a toggle option that only displays the
available action. For example, if the selected store is currently mounted, the
Dismount Store command appears. The store must be mounted before the
client can access it. You must also dismount a store before moving its
transaction log files and database files, or before restoring it from backup.

Users are not automatically warned that the server is dismounting a
store. You will see a warning stating that dismounting the database will
disconnect all users when you select this option. Use the mailbox subcontainer
in the Exchange System Manager to see what users have mailboxes in the store.

Note
Delivery Tip
Ask students to describe the
consequences of
dismounting a store while
users are connected.
Warning
Module 4: Creating and Managing Storage Groups and Stores 5

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Overview of Storage Groups
Exchange 2000
Store
Store
Storage Group A
Transaction Log
Store
Store
Store
Store
Store
Store
Store
Store


A storage group is a set of stores that share the same set of transaction log files.
A storage group contains up to five stores that use one set of transaction log
files. Exchange 2000 uses storage groups to reduce the overhead of multiple

sets of transaction log files. You can manage these stores as a group or
independently.
Benefits of Storage Groups
Storage groups enable you to:
!
Support more users on each server because multiple smaller stores can be
created and managed more easily.
!
Perform backup and restore activities on a single store while other stores in
the storage group remain in operation.
!
Host multiple businesses on a single server. Each company can have its own
store or storage group. You can configure and maintain each storage group
according to the requirements of the associated company.
!
Provide individual support for critical mailboxes. For example, you may
have one or more critical mailboxes that must be recovered individually as
quickly as possible in the event of an emergency or disaster. You can
configure each mailbox in its own dedicated store, enabling you to perform
individual backup and recovery. The more stores and storage groups you
create, the more Exchange 2000 resources are required. For this reason, it is
important to weigh the impact on resources against the business need for
creating additional stores and storage groups.
!
Use circular logging for a specific storage group. Circular logging enables
Exchange 2000 to use and reuse a small set of transaction log files. For
example, you may have a store that generates a volume of transactions that
do not need to be recovered, such as a public information store that receives
a newsfeed. If you place this store in its own storage group it can use
circular logging. You should disable circular logging for the other storage

group(s) in this instance.
Topic Objective
To explain the benefits of
storage groups, the types of
stores, and the number
allowed on a single server.
Lead-in
A storage group is a set of
databases, called stores,
which share the same set of
transaction log files.
6 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Storage Group Limits
You can create up to four storage groups for each Exchange 2000 server.
Exchange 2000 creates an additional temporary storage group during restore
operations. Each storage group can support five stores. Stores do not have a size
limit, although administrators should limit their size so that they can easily
backup or restore the stores.
Transaction Log Files
Transaction log files are history files recording server activity. These files are
useful in restoring and backing up Exchange 2000 data. All Exchange 2000
transaction logs are 5 megabytes (MB) in size.
Each storage group uses its own set of transaction log files. For example, if a
storage group contains five stores, all transactions for all five stores are
recorded in a single series of transaction log files. You can determine where to
locate the transaction log files for each storage group.
Transaction log files are the most important files for recovery because they

reflect all the transactions that have taken place up to the point of a system
failure. ESE even saves those transactions that have not yet been written to the
database file. To increase performance and reliability, place the log files on
separate hard disk spindles for each storage group. Make sure that these log
files are on separate hard disk spindles from the database files for the stores in
the storage group.
Each storage group contains one current transaction log file. This file is always
named Exx.log. The First Storage Group files are located in the C:\Program
Files\Exchsrvr\Mdbdata folder. The second storage group files are located in
the C:|\Program Files\Exchsrvr\Second_storage_group_name folder.
For Your Information
The administrator has
control over the location of
the transaction log and ESE
database files through
Exchange System Manager.
Module 4: Creating and Managing Storage Groups and Stores 7

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

#
##
# ESE Features in Exchange 2000
!
ACID Transactions
!
Storing Data
!
File Generation
!

Previous Log Files
!
Checkpoint Files
!
Reserved Log Files
!
File Location
!
Circular Logging


ESE enables storage groups and stores to function. ESE manages the Exchange
2000 database. There are three basic aspects of database management: storing
data; adding, deleting or changing data; and recovering data in the case of a
system failure.
ESE is also used with the Active Directory
®
directory service and other
software clients, such as the Key Management Server, that need to store and
retrieve data quickly. ESE is a dynamic-link library (DLL) that is included
within each application or component that uses its features.
The main function of ESE is to handle transactions. A transaction is a series of
modifications to a database that leaves the database in a consistent state. These
modifications are called operations. An operation is the smallest change that
can be made to a database. Operations include such activities as insert, delete,
replace, or commit. Several operations make up a single transaction. A single
operation may leave the database in an inconsistent state.
Topic Objective
To provide an introduction to
ESE features in Exchange

2000.
Lead-in
The Extensible Storage
Engine (ESE) is the
technology behind
Exchange 2000 storage and
Active Directory.
8 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

ACID Transactions
!
Atomic
!
Consistent
!
Isolated
!
Durable


ESE supports full Atomic, Consistent, Isolated, and Durable (ACID)
transactions. The acronym ACID is defined as follows:
!
Atomic. Operations performed in a transaction are either all completed or
none of them are completed.
!
Consistent. A transaction takes a database from one consistent state to
another.

!
Isolated. Changes are not visible until all operations within the transaction
are completed. When all operations are complete, the transaction is
considered committed.
!
Durable. Committed transactions are preserved even if the system crashes.

An example of an ACID transaction would be as follows: You move a mail
message from the Inbox folder to another folder named Important. This is a
single transaction. To complete this transaction, Exchange 2000 must perform
the following operations:
1. Delete the mail message from the Inbox folder.
2. Insert the mail message into the Important folder.
3. Update the information about each folder to correctly reflect the number of
items in each folder and the number of unread items.
4. Commit the transaction.

Topic Objective
To describe ACID
transactions.
Lead-in
ESE supports full Atomic,
Consistent, Isolated, and
Durable transactions.
Module 4: Creating and Managing Storage Groups and Stores 9

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Because these operations are accomplished within a single transaction,
Exchange 2000 will perform all of these operations or none at all. The commit

operation is not recorded until all operations have been carried out.
If the system fails, ESE will reverse operations that were not part of a
committed transaction. This means, using the previous example, that if the mail
message is deleted first, then the system fails and the operation is rolled back
(reversed) when the database restarts. The consequence of this action is that a
mail message would never be lost while moving it, nor would Exchange 2000
end up with two copies of a mail message that was moved.
10 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Storing Data
DatabaseCurrent Transaction Log
.edb .stm
.log
Memory


The data in an ESE database is stored in three different locations: database,
memory, and transaction log files.
Database
Stores consist of two database files: .stm and .edb files. The .stm file is the
streaming database file. This holds all data in native MIME, audio, video, and
so on The .edb file is the rich text database file. This holds all the data in
Messaging Application Programming Interface (MAPI) format. These files are
used in pairs to make Exchange 2000 more efficient.
Memory
When a modification is made to the database, the page to be changed is copied
into memory. Changes are made in memory, which increases the performance
of ESE. However, this also means that current pages of the database are now

stored in memory, and the same pages in the database file are out of date.
Although this use of memory processes transactions more quickly, the database
becomes more vulnerable were a system failure to occur. For example, if you
lose power to the server, all data in memory is lost, including all changes to the
database that were not copied to the database file. ESE recovers the changes by
recording the operations that are performed in memory to transaction log files
on the hard disk.
Current Transaction Log
A database file is often several GBs in size, and writing changes to the database
file requires finding each page that needs modification. It is much faster to
append a transaction to the end of a transaction log file than to write it into the
database file. ESE uses transaction log files to save a record of individual
database operations on the hard disk, as they occur. The change made to the
page is written sequentially into the transaction log file immediately after the
change is made in memory. When all the operations of a transaction are written
to the transaction log files, the integrity of the data is secure.
Topic Objective
To describe the location of
data stored in an ESE
database.
Lead-in
Each ESE database file is
logically organized in 4-KB
pages.
Delivery Tip
Stress that when referring to
the database it has two
components, .stm and .edb
files.
Delivery Tip

Ask students to describe
system exposure when
changes are made to
information in the database
using Exchange 2000.
Module 4: Creating and Managing Storage Groups and Stores 11

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Log Sequence Numbers (dbTime)
Each database page has a Log Sequence Number, called dbTime, which gives
the relative time the page was last changed. This is not a time stamp, but a
counter that increases by one every time a change is made. By performing this
operation, ESE can track if the page in memory is more current than the page in
the database file.
Dynamic Buffer Allocation
With dynamic buffer allocation, ESE can use as much memory as the server has
available, and therefore requests can be processed quickly.
ESE dynamically grows or shrinks the buffer cache depending on how much
memory is available and whether there are memory requirements from other
non-ESE services, such as Internet Information Services (IIS), running on the
same computer. If memory is not being used by other services on the server,
then ESE takes as much memory as it needs. When other services need memory
ESE will give up some memory by copying pages to the database file and
shrinking the size of its buffer.
For Your Information
Allocating buffers was
manually performed by
using the Performance
Wizard in Exchange Server

5.5, but is performed
automatically in Exchange
2000.
12 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

File Generation
!
.stm –Streaming Database File
!
.edb – Rich Text Database File
!
.log – Transaction Log File
!
.chk – Checkpoint File


ESE generates several different files, with different extensions for different
purposes, as it is storing data.The following table outlines the types of files that
ESE generates.
File type Function

Current Streaming
Database (.stm)
The streaming store, or native store, contains common
Internet formatted content, including native MIME
content, voice, video, and so on. There are mailbox stores
and public stores.
Current Rich Text

Database (.edb)
The rich text store contains MAPI formatted content. A
common MAPI client is Microsoft Outlook
®
2000. This
allows a rich message property set, such as text
formatting and color. There are mailbox stores and
public stores.
Current transaction log file
(Exx.log, for example
E00.log)
The current transaction log file secures transactions
before they are written from memory to an ESE database
file. There is only one current transaction log per storage
group recording transactions for multiple databases.
Previous transaction log
files (Exxnnnnn.log, for
example E0000001.log)
The previous transaction log files maintain older
transactions. These transactions may or may not have
been written from memory to the database file.
Checkpoint file (Exx.chk,
for example E00.chk)
The checkpoint file contains a pointer that specifies
which transaction log file contains the last transaction
that was committed to the database file. A recovery
should begin with this file. Transactions older than the
checkpoint file pointer are guaranteed to be in the
database, while transactions newer than the checkpoint
may or may not have been committed to the database.

Reserved transaction log
files (Res1.log and
Res2.log)
The reserved transaction log file reserves log file space in
case an out-of-disk-space situation arises. There are two
log files reserved.
Topic Objective
To identify file extensions,
and the purpose of each
type of file, for ESE
generated database files.
Lead-in
ESE generates several files
as it is storing data.
Module 4: Creating and Managing Storage Groups and Stores 13

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

(continued)

File type Function

Temp files (tmp.edb) Temp files are used during upgrades as well as for
transient storage during information store maintenance,
creating indexes, and sorting data. The Tmp.edb file is
not backed up and is automatically deleted when the store
process shuts down gracefully. There is no need to back
up this file.
Patch files Patch files are temporary log files that store special
transactions during an online backup.

14 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Previous Log Files
Previous Logs
Previous Logs
Current Log
Current Log
E0000001.LOG
E0000002.LOG
.
.
.
Current Logs Are Renamed After 5 MB of Data Is Accepted
E0000003.LOG
Renamed
Renamed
Renamed
3 MB5 MB
New
E00.log
(5 MB)


In Exchange 2000, each transaction log file can contain up to 5 MB of data.
When the current transaction log file becomes filled (after every 5 MB of
transactions are written), it is renamed to indicate that it is a previous log file,
and a new log file is created with the Exx.log file name. The Exx.log file and

renamed log files are stored in the same subdirectory.
Log File Size
Exchange 2000 log files are always 5 MB in size. Microsoft Explorer reports
the transaction log files as exactly 5,242,880 bytes.

If your transaction log files do not reflect this exact size, they are
most likely damaged.

Generation Numbers
To keep track of the transaction log files, ESE assigns each log file a generation
number. For example, when Exchange 2000 starts for the first time, with the
First Storage Group, it creates a transaction log file named E00.log with a
generation number of 1. When that log file is full and Exchange 2000 rolls over
to a new log file, the new transaction log file becomes E00.log with a
generation number of 2, and the old E00.log file is renamed to E0000001.log.
The five digits in previous log file names are hexadecimal numbers, while the
generation number inside a log file is a decimal number. The generation number
in the current transaction log file tells ESE how to rename this log file when it
is full.
When a store is created in a new storage group, a new set of transaction logs is
generated. (There is one set of transaction logs per storage group.) The current
transaction log in the second storage group is called E01.log. This follows the
same process described above, and the old E01.log file is renamed to
E0100001.log.
Topic Objective
To describe the disposition
of previous log files.
Lead-in
When the transaction log file
is full, a new log file is

created and the current log
file becomes a previous log
file.
Delivery Tip
The animation starts with a
partially full Exx.log file. The
animation shows the Exx.log
file filling up, being renamed
to E000003.log, and then a
new Exx.log file being
created.
Important
For Your Information
Active Directory ESE log
files in Microsoft Windows
®

2000 are 10 MB in size.
Files include:
edb.log
edb0000x.log
res1.log
res2.log
Module 4: Creating and Managing Storage Groups and Stores 15

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Log File Signature
If you were to shut down the server and delete all the transaction log files, ESE
would create a new series of transaction log files starting with a generation

number of 1 when you restart the database service. Because log files can have
the same name, ESE stamps the header in each file in the series with a unique
signature so it can distinguish between different series of log files.
Previous Log Files
You should never delete previous transaction log files manually, unless
recovery from possible data loss is not important. By maintaining the old data
in transaction logs, the server could, if needed, use an older copy of the
database and apply transaction logs to that database to bring it up-to-date.
16 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Checkpoint Files
E0000001.log
E00.chk
Transaction Log
Entries Written
to the Database
Transaction Log
Entries Not Yet
Written to the
Database


The checkpoint is a pointer within the Exx.chk file that indicates the last
transaction that was completely written to the database file. When all the pages
that were changed by operations in a given transaction are written to the
database file, the checkpoint is advanced to the transaction with the next
unwritten entry. Separate Exx.chk files are maintained for each storage group
using ESE. For example, the First Storage Group would have a check file of

E00.chk. The second storage group would have a check file of E01.chk.

If you are using circular logging, you do not want to get rid of the
checkpoint file. The checkpoint allows for implementing circular logging.
Circular logging deletes log files older than the checkpoint; these are log files
that are not needed for recovery to complete.

The following process describes the steps the system follows to recover data
with the checkpoint file:
1. ESE reads the Exx.chk file when Exchange 2000 starts up.
2. ESE opens the transaction log file referenced by the checkpoint.
3. All committed transactions are written to the database file.
4. Transactions not ending in a commit operation in the transaction log file
(which would occur in the case of a system failure) are discarded.
5. In a normal shutdown, the current transaction log file is Exx.log, and all
transactions are written to the database file.

Topic Objective
To explain the function of
the checkpoint file.
Lead-in
The checkpoint file tracks
the location of the last
committed transaction that
has been fully copied to the
database file.
Delivery Tip
Use the illustration to point
out that some transactions
past the checkpoint have

been written to the database
file, while others have not.
Make it clear to students
that the checkpoint only
designates that everything
before it has definitely been
written to the database. It
does not imply that no
transactions after the
checkpoint have been
written, only that not all have
been.
Warning
Module 4: Creating and Managing Storage Groups and Stores 17

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

If the checkpoint file does not exist, the database service starts from the
beginning of the oldest transaction log file it finds on disk and checks every
operation in every log file to determine whether it was written to the database.

The Exx.chk file is not required to replay transactions. ESE determines
which transactions have already been written by reading the transaction log files
directly and looking at the dbTime value of each operation. When you use a
checkpoint you save ESE from starting at the first transaction log file and
checking every operation.

Note
18 Module 4: Creating and Managing Storage Groups and Stores

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

Reserved Log Files
1
1
1
3
3
3
Event Log
Writes
Writes
Writes
4
4
4
Microsoft Exchange
Services
Microsoft Exchange
Services
Shut Down
Shut Down
Shut Down
res2.log
5 MB
res1.log
5 MB
Memory
Writes
Writes

Writes
2
2
2
Out of
Disk Space


If the current transaction log contains 5 MB of data, ESE will rename the file
and create a new transaction log. If the server is running low on hard disk space,
and 5 MB is not available, a new current transaction log cannot be created.
In the event that the server runs out of disk space, each storage group reserves
two log files, Res1.log and Res2.log, which are stored in the transaction log file
folder. These files hold no data, but reserve 5MB of hard disk space each. ESE
uses reserved log files when attempting to create a new Exx.log file and there is
not enough disk space. In this situation, the following occurs:
1. ESE sends an error message to the respective database service.
2. ESE writes any operations in memory to a reserved transaction log, starting
with Res2.log. This may include several transactions that are on their way to
the server, depending on how busy Exchange 2000 is.
3. The database service records the event in Event Log in Windows 2000.
4. The database service shuts down.


Reserved transaction log files are 5 MB in size, as are all transaction log
files.

Once the out-of-disk-space error occurs, you cannot make any additions to the
database because there is no hard disk space. ESE will record any transactions
in process, roll back all existing uncommitted transactions, and record the

uncommitted transactions in the transaction log file before the system can shut
down the database safely. When transactions in memory have been committed,
ESE will rename the file last used, either Res1.log or Res2.log, to Exx.log.
The amount of information contained in the reserved log files can be up to 5
MB each. If there is more than 10 MB of information to be written to the
reserved log files, including rollback operations and new operations, ESE will
terminate and an error will result.
Topic Objective
To explain the function of
reserved log files.
Lead-in
There are two transaction
log files that are created at
the initialization of an ESE
database to provide
resources in low disk space
situations.
For Your Information
Point out that the system
warning for out of disk
space occurs long before
the actual available storage
space reaches zero.
Note
Module 4: Creating and Managing Storage Groups and Stores 19

BETA MATERIALS FOR MICROSOFT CERTIFIED TRAINER PREPARATION PURPOSES ONLY

File Location
System Partition and

Boot Partition
System Partition and
Boot Partition
Mirror Set
C:\
Storage Group 1
Transaction Logs
Storage Group 1
Transaction Logs
Mirror Set
E:\
Storage Group 2
Transaction Logs
Storage Group 2
Transaction Logs
Mirror Set
F:\
Page File
Page File
D:\
All Database Files For
Both Storage Groups
All Database Files For
Both Storage Groups
Stripe Set with Parity
G:\


When the server running Exchange 2000 has only one hard disk, the log files
are typically kept in the storage group directory along with the database files.

You receive the benefits of enhanced system performance and data
recoverability by storing log files on a separate disk from the database files.
Choosing a Separate Disk
The speed of the Exchange 2000 database depends greatly on how quickly
operations are copied from memory to the transaction log.
Log files are written sequentially and are optimised for disk writes and
minimum disk head movement. For this reason, you should configure the
transaction logs to be on a separate, high performance disk that does not have
other input/output (I/O) operations occurring. For example, you should not store
the checkpoint file on the same disk as the transaction log files. Likewise, you
should not store a swap file on this disk either. During normal operation, ESE
does not read from log files, so the faster ESE can write to the transaction log
file disk the better the server performance. The best performance is normally
obtained with a hardware mirror array.
Topic Objective
To describe the file location
options for Exchange 2000
transaction log and
database files.
Lead-in
Transaction log files should
be stored separately from
the database files and
should be stored on high
performance disks.
Delivery Tip
Ask students to:
1. Describe the importance
of storing transaction logs
on a separate disk.

2. Share any experiences of
the consequence of not
storing transaction logs on a
separate disk.