In an Exchange 2000 Server environment, how well your server performs depends largely on how well it’s configured. The way you use your hard drives is one of the most important configuration issues. Where you place your databases and related database support files makes a huge difference as to how well the server will keep up when placed under a load and how easily, if at all, you’ll be able to recover your server in a disaster situation.

If you’re coming from an Exchange 5.5 environment, you already know something of the importance of proper database placement. However, things have changed a bit in Exchange 2000, because unlike Exchange 5.5, Exchange 2000 allows you to use multiple databases. To maximize your server’s performance, it’s important to understand how Exchange 2000 databases function and how you can get optimal performance out of your server by rearranging your databases.

Exchange database components
Just like its predecessors, Exchange 2000 uses the Jet database format. The Jet database format relies on a database engine known as the extensible storage engine (ESE). The ESE is responsible for manipulating the data within the actual databases. As with many other database formats, the database engine and the database itself can’t function alone. Many components, such as transaction logs, reservation files, and the checkpoint file, work together to make the database functional. In the sections that follow, I’ll discuss each of these components and explain how they work together.

The transaction logs
The transaction log preserves the integrity of the databases and makes the databases available at all times. To see how this works, imagine that you are writing records directly to the Exchange databases. In a busy Exchange environment, it’s not at all uncommon for several records to be written each second. Now, suppose the power fails while you’re posting records directly to this database. When the system comes back online, there’s a very good chance the database will be so corrupt that you wouldn’t be able to use it.

In a situation like this, even if you ran some sort of utility against the database to remove corruption, the database would have no way of knowing which transactions had and hadn’t been processed. You might be able to make the database functional again, but you’d lose an undeterminable amount of data in the process.

This is where the transaction logs come into play. Rather than posting data directly to the database, the transactions are posted to a transaction log file. The idea is that after a power failure, you can bring the database back into a consistent, usable state by comparing the database contents to the transaction logs.

Transaction logs also allow the server to run even during a backup. Normally, you can’t back up a database while it’s in use. Likewise, you can’t use a database while it’s backing up. However, when you use transaction logs, all transactions are posted to the logs instead of to the actual database while the backup is in progress. This allows Exchange users to continue working even during a backup.

Checkpoint files
In Exchange, it’s the responsibility of the checkpoint file to keep track of the transactions that have and haven’t been posted to the database. Each transaction log file is a uniform size and contains multiple transactions. The transaction log files’ names define a sequence. For example, a transaction log file named E0014.log would fall between E0013.log and E0015.log. Any time a transaction log file fills up, Exchange starts posting transactions to the next log file in the sequence. Exchange then posts all of the transactions from the completed log file to the database. Finally, Exchange updates the checkpoint file to reflect the name of the last transaction log file that was posted to the database.

To keep the transaction logs from completely filling up your hard disk, Exchange 2000’s extensible storage engine makes use of something called circular logging. There are a limited number of total log files, which take up a limited amount of hard disk space. So when Exchange 2000 fills up the highest numbered log file with transactions, it overwrites the lowest numbered transaction log and then works its way up to the higher numbered log files again.

You may recall that Microsoft used to discourage circular logging. Although it was available in Exchange 5.5, it was intended for use only on systems that were low on free hard disk space. In Exchange 2000 though, circular logging is the default setting, and Exchange is optimized to run better with circular logging enabled. You can disable circular logging by opening the Exchange System Manager console and navigating through the console tree to your organization | Administrative Groups | your group | Servers | your server | the storage group containing the database, where the italicized words denote objects in your server’s tree.

Right-click the storage group with which you want to work and select Properties to view its properties sheet. On the General tab, you’ll see several items including the location and prefix used by this storage group’s log files. The properties sheet also contains the Enable Circular Logging checkbox. Ensuring that this box isn’t checked disables circular logging. If you disable circular logging, the checkpoint file is reset after each backup of the Exchange databases.

Reservation files
Suppose you decided to disable circular logging and never back up your system again. What would stop the transaction logs from filling up the hard disk? Nothing; the hard disk would eventually run out of space. This is where the reservation files come in. The reservation files, Res1.log and Res2.log, each consume 5 MB of space. The sole purpose of these files is to take up space, so if you run out of hard disk space, you can erase them and reclaim some space. Remember, erasing the reservation files will get you just enough hard disk space to get the server back online. After that, you’ll need to take further steps to free up more space, such as deleting other unnecessary files like temp files, etc.

Databases
Perhaps the biggest database-related change you’ll encounter when going from Exchange 5.5 to Exchange 2000 is the database itself. Exchange 5.5 used a directory service database called Dir.edb. In Exchange 2000, this file doesn’t exist because Exchange 2000 pulls all of the directory information from the Windows 2000 Active Directory rather than from a standalone database file.

The Priv.edb and Pub.edb files still exist, but there have been a few changes, as well. One change is in the way information is stored within the databases. In Exchange 2000, a globally unique identifier (GUID) references most of the database records, because there’s no such thing as a mailbox in Exchange 2000. Instead, an Active Directory user object is mail enabled. Therefore, if an e-mail message is intended for a specific user, an entry is added to the database that links the message to the appropriate Active Directory user object.

Storage groups
Another big change in Exchange 2000 is the addition of storage groups. In Exchange 5.5, each server contained only one private information store and one public information store. In Exchange 2000, you can have up to four storage groups per server. Each storage group can support up to six databases. Therefore, if your server is powerful enough, you can have up to 24 databases, which enables you to give each department its own public folder tree or host mail services for multiple companies.

File placement
Database placement is critical to the way your server runs, because Exchange 2000 tends to be extremely disk intensive. Therefore, it’s important to place the database and the log files in a location that will provide them with the best possible hard disk service.

For the databases, your best bet is on a RAID array. RAID arrays stripe data across multiple hard drives, which means data can be read and written faster than it could be to a single hard disk. For example, if your RAID array is made up of five hard drives, you could read data five times faster than you could from a comparable single drive, or four times faster if you use parity.

I recommend using a dedicated RAID array to house a database under heavy use. By reserving the entire array for the database, the database will never have to wait for disk services when the hard disks are busy with another file.

If your databases already reside in a location that provides them with optimal performance, that’s great; if not, you may want to move them. You can do so by opening the Exchange System Manager console and navigating through the console tree to your organization | Administrative Groups | your group | Servers | your server | the storage group containing the database | the database, where the italicized words represent objects in your server’s tree. Right-click the database you want to move and open the database’s properties sheet. Select the Database tab to view the database’s current location. You can then click Browse to begin moving the database. When the Exchange Database window appears, you can find a new location for the database. Clicking Save in the Exchange Database window moves it to the new location. Previously, I showed you where to go to move the transaction log files. The placement of these files is almost as important as the placement of your databases. You’ll need to place these files on a fast hard drive so Exchange can run smoothly. Again, I recommend using a dedicated hard drive—drive, not partition—so Exchange 2000 doesn’t have to wait for another application to finish using the hard disk. The partition containing the transaction log files should be running NTFS so it can take advantage of the NTFS file transaction recovery system in case anything goes wrong. Microsoft also recommends you mirror the drive that contains the transaction logs so that if a drive were to fail, you wouldn’t lose your transaction logs.

Conclusion
When it comes to optimizing Exchange 2000’s file performance, you can forget a lot of what you learned when administering Exchange 5.5. Microsoft changed the way Exchange 2000’s databases and files work. By paying close attention to way you arranged Exchange 2000’s important files, you can optimize performance and avoid bottlenecks.