Taming your Exchange Databases
Dont let your Exchange databases grow out of control; tame them by configuring Outlook to relieve some of the burden.
In many companies, e-mail has quickly become a critical application. In fact, it's not at all uncommon to see private information store files on Exchange servers reach several gigabytes in size. Unfortunately, although Exchange 5.5 is supposed to be a scalable application, it has some inherent problems that you might encounter when Exchange databases grow to extremely large sizes. In this article, I'll discuss some of these problems. I'll then go on to explain how to configure Outlook 2000 to relieve some of the burden from your Exchange servers.
Issues with the Exchange Databases
Several problems are related to this rapid growth. For starters, the larger the database is, the longer it takes to back up and restore. For example, I once had a manager who needed a single message restored from a 9 GB private information store. In Exchange, there's no easy way to restore individual mailboxes or messages (without third-party utilities), so I had to build up a spare Exchange server. After doing so, I had to restore the backup to this new server and extract the one message that my boss needed into a personal folder. I then had to attach this personal folder to an Outlook client and copy the message from the folder to the user's inbox. The process took all night. Most of that time was spent waiting on the backup tape.
Other problems come into play because the three Exchange databases mentioned earlier must be kept in sync. Occasionally, delays caused by processing extremely large databases can cause the databases to become unsynchronized. In a situation like this, you can use built-in utilities such as ISINTEG and ESEUTIL to repair or resynchronize the databases. However, the Exchange services must be shut down to do so. In the case of large databases, the repair process could take quite a few hours, preventing mail flow for quite some time.
One other problem that you might run into is that large databases can quickly cause your server to run out of disk space. As you've probably already figured out, the best way to prevent all these complications that I've mentioned is to decrease the size of your Exchange databases. The easiest way to do this is to break the PRIV.EDB into many smaller pieces that can be individually managed. By doing so, you're not putting all of your information eggs in one basket. If you were to have a massive Exchange server crash, very little information would be lost.