If you missed the first part in this article series please read Exchange 2007 Online Maintenance Database Scanning (Part 1).
Introduction
In part one of this two part article we covered an introduction to the two main processes that comprise online maintenance database scanning, namely checksumming and page zeroing of the database pages. We then went on to look more closely at the database checksumming process, covering what it is, how it operates, how to enable it and the event log information it produces so that you can track its progress.
Here in the second and final part of this article we’ll cover the same information for the database page zeroing process and finally end up by having a brief look at some performance information relating to these two processes. So let’s get going and see what database page zeroing offers us and how to enable it if we require it.
Database Page Zeroing
The database page zeroing feature has been around in previous versions of Exchange and it is something that you may have come across if you have worked with Exchange before Exchange 2007 was released. Page zeroing is an additional security feature that can be used to make Exchange database data unrecoverable, or as Microsoft puts it “unrecoverable via conventional methods”. It does this by overwriting unused database pages with zeroes. What is meant by unused pages? These are the pages that formerly contained data but that data has now been removed, such as when users delete unwanted messages from their mailboxes. Of course, these database pages won’t be marked as unused until any additional retention periods have passed, such as the deleted item retention period that allows users to recover messages that they had previously deleted. Admittedly, the database page zeroing feature is likely to only be used in those organizations that require higher levels of security within their messaging infrastructures but if you’ve decided that this is something that interests you and your organization then read on.
Although the database page zeroing feature was available in the Release To Manufacturing (RTM) version of Exchange 2007, it’s now possible in SP1 to perform database page zeroing during online maintenance. You may wonder why this is of importance. If you’ve read part one of this article you may remember that the database checksumming process had specific issues when used in conjunction with the continuous replication technologies such as Clustered Continuous Replication (CCR) in Exchange 2007 RTM. The database page zeroing feature also has some limitations when used with the high availability technologies such as Local Continuous Replication (LCR) or CCR within the Exchange 2007 RTM infrastructure. The problem is that the zeroing changes made on the active copy of the database are not copied to the passive database used with LCR or CCR. To overcome this, organizations had to either take the databases offline and manually run the ESEUTIL utility, or perhaps take a streaming backup against both the active and passive copies of the databases. Like the workarounds used with the checksumming process, these workarounds are not ideal at all. To address these issues, Microsoft made sure in Exchange 2007 SP1 that the changes can be replicated via the continuous replication technologies. Also, when using LCR or CCR in conjunction with Volume Shadow Copy Service (VSS) backups the page zeroing process cannot be implemented with Exchange 2007 RTM since it only applies to streaming backups. By making the page zeroing process part of online maintenance, this situation is overcome.
Enabling Database Page Zeroing
Enabling the database page zeroing feature, like the database checksumming feature, also requires making a change to the registry as once again this is an opt-in feature. This registry sub-key will not exist by default on an Exchange 2007 server so it must be created. The change to make is:
Key: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ParametersSystem
Name: Zero Database Pages During Checksum
Type: DWORD
Value: 1
A screen shot of how this registry value looks is shown in Figure 8. As with the checksumming registry key, once you’ve made the registry change you will need to restart the Microsoft Exchange Information Store service for the change to become effective.
Figure 8: Database Page Zeroing Registry Key
Event Log Entries
There are new event log entries that will help you examine the progress of the database page zeroing feature in the same manner as we’ve seen with the checksumming feature. First, when the database page zeroing process starts, the following event is logged:
Source: ESE
Category: Online Defragmentation
Event ID: 718
Description: Online maintenance is starting the database page zeroing background task for database <database name>.
An example of this event is shown in Figure 9.
Figure 9: Event 718
Once the process has completed, the following event is logged:
Source: ESE
Category: Online Defragmentation
Event ID: 722
Description: Online maintenance database zeroing background task has completed for database <database name>. This pass started on <DATE> and ran for a total of <N> seconds, requiring <N> invocations over <N> days.
The description field continues to give you an operation summary which includes key information such as the number of pages seen and zeroed. An example of this event is shown in Figure 10. Note that I have scrolled further down the description field in order to show you the operation summary in full.
Figure 10: Event 722
The other two events relating to database page zeroing that you may see are event 724, which occurs if the process encounters an error and event 729, which occurs when the process has been paused.
Performance Impact
As I said in part one of this article regarding database checksumming, take time to understand the performance impact of enabling database page zeroing before you implement it. In particular, you should recognize that implementing this feature on an existing large database that has been in use for some time could affect server performance in a negative way. This is because there could be a large amount of unused pages that all need to be zeroed which will obviously take some time and effort to do, resulting largely in increased disk I/O. It’s much easier if you enable page zeroing at the time a new database is created, since the ongoing effort to zero-out unused pages will obviously be much less. Also, you could easily double, if not more, your transaction log file generation until the first full pass has been performed. Of course, once the first full pass has completed things should return to normal regarding the rate that transaction logs are generated.
Information that I saw presented by Microsoft at TechEd IT Forum in November 2007 showed that the introduction of database page zeroing had a small increase in the % Processor Time counter, whilst the RPC Averaged Latency counter increased by approximately 20ms. Therefore, database page zeroing is something that you should only really run outside of your core user access times.
As with database checksumming, Microsoft provides performance counters for monitoring the database page zeroing process. They are:
- MSExchangeDatabase\Online Maintenance (DB Scan) Pages Read/sec
- MSExchangeDatabase==>Instances\Online Maintenance (DB Scan) Pages Read/sec
To see these performance counters you’ll need to again enable the extended Extensible Storage Engine (ESE) performance counters as you had to do for the database checksumming process. For details on how to do this, see part one of this article.
Summary
Over the two parts of this article we have looked at the database checksumming process as well as the database page zeroing process, covering what these are and how to enable them as part of online maintenance. Whilst the database checksumming process is likely a welcome addition to online maintenance, it is possible that the database page zeroing process may not appeal to every organization.
If you missed the first part in this article series please read Exchange 2007 Online Maintenance Database Scanning (Part 1).
