Understanding Exchange 2010 Page Zeroing

  • Artikel

 

Applies to: Exchange Server 2010 SP3, Exchange Server 2010 SP2

By default, most storage systems (file systems and databases) don't write over the actual data when it's deleted. They delete the pointer to the data and add the pages and blocks backing the data to a free or available list. The data is eventually deleted when the pages and blocks are re-used. Data zeroing is a mechanism that writes either zeros or a binary pattern over deleted data in an attempt to make the data much more difficult to recover. This action is taken for security reasons. Data zeroing occurs prior to the pages and blocks being re-used by the storage system.

Page Zeroing in Exchange 2010 SP1

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.

Implementation of Page Zeroing in the ESE Database

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

ESE run-time operation Fill pattern

Replace

R

Record/long value delete

D

Freed page space

H

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

ESE background database maintenance operation Fill pattern

Record delete

D

Long value delete

L

Freed page space of partially used page

Z

Freed page space of unused page

U

Background Database Maintenance

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.

Process of ESE Database Page Zeroing

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

ESE background database maintenance operation

Database delete scenario ESE process and timeframe to zero database data

  • Scenario 1: Single item recovery is disabled and user purges item from the Recoverable Items folder.

  • Scenario 2: Single item recovery is disabled and the Recoverable Items retention period is set to zero.

  • Scenario 3: Single item recovery is enabled and the item expires based on the deleted item retention period.

An asynchronous thread writes a binary pattern over the deleted data. This action occurs within milliseconds of the record deletion. If the Store process crashes while the asynchronous zeroing work is still outstanding (or version store cleanup is cancelled due to version store growth), the zeroing is completed when background database maintenance (24x7) processes that section of the database. For more information about background database maintenance, see New Exchange Core Store Functionality.

View Scenario: Expiration of items from Outlook/Outlook Web Access folder view (for example, Conversation view)

Data zeroing occurs when background database maintenance (24x7) processes this section of the database.

Move Mailbox/Delete Mailbox Scenario: Deletion of source mailbox (expiry of deleted mailbox from dumpster)

Data zeroing occurs when background database maintenance (24x7) processes this section of the database.

Monitoring Page Zeroing Behavior

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.

Exchange 2010 Mailbox Data and Page Zeroing

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.

 © 2010 Microsoft Corporation. All rights reserved.