7.2 Exchange ACID

 < Day Day Up > 



Microsoft designed the Store to meet the ACID (Atomicity, Consistency, Isolation, and Durability) test for database transaction integrity. Transactions are only applied if they are compete and intact. Microsoft makes great efforts to ensure consistency throughout the Store; transactions are isolated from each other, and there are many features implemented in the Store to make it a reliable and robust repository.

A transaction is a series of modifications to a database that leaves the database in a consistent state. These modifications are called operations. Sending a new message requires several operations that form the single logical transaction we consider when we think of someone sending a message and Exchange delivering it to recipient mailboxes.

An operation is the smallest change made to an ESE database. Operations include insert, delete, replace, and commit. A database is left in an inconsistent state if not all of the operations that make up a transaction are committed. For example, if a server experiences a sudden failure during normal operation, it is quite likely that a number of transactions are outstanding and have not yet been completely committed to the database. Exchange can return its databases to a consistent state by processing the contents of the transaction log files. When the Store makes the database consistent, ESE may ignore some transactions because the Store was not able to complete all of the operations necessary to finalize some transactions when the system crash occurred.

ACID transactions mean that ESE must fulfill the following requirements, as described in Transaction Processing: Concepts and Techniques (by Gray and Reuter, 1983):

  • Atomic: An atomic transaction is one where all its operations are indivisible. Either all of the operations that make up a transaction are committed to the database or none is committed. There is no halfway stage.

  • Consistent: Transactions move the database from one consistent state to another. In other words, after a transaction is fully complete, the database is consistent.

  • Isolated: Changes made to the database are not visible to users until all operations that make up the transaction are completed. At this point, the transaction is committed to the database.

  • Durable: Committed transactions are preserved even if the system crashes.

We will examine many of the features that contribute to ACID compliance in this chapter, including:

  • The single-instance storage model

  • Transaction logging

  • Recovery from server crashes

  • Throughput

Operational experience demonstrates that many system administrators do not understand the way that the ESE database model works. Knowing how transactions occur and are stored is fundamental to understanding Exchange, as is the concept that transactions are stored in three different locations: the on-disk databases (content and properties in the EDB database and potentially content in the streaming file), a cache managed in memory, and a separate set of transaction logs for each active storage group. Before we look at how the features of the Store help Exchange to achieve these goals, we need to review how ESE organizes data within the database.



 < Day Day Up > 



Microsoft Exchange Server 2003
Microsoft Exchange Server 2003 Administrators Pocket Consultant
ISBN: 0735619786
EAN: 2147483647
Year: 2003
Pages: 188

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net