Exchange Server 2007 features two types of continuous replication: local continuous replication (LCR) and cluster continuous replication (CCR). In this tip, Microsoft Exchange Server expert Brien Posey explains 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). Plus, learn the basic process that Exchange Server performs during database transactions.
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, but I think 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. 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.
About the author: Brien M. Posey, MCSE, is a five-time recipient of Microsoft's Most Valuable Professional award for his work with Exchange Server, Windows Server, Internet Information Services (IIS), and File Systems and Storage. Brien has served as CIO for a nationwide chain of hospitals and was once responsible for the Department of Information Management at Fort Knox. As a freelance technical writer, Brien has written for Microsoft, TechTarget, CNET, ZDNet, MSD2D, Relevant Technologies and other technology companies. You can visit Brien's personal website at www.brienposey.com.
Do you have comments on this tip? Let us know.
Please let others know how useful this tip was via the rating scale below. Do you know a helpful Exchange Server, Microsoft Outlook or SharePoint tip, timesaver or workaround? Email the editors to talk about writing for SearchExchange.com.
