The poor, misunderstood patch file

By Jerry Cochran 01 Nov 2004 | SearchExchange.com

Digg This!     StumbleUpon     Del.icio.us

The following is tip #10 from "20 tips on protecting and recovering Exchange data in 20 minutes," excerpted from the book, "Mission Critical Microsoft Exchange 2003" (Digital Press, a division of Elsevier, Copyright 2004). For more information about this book and other computing titles, please click here. Return to the main page for more tips on this topic.

Patch files (*.PAT) are special-purpose files used by the Exchange Server database engine on limited occasions. During on-line backup operations, the database file is written out 64 KB at a time in a sequential fashion. In other words, the 4-KB database pages are written sequentially in groups of 16 pages at a time (16 x 4 KB = 64 KB).

Since Exchange Server allows backup operations to be performed while the server is running and users are connected, it is possible that changes to pages in the already written (or backed up) section of the database will not be on tape. This case, however, is handled by Exchange since these changes will be stored in the transaction logs, which will be copied to the backup as well. Another case exists, however, in which a single 4-KB page that resides in the portion of the property store (EDB file) already copied in the backup becomes full (i.e., all 4 KB are used) as a result of transactions that have occurred since the backup was begun. In this case, the page must be split and a new page allocated in the B-Tree structure of the database (remember that the streaming store is not a B-Tree database structure and therefore does not require patch file measures).

A similar situation occurs if pages must be merged. If the pages are involved in a split or merge operation occurring across the backup committed/uncommitted boundary, they cannot be handled by the transaction logs alone. Therefore, these operations must be written to a separate location in order for the property store database to remain consistent when it is restored from backup. Updates to pages in the portion of the database that has already been copied in the backup are stored in the patch file. There is a patch file created during on-line backup for each database. During recovery, the database engine will update the database with any pages that are stored in the patch file.

Starting with Exchange 2000, Microsoft implemented the same level of integrity checking of each page in the patch file as is available for the property store. Each page in the patch file is verified using the checksum stored in the page header. Patch files are an important concept to understand concerning disaster recovery for Exchange server running versions prior to Exchange 2000 SP2. This entire discussion of patch files and their use is purely academic since the important point is that ESE takes care of everything for you.

So how did Microsoft eliminate the need for patch files in Exchange 2000 SP2?

Surprisingly, it was rather simple. Microsoft developers determined that the reasoning behind the original design requirement was a bit flawed. The patch file was needed because of the possibility that database page modifications that resulted in pages being merged or split could not be handled well during backup operations because, if the location (either before or after the current backup location) of these merged or split, pages would be unknown. They decided to invent a mechanism to handle this -- but was it the best way to solve the problem?

After many years, the JET/ESE developers came to the conclusion that they could handle the page merge/split scenario and effectively accomplish the same thing as the patch file by simply not advancing the ESE checkpoint and not flushing dirty database pages to disk during backup operations.

In this manner, ESE is able to handle page splits and merges during a backup operation. This little thing is a big win since the elimination of the patch file just means there is one less thing to go wrong during hard recovery operations.

I wish I could have seen the light bulb go on and heard the resulting "Duh!" when ESE developers figured this one out.

Get more "20 tips on protecting and recovering Exchange data in 20 minutes." Return to the main page.

About the author: Jerry Cochran is a contributing editor for Windows IT Pro and Exchange & Outlook Administrator and a group program manager for Microsoft. He is the author of Mission-Critical Microsoft Exchange 2000 (Digital Press).

Digg This!     StumbleUpon     Del.icio.us

RELATED RESOURCES 2020software.com, trial software downloads for accounting software, ERP software, CRM software and business software systems Search Bitpipe.com for the latest white papers and business webcasts Whatis.com, the online computer dictionary