By now, you've probably heard about one of the biggest changes in Exchange Server 2003 Service Pack 2: SP2 increases the maximum database size to 75GB. Let's take a look at how SP2 implements this new 75GB database limit and how you can control and report database sizes.
Know Your Limits
If you've been working with Exchange for any length of time, you know what happens when the database hits its limit (16GB in Exchange Server Standard Editions prior to Exchange 2003 SP2). The Information Store service shuts down and Exchange logs event ID 1112, indicating that it's dismounting the database, and event ID 445, indicating that the database has reached its maximum size. The Store commits all outstanding transactions, disconnects clients, and dismounts the database. To remount the database, you must perform an offline defrag (or temporarily increase the maximum permitted database size) to remove some content.
You might assume that the new 75GB database limit makes this type of situation disappear. However, the story isn't quite that simple. Microsoft doesn't just bump up the database size to the new limit, but instead requires you to make an informed decision about the limits you deploy. The logic is that some Exchange Standard Edition servers, especially those running Microsoft Small Business Server (SBS), might not have a lot of free disk space. If SP2 automatically increased the database limit to 75GB, the database could grow to occupy all free disk space—causing a whole new set of problems.
When the Information Store detects 10MB or less of free space on the disk that mounts an Exchange database, the Store will automatically dismount that database. Imagine the possible outcome: Exchange could shut down on an unattended server because of a lack of disk space caused by unobserved database growth. For this reason, immediately after you install SP2 on a server, Exchange lifts the maximum database size to just 18GB. (See "Dealing with Databases," page 1, for more information about this process.) Another subtle change is that Exchange 2003 SP2 uses the logical database size (i.e., the actual space occupied in the database, without white space) rather than the physical file size on disk as the measure for the database limit. Thus, a database that has 18GB of real data with 10 percent white space can grow to be a 19.8GB file on disk before the limit kicks in.
These changes provide a useful boost in available database size, but to increase it even more, you'll have to define the maximum supported database size by tweaking the registry, using the Database Size Limit in GB entry that Table 1 shows. You'll need to create this entry in the HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\MSExchangeIS\ServerName\PrivateISIdentifier registry subkey. (Server Name is the name of the Exchange Server; Private IS Identifier is a string made up of "Private-" together with the objectGUID value for the database object in Active Directory—AD.) On a server running Exchange Standard Edition, you can set any value between 1 and 75. (Exchange Enterprise Edition supports the same registry setting, with the available values listed in Table 1.)
Heed the Warnings
Both Standard and Enterprise edition Exchange 2003 SP2 systems let you customize when Exchange will write size-limit warnings to the event log. By default, Exchange generates a warning (event ID 9689) when the logical database size reaches a specific limit (the default is to within 10 percent of the maximum permitted database size, otherwise known as the warning buffer), but you can modify the warning limit by setting the Database Size Buffer in Percentage registry entry (Table 1 lists valid values).
The warning buffer is a new concept introduced in SP2. When the Store mounts a database, it compares the database's physical size on disk to the maximum supported value for the server, minus the warning buffer. For example, suppose you have a 17GB physical database on a server, and you've set a 20GB maximum value size. The default buffer is 10 percent, so the warning value is the maximum size of the database less 10 percent. That's 20GB minus 2GB, or 18GB. So long as the database remains under 18GB, Exchange will continue to mount the database. However, if the database grows to 18GB, the next time the Store begins to mount the database, the Store will realize that the physical size might now be a problem and will check the logical space occupied by the database to determine whether the database's logical size is under the 18GB warning limit. If so, the Store will mount the database but also will write event ID 9689 to the Application log. The check takes a few seconds, so you'll experience a delay before the database is mounted.
Now let's suppose that the physical size of the database grows to 19GB. Once again, the Store checks physical and logical file sizes when it attempts to mount the database. This time, the Store discovers that even with the white space eliminated, the database's logical size is 18.2GB. Both the physical and logical sizes exceed the warning values, so you clearly need to take action to prevent the database reaching the 20GB maximum. Exchange again logs event ID 9689 to the Application log and sets an internal flag in the Store. This flag will cause the Store to dismount the database the next time the Store performs a size check (in 24 hours). You have one last chance to rectify the problem without troubling users too much because Exchange lets you remount the database even though the file size is exceeded. However, just as in earlier Exchange versions, you must remove content before the next file-size check. If you don't, Exchange will dismount the database and refuse to remount it until you run Eseutil (or a similar tool) to rebuild the database offline.
A Good Beginning
The move to a 75GB limit is a boon for anyone who runs Exchange 2003 Standard Edition. I only wish that Microsoft had provided some type of UI to control the database-limit settings, rather than requiring another set of registry changes. Hopefully, the UI will catch up in a future version.
NEED TO KNOW MORE?
If you want more information about managing Exchange Server databases or about Exchange Server 2003 Service Pack 2 (SP2), take a look at these articles, available online at http://www.windowsitpro.com/microsoftexchangeoutlook. (Accessing some articles might require registration, a print subscription, or a monthly pass.)
"Dealing with Databases," InstantDoc ID 48632 (page 1 in this issue)
"Top Exchange Design Considerations," InstantDoc ID 48307
"Exchange Server 2003 SP2 Delivers New Features Without the Cost," InstantDoc ID 48244
"What's new in Microsoft Exchange Server 2003 Service Pack 2 (SP2?)," InstantDoc ID 48365
"Troubleshooter: Reclaiming White Space in an Exchange Database," InstantDoc ID 25479
Tony Redmond ([email protected] pro.com) is a contributing editor for Windows IT Pro, a senior technical editor for Exchange & Outlook Administrator, vice president and chief technology officer for HP Services, and author of Microsoft Exchange Server 2003 with SPI (Digital Press).