Exchange Server 2007 replication and database transaction basics

[Balaji]

Introduction:
-----------------
Exchange Server 2007 features two types of continuous replication:

a) Local Continuous Replication (LCR) and

b) Cluster Continuous Replication (CCR)

In this the difference between these two replication methods and a
third type -- standby continuous replication (SCR) -- which was
introduced in Exchange Server Service Pack 1 (SP1) is also discussed
along with the basic process that Exchange Server performs during
database transactions.

Details:
-----------
The original RTM release of Exchange Server 2007 offered two different
types of continuous replication: local continuous replication and
cluster continuous replication. Local continuous replication provides
a degree of fault tolerance on a single mailbox server. The basic
premise is that LCR creates a secondary copy of an Exchange Server
database on a separate volume than the server. In contrast, CCR uses a
similar method to create a separate copy of the database and stores it
on a separate Exchange server.

When Microsoft released Service Pack 1 for Exchange Server 2007, it
introduced a third type of continuous replication known as standby
continuous replication (SCR). SCR is similar to CCR; however, CCR can
only create one replica of a protected database. SCR can create
multiple replicas of a database.

Even though Exchange Server 2007 provides three different types of
continuous replication, all three work in basically the same way.
Continuous replication is based on a technique called “log shipping”,
which involves copying each log file to the location where the backup
database is stored while the log file is built. The log file is then
replayed against the replica database, bringing the database into a
current state.

Microsoft classifies continuous replication as a storage group-level
operation, instead it's more accurate to classify it as a database-
level operation. Log files reside at the storage group level, but
continuous replication, in any form, limits the protected storage
group to a single database. Therefore, continuous replication could be
considered a database-level operation because it involves a single
database.


How Exchange Server database transactions work
---------------------------------------------------------------------------

The process that database transactions use is the same process used by
all mailbox servers, regardless of whether or not continuous
replication has been enabled. Database transactions are operations
that prompt a database update. These updates can include operations
like sending or receiving an email message, updating a calendar item
or creating a new task.
Any time a database transaction occurs, the database page that the
transaction is being performed against is read from the database file
and copied to an area of the server's memory known as the “ESE
cache” (Extensible Storage Engine cache). Any updates to the database
resulting from the current transaction are performed within the ESE
cache but are not written directly to the database.

Cached database pages that have been updated but not written to disk
are referred to as dirty pages. If additional transactions perform
operations against dirty pages, then the operation is performed within
the ESE cache. In such a case, Exchange uses a mechanism called the
version store to make sure the database remains in a consistent state.
Next, the transaction is recorded in a transaction log file. Depending
on the size of the transaction, this process may involve closing the
current log file and starting another one. Because the log file is
only 1 MB, Exchange may consider the excessively large transactions as
multiple log files. Each time a log file reaches the 1 MB limit, it is
closed and a new log file starts.

When a backup is running against an Exchange server, the contents of
the log files are written to the database. At this point, the
checkpoint file is advanced so that it references the oldest log file
that has not yet been committed to the database.