Exchange server uses the Extensible Storage Engine (ESE) Indexed Sequential Access Method table manager. This table manger works on the basis of discrete transactions and log files. Active Directory is employed on top of an Indexed Sequential Access Method (ISAM) table manager. ESE handles all the tasks related to maintenance of AD integrity. It possesses full data manipulation language (DML) and data definition language (DDL) capabilities for handling all transaction requests made by DSA; the request may include the addition, modification or deletion of an AD attribute. The Ntds.dit file stores all the data related to each transaction occurring in the domain controller.
The default location for Ntds.dit file is : < drive >\winnt\NTDS\Ntds.dit
ESE keeps track of all Exchange server data in memory, log files, and database stores. Exchange store uses ESE for storing Exchange database records and create indexes. The ESE engine supports JET technology and multi-threading. On the top of ESE database, there lies an Exchange store. Exchange database contains all the records and indexed stored by ESE. Different applications use ESE in different ways for storing and accessing records. ESE has three versions: ESE97 that was used in Exchange Server 5.5, ESE98 that is used in Exchange versions 2000 and 2003; the third version of ESE is ESENT. It uses 10 MB for log files and 8 KB pages but the other versions of ESE implementation uses use five MB log files and four KB page sizes.
How Does ESE Manage Transactions?
Each transaction is an indivisible unit that contains a series of operations that are bundled inside the transaction. ESE keeps track of all operations from the commencement of operation till its completion. When an operation is being performed then the change is not applied permanently to the database, so that if the operations cannot be performed completely then the database can be brought back to its previous state. Once the operation is completed successfully the change is permanently applied to the database. This ESE provides the recovery and roll back facility so that if a crash occurs or transaction couldn’t be completed successfully due to some reason, then the database can be kept synchronized and consistent.
Version Store
It keeps track of the current ongoing ESE transactions and manages an in-memory list of the operations being performed to the database. It supports Rollback, Write-conflict detection, Repeatable reads, deferred before-image logging. These features make it capable of keeping the ESE transaction Isolated and Consistent.
Transaction Rollback
If it is required to roll back a transaction, then version store comes into play. It stores all the list of operations performed within the transaction. The series of operations is performed again in reverse order; from there the database can be restored back to the previous state.
Write-conflict Detection
What will happen if two different sessions are trying to modify the same record, here again Version stores plays a significant role. It keeps track of the sessions going on and if it finds such case then it accepts the first modification and rejects the second one.
Repeatable Reads
Version store helps to avoid the database view conflict that can occur if a session is viewing a record and other sessions modify the records that it is viewing. The version store helps in determining that which version of the database record should be presented in the session for viewing. Thus a session will view the record regardless of modifications made by other clients or sessions. Or we can say that the modifications made by other clients or sessions are isolated from each other.
Deferred Before-Image Logging
This feature helps in optimizing the data of ESE; this helps ESE to keep its data less as compared to other database engines.
ESE Database Pages and ECC Checksum
A ESE database stores the data in B tree structure i.e. parent element at the root and child elements at a node. The database files include edb file, .stm file, and transaction log files. 64 bit Error Correcting Code (ECC) has been introduced in Exchange Server 2003 Service Pack 1 (SP1), the earlier formats used 32 bits. The previous versions of ESE used four-byte checksum, followed by a four-byte page number but ECC starts with an eight-byte checksum.
Database Consistency
ESE helps in maintaining the database consistency. When a page is read then ESE checks its flag and checksum for it. If the checksum is not same as the checksum calculated by ESE then, there is a checksum mismatch error. ESE corrects this error automatically; if the error cannot be corrected then it reports a -1018 error.
ESE manager is based on write-ahead log and a snapshot isolation model. It provides support for de-normalized schemas including tables. ESE has to perform the Database tree balancing function. For a balanced tree there must be the same number of nodes at the root level and at the leaf level. Split and merge operations are performed by the ESE for managing the page’s data. When a page gets full, it keeps the half data and the rest half is shifted to a secondary page. Merge operation is performed when a page is almost empty. In such case the empty page is merged with an adjacent page.
If I recapitulate the summary of the above article, we can easily wrap up the fact that the transactions performed by ESE possess ACID properties (i.e. Atomicity, Consistency, Isolation, and Durability). These properties make ESE supportable for server applications as well as it is lightweight, provides high data performance using caching and concurrent transactions. These properties also make it suitable for auxiliary roles and light structured data storage applications. Read my upcoming article, to know more about ESE, its functioning and related issues.
0 comments:
Post a Comment