These days, some customers are deploying Exchange databases and log files on advanced format (4K) drives. Although these drives support a physical sector size of 4096, many vendors are emulating 512 byte sectors in order to maintain backwards compatibility with application and operating systems. This is known as 512 byte emulation (512e). Windows 2008 and Windows 2008 R2 support native 512 byte and 512 byte emulated advanced format drives. Windows 2012 supports drives of all sector sizes. The sector size presented to applications and the operating system, and how applications respond, directly affects data integrity and performance.
For more information on sector sizes see the following links:
- Understanding the Impact of Large Sector Media for IT Pros
- Advanced format (4K) disk compatibility update
- KB 2510009 Microsoft support policy for 4K sector hard drives in Windows
When deploying an Exchange 2010 Database Availability Group (DAG), the sector sizes of the volumes hosting the databases and log files must be the same across all nodes within the DAG. This requirement is outlined in Understanding Storage Configuration.
Support requires that all copies of a database reside on the same physical disk type. For example, it is not a supported configuration to host one copy of a given database on a 512-byte sector disk and another copy of that same database on a 512e disk. Also be aware that 4-kilobyte (KB) sector disks are not supported for any version of Microsoft Exchange and 512e disks are not supported for any version of Exchange prior to Exchange Server 2010 SP1.
Recently, we have noted that some customers have experienced issues with log file replication and replay as the result of sector size mismatch. These issues occur when:
- Storage drivers are upgraded resulting in the recognized sector size changing.
- Storage firmware is upgraded resulting in the recognized sector size changing.
- New storage is presented or existing storage is replaced with drives of a different sector size.
This mismatch can cause one or more database copies in a DAG to fail, as illustrated below. In my example environment, I have a three-member DAG with a single database that resides on a volume labeled Z that is replicated between each member.
Read my favorites blogs: