Microsoft has made some significant changes in Exchange 2000 Server from Exchange Server 5.5. One of the most important changes in the areas of reliability, recoverability, and flexibility for configuration is Exchange 2000 Server’s new storage groups. In this Daily Drill Down, I’ll give you the rundown on storage groups, explaining their purpose and some of their advantages. After you come to understand storage groups, you’ll understand one of the most compelling reasons to migrate from Exchange Server to Exchange 2000 Server.

The way things used to be
In Exchange Server 5.x, data is stored in two database files, Priv.edb and Pub.edb. The Priv.edb file contains the mailbox store, and the Pub.edb file contains the public folder store. Separating the two ensures that corruption in one doesn’t affect the other. For example, if the public folder store becomes corrupted and has to be re-created, it doesn’t take down the mailbox store.

Even with this measure of reliability, the Exchange Server store is still susceptible to some potentially significant problems, including data loss, performance, and recoverability. In order to understand how Exchange 2000 Server storage groups address those problems, you need to understand storage group architecture.

Storage group overview
As I mentioned, Exchange Server 5.x uses two database files, Priv.edb and Pub.edb, to store its data, with one set of files per server. By contrast, Exchange 2000 Server supports multiple folder stores contained in storage groups. A storage group is a set of Exchange database files that share a single transaction log and are managed as a single unit for administration, archiving, and restoration. Each storage group can contain up to six databases, and a single server can use up to four storage groups—that’s a total of 24 databases per server. As I’ll explain, this ability to create multiple databases and storage groups provides greater redundancy, flexibility, and recoverability for Exchange 2000 Server.

Each database in a storage group functions independently of the others and can be either mounted or dismounted (started or stopped). If a database becomes corrupted, Exchange 2000 Server won’t mount it. The good thing is that the corrupted database won’t affect the other databases in the storage group. This improves reliability in situations where you need to limit downtime as much as possible (which is virtually every situation). Therefore, you can repair the affected database and remount it without taking down the others. Plus, the failure of a single database doesn’t affect the information store (Store.exe) process—it can continue to manage the other databases.

I’ll take a little closer look at the storage group architecture later. For now, just keep in mind that each server can host multiple storage groups, and each group can contain multiple databases.

Advantages of storage groups
Exchange 2000 Server storage groups provide several advantages over the Exchange Server database model. These advantages make Exchange 2000 Server more stable, more reliable, and more flexible in terms of configuration and administration. Let’s take a look at some specific advantages.

Enhanced user support
In Exchange Server 5.x, all users are hosted in a single database. There are certainly practical limitations to the number of users you can host in an Exchange Server database. As the number of users grows, the size of the database grows. The larger the database, the longer it takes to back up, and more importantly, the longer it takes to restore. If you can’t afford to have your users down for a long period of time, the repair and restore time required for an Exchange Server 5.x database can be a real limitation of the usefulness and flexibility of Exchange Server.

Exchange 2000 Server provides a handful of advantages for your users. Because you can separate users into multiple databases, you reduce the potential size of each database. Rather than using a single 20 MB database for all of your users, you might instead use five databases, each at roughly 5 MB. The result is that individual databases back up faster and can be restored much more quickly, meaning you can safely host more users on a given server and/or decrease downtime by being able to restore a particular database more quickly because of its reduced size.

Separating users across multiple databases also means that when a problem does occur, the problem is more localized. In the five-database scenario above, for example, a single corrupted database might take down only 20 percent of your users rather than 100 percent. Not only are the other 80 percent unaffected, but also the 20 percent who are affected get their Exchange Server access back more quickly because of the decreased restore period.

As you’re deciding how to structure your storage groups to accommodate your users, keep in mind that although you can create six databases in a storage group, you’ll want to limit yourself to only five for recoverability reasons. The Information Store Integrity Checker (Isinteg.exe) requires a temporary database for analyzing a database with suspected problems. If you create six databases in a storage group, you’ll have to dismount one additional database when you need to run Isinteg on a database that’s experiencing a problem. So rather than taking down a group of users, limit the number of databases you create in a storage group to five, leaving one available for Isinteg.

Improved recoverability is another important advantage offered by Exchange 2000 Server storage groups—one I hinted at in the previous section. With Exchange 2000 Server, you can back up and restore each database independently of the others. If a database experiences corruption, you can dismount only that particular database and run the integrity check/repair process on the database. Meanwhile, the other users supported by the remaining databases are unaffected and continue to be able to access their Exchange data. In effect, Exchange 2000 Server storage groups enable you to perform a selective backup and restore to limit downtime and speed the archival process.

Hosting multiple organizations
The ability to separate users into multiple databases within a storage group or even to separate them into multiple storage groups has implications not only for organizations that host only their own users but also for organizations that host users in different companies. You could host multiple companies on a single Exchange 5.x server but doing so wouldn’t be practical from an administration perspective. Plus, having all of the businesses in a single database means that when the database goes down, all of your customers are affected.

With Exchange 2000 Server storage groups, you might host each company in a different database or even host each in its own storage group, depending on the number of users in each company, etc. This gives you the same advantages for supporting multiple companies as for supporting users. A single database or storage group going down means that only one business is affected, not all of them. When a problem does occur, you can take down the affected database and repair it without affecting the others, limiting downtime to a single company or even a single department within a company.

Storage groups also give you greater flexibility for administration when you host multiple companies. For example, one company might have different archival requirements than another. One might need weekly backups, while another might need backups daily or even more frequently. By separating the companies into different databases, you make it possible to back up their databases separately and at different frequencies, as needed.

Supporting unique storage requirements
The ability to separate recipients into different databases also gives you more flexibility in structuring how data is stored on your Exchange server. If you use journaling to keep a running archive of messages, for example, you could place the archive in a separate database for performance and recoverability reasons. Or you might want to separate departments or groups that have unique store requirements from other departments or groups. Whatever the scenario, storage groups give you much greater flexibility in structuring your Exchange server data.

Logging flexibility
The checkpoint file works in concert with the log files to inform Exchange 2000 Server of which entries in the log files have already been recorded and which entries need to be replayed during the recovery process. Log files with a timestamp older than the checkpoint file have generally had their transactions recorded and are not needed to restore the database.

Exchange 2000 Server supports a logging method called circular logging in which log files older than the checkpoint file are overwritten. Circular logging can improve recovery speed by eliminating the need to replay all log files and helps you manage disk space. However, circular logging has a negative impact on your ability to recover a database from a tape backup. Without all of the log files, you can restore the database only to the point of the last backup. With all the log files in place, you can restore the database to its state just prior to the failure. Therefore, circular logging limits your ability to restore the database from tape backups.

Because you can configure the logging properties of databases individually, Exchange 2000 Server’s support for multiple databases means that you can implement circular logging on those storage groups that contain less critical data (data in which you can afford to lose changes back to the last backup) and use linear logging on those that are more critical and that require the ability for complete restoration from tape.

Microsoft has made a lot of improvements in Exchange 2000 that make upgrading from Exchange 5.5 worthwhile. One of the biggest changes is the way that Exchange 2000 stores files. In this Daily Drill Down, I’ve given you a basic overview of Exchange 2000 Server’s new storage groups and the advantages they offer.
The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.