In Service Pack 1 (SP1) for Exchange Server 2010, page zeroing is on by default. There is no mechanism to disable it. Page zeroing operations are recorded in the transaction log files so that all copies of a database are page-zeroed in a similar manner. That is, zeroing a page on the active database causes the page to get zeroed on a passive database after the passive database replays the transaction log with the page zeroing log record. There is no mechanism for the Extensible Storage Engine (ESE) to prioritize the reutilization of zeroed pages over allocating new space. Tables which have sequential space allocation assigned will intentionally skip fragmented or zeroed pages in favor of using new or free sequential pages. This approach reduces the database I/O footprint of the server.

In Exchange 2010 SP1, improvements to database page zeroing help to reduce the performance impact on servers when they're performing zeroing functions. Key improvements are:

• Optimized storage and network capacity   The Extensible Storage Engine (ESE) writes a page-zeroing record to the transaction log file instead of logging the entire page image. This approach reduces log write I/O, keeps the capacity footprint of the logs as low as possible, and reduces the bandwidth requirements to ship the logs from active to passive copies.
  
  
• Optimized database disk I/O   In previous versions of Exchange 2010, page zeroing occurred only during a backup or scheduled maintenance process (when configured), and caused significant database disk I/O. In Exchange 2010 SP1, page zeroing occurs by default and happens primarily at transaction time. For the majority of cases, the zeroing occurs immediately after the hard delete. This design allows the database to utilize the checkpoint depth capability of the engine, which ensures dirty pages stay in cache for a certain amount of time so additional page updates that occur in close time proximity don't cause additional database write I/O. Because of this design, page zeroing has no significant database I/O impact, which is why it's enabled by default.
  
  

The ESE database uses pages as its unit of storage and has implemented page zeroing. ESE page zeroing writes a binary pattern once over a hard-deleted record. The page-zeroing pattern is specific to the ESE engine operation and is different for run-time operations vs. maintenance operations. The following table lists the fill patterns that correspond to specific run-time operations.

Fill pattern of page zeroing per ESE run-time operation

The following table lists the fill patterns that correspond to specific operations that occur during ESE background database maintenance.

Fill pattern of page zeroing per ESE background database maintenance operation

Configured by default, background database maintenance is a process which continuously checksums and scans the database in the background. Its primary function is to checksum the database pages, but it also handles cleaning up after Exchange 2010 Store crashes (cleaning up space and zeroing out records and pages which did not occur due to the crash). Background database maintenance processes approximately 5 MB per second per database. If timely page zeroing is a priority, you can reduce database sizes to ensure page zeroing occurs for the crash recovery cases in a shorter time period (for example, 24 hours). For more information, see New Exchange Core Store Functionality.

Background database maintenance is a continuous process, so there are no events associated with its start and completion. You can track the progress of background database maintenance completion with the following performance counter:

• MSExchange Database =>Instances->Database Maintenance Duration: This performance counter indicates the number of seconds that have passed since maintenance last completed for a given database.
  
  

The following table discusses database delete scenarios, and when page zeroing functions occur.

ESE background database maintenance operation

You can measure and monitor page zeroing functionality with the following ESE performance counters:

• MSExchange Database->Database Maintenance Pages Zeroed: This performance counter indicates the number of pages zeroed by the database engine since the performance counter was invoked.
  
  
• MSExchange Database->Database Maintenance Pages Zeroed/sec: This performance counter indicates the rate at which pages are zeroed by the database engine.
  
  

Note:
To learn how to enable these counters, see How to Enable Extended ESE Performance Counters.

Page zeroing is a database maintenance function, so performance information related to both page zeroing for run-time transactions and page zeroing due to background database maintenance is included in these counters.

Only the Mailbox database file (.edb) has provisions for page zeroing. The following Exchange 2010 Mailbox data types have no provisions for page zeroing:

• Mailbox database transaction logs (.log)
  
  When transaction logs are deleted (due to truncation via backup or circular logging), there is no process to zero the blocks in the NTFS file system backing the log file. It's likely that NTFS will quickly re-utilize that free space for newly created logs, but there is no guarantee that this will happen.
  
  
• Content index catalog files
  
  Exchange 2010 uses Exchange Search (MSExchangeSearch) for search indexing functionality. The search index catalog is comprised of several dozen files stored on the same volume as the mailbox database file. When a message is hard-deleted from the mailbox database, the associated content in the search catalog isn't immediately deleted. The content deletion occurs when MS Search does a shadow, or master merge, of many small catalog files in to a single larger file. After the master merge completes, the smaller catalog files are deleted. There is no process to zero the blocks which backed the deleted catalog files. To ensure the catalog files are fully zeroed, use the following process:
  
  
  1. Stop the MSExchangeSearch and Microsoft Search (MSSearch) processes on affected servers.
     
     
  2. Delete the catalog directory for each affected database (on all copies).
     
     
  3. Re-start the MSExchangeSearch and MSSearch processes.
     
     
  4. Zero-out the freed block using a NTFS block zeroing tool.
     
     

  Note:
  Deleting the content index catalog files severely impacts the client user experience on the Exchange 2010 server. Outlook Web App and Exchange ActiveSync server searches will be broken until the content index rebuilds the catalog by re-crawling each database. This rebuild could take several days to several weeks to complete.