So we've established that we're old enough to
remember the many iterations of Exchange Server prior to Exchange
Server 2010. We also remember an expression that goes something like,
"Explore the past and you will understand the present." We think this
expression is fitting for database management in Exchange Server. So,
let's turn on the Exchange Time Machine and explore the essence of mail
storage in Exchange Server.
1. Exchange Server 4.0, 5.0, and 5.5 (First Generation)
Back when a 28.8 modem was considered high-speed
Internet, Microsoft released the predecessors of what we now know as
Exchange Server 2010. The servers ran an earlier version of the
Extensible Storage Engine (ESE) data storage technology. A major
benefit of ESE at the time was that it provided Atomic, Consistent,
Isolated, Durable (ACID) transactions for Exchange, ensuring that
transactions are reliable and recoverable.
Three Exchange database (EDB) files were used to store all Exchange information:
Dir.edb, a file for the directory information
Pub.edb, a file for public folders
Priv.edb, a file for all user mailboxes.
The maximum database file size was 16 GB, and each
server could only hold one database for user mailboxes, thus limiting
each server storage to 16 GB (for the Standard Edition).
2. Exchange Server 2000 and 2003 (Second Generation)
ESE proved its stability and efficiency for dynamic
storage and graduated to become the data storage technology for Active
Directory, starting with Windows 2000 Server. In the world of Exchange,
the Exchange directory was replaced by Active Directory. Two database
files remained: one for user mailboxes and another for public folders.
Database file sizes were still capped at 16 GB for
the Standard Edition (though later increased to 75 GB thanks to an
Exchange Server 2003 service pack), but the game changed when
administrators were able to create multiple databases (up to 20 and
unlimited in Enterprise editions). Databases known as mailbox stores
were organized in container objects called storage groups. For each
database, in addition to the EDB file, Microsoft introduced the
streaming database (STM) file. Designed to store content in native MIME
format and reduce content conversion requirements, the STM file now
lived side by side with the EDB file.
3. Exchange Server 2007 (Third Generation)
So, the rumors of Exchange moving to a SQL-based
storage technology proved untrue. In fact, Microsoft pushed forward
with ESE and increased its investment, introducing database replication
technologies and essentially providing greater availability options to
administrators, now stressed out about their ever-growing databases.
Exchange Server 2007 introduced two major changes in
database management. First, the maximum number of available databases,
still organized in storage groups, was increased to 50. Second, finally
recognizing the need for large mailboxes, Microsoft removed all
database hard file size limits. There were many other changes, but a
notable one was the graceful removal of the STM file from Exchange,
ensuring that the EDB was once again riding solo, storing all content
in a single database file.
4. Exchange Server 2010 (Current Generation)
Exchange Server 2010 now introduces a version of ESE
that is reengineered to denote years of customer feedback, experience,
and the reality of larger user mailbox requirements. The changes in
Exchange Server 2010 are mostly the kind of changes that most
administrators would not notice when working with middle-of-the-range
servers or hardware. However, for administrators who manage Mailbox
servers with 500 or more mailboxes, the importance of the changes
becomes very real, very fast.
Online defragmentation running at runtime, new
database tables, a larger page size, and an aggressive compression
solution, to name just a few, are some of the architectural changes in
storage for Exchange 2010. Exchange Server 2010 promises to reduce IOPS
(input/output operations per second) requirements by up to 90 percent
(when compared to Exchange Server 2003). Since most organizations are
still running Exchange Server 2003, we're estimating that this change
can make many IOPS-hungry and fast disk–deprived administrators happy.
5. Basics in Storage Terminology
In this section, let's visit the basics of storage
terminology and why these terms should be relevant to you in a
discussion on storage.
5.1. Mailbox Database
For those of you who came from an Exchange Server
2003 background, this is what we called a mailbox store. In Exchange
Server 2010, the mailbox database is the configuration object that
provides management for all database settings. From the mailbox
database properties, an administrator can configure the location of the
database file, the transaction log file settings, and some settings
that apply to mailboxes stored in the mailbox database.
Each Exchange Server 2010 server that has the
Mailbox Server role installed has a mailbox database named Mailbox
Database <GUID> (The GUID suffix is there to ensure that the
database name is unique). This
database is created during the installation process and has an EDB file
named Mailbox Database.edb, stored in the default Mailbox
folder in the Exchange Installation directory. (The EDB file may also
be stored in an alternate location if you specified one during the
Exchange Server installation by using the /DBFilePath
parameter.) On an Exchange Server 2010 Standard Edition Mailbox Server,
an administrator can create up to five mailbox databases. On an
Exchange Server 2010 Enterprise Edition Mailbox server, an
administrator can create up to 100 mailbox databases (though most
administrators will likely not want
to create so many). Administrators often ask me why they should ever
need to create more than one Exchange database, especially since the
maximum mailbox database size is unlimited.
5.2. Transaction Logs
Transaction logging is one of those aspects of
Exchange that is obscure to most administrators. It is easy to forget
about transaction logging, since it all occurs automatically (or automagically).
For every transaction that enters your messaging server (new email,
deleted email, a change to an email message, a modified attachment...),
the information is written to a transaction log file. When transaction
log files are filled up with data, new transaction log files are
created in a perpetual fashion that bears resemblance to a factory
production line.
Transaction log files always have the same size,
1024 KB. We compare them to milk containers (whether empty or full,
they are always one gallon containers, or one liter containers for
those using the metric system). Transaction log files are created at
the 1024 KB size and then filled to capacity. These files will be
persistent on the hardware.
5.3. Storage Groups, RIP
Yes, they are finally gone. In your Exchange
administration tools, you will no longer find configuration options for
Storage Group objects. Microsoft has finally deprecated this object,
which seemed mostly inconsequential in Exchange Server 2007. Well, we
had to configure it, create it, and modify it, whenever a configuration
seemed to be placed in its tabs and pages. However, the recommendation
has long been to create only one mailbox database per storage group. So
why have the storage group at all? Well, Microsoft answered that
question and got rid of this object. All storage group configuration
settings (such as Circular Logging and Transaction Log Location) have
been moved to the Mailbox Database objects.
