Space allocation refers to the way that ESE allocates space on the database.

A column or a record in ESE cannot span pages in the data B-tree. However, there are values in the database that break the 32 KB boundary of a page. These are referred to as long-values (LV). A table's long-value B-tree is used to store these large values.

The B-tree defragmentation process has been improved to reduce I/O operations by maintaining contiguous data in the B-tree.

B-tree defragmentation is performed in-place (as opposed to creating a new B-tree and renaming the indexes and tables) with three new operations:

1. Page move   A page move consists of moving all data from one page to a newly allocated page.
   
2. Partial left merge   A partial left merge is the same as a right merge in Exchange 2007 or earlier, except that data is moved from the left page to the right page.
   
3. Full left merge   A full left is the same as a full right merge in Exchange 2007 or earlier.
   

Defragmentation has been changed from right merges to left merges to optimize performance. Data is read/written to the hard drive from right-to-left. If the database is being defragmented in the same direction as the read/writes, then defragmentation will conflict with the read/writes. In addition space allocation allows the next page in an extent to be allocated, but not the previous page. Because a page move needs to allocate a new page, defragging the database from left to right is much more efficient.

The Defragmentation Manager is a new event in ESE that monitors which B-trees require defragging and which B-trees have already been defragged. The defragmentation manager compiles a list of the B-trees in all mounted databases that should be defragged. As fragmented B-trees are discovered, they are registered with the Defragmentation Manager and the defragmentation manager will process them.

As stated earlier in this topic, all data inside the database is stored in B-trees, and the B-trees are divided into pages. The page size is the minimum size for reading and writing to the database; it is also the unit size used for database caching. Reading from the disk is slower than performing operations in memory; therefore, by increasing the page size to 32 KB, ESE reduces the IOPS which increases performance by caching the larger page size in memory.

Sync Read IO = Small/Random IO

Async Write IO = Large/Sequential IO

Exchange 2010 Store/ESE have put a lot of work in to moving away from Sync DB reads to Async DB Reads to leverage the contiguous nature of the database. View creations and updates, Outlook OST sync, Search result returns, Content Indexing crawls.

Disk subsystems are more efficient at handling fewer but larger IO. As stated erlier in this topic, in Exchange 2010 or earlier the page size is the minimum read/write size and the minimum size for database caching. Coalescing IOs refers to the process for combining database page operations into a single IO operations thereby producing fewer and bigger IO operations.

Increasing the average database IO sizes has the following benefits:

• Increased disk use efficiency   Disks are more efficient at processing large IOs. The more efficiently the disk is utilized, the more mailboxes can be hosted on that disk.
  
• Increase the cache warming rate   Cache warming is a process that helps reduce the execution times by preloading the initial queries that were executed against a database the last time the database was started. After a server reboot, restart, failover, or switchover, the larger IO allows ESE to increase the rate at which the cache is warmed.