Dealing with Databases

I recently worked with a customer who operated a mixed Exchange Server 2003 and Exchange Server 5.5 organization and was in the process of migrating the Exchange 5.5 users to the company's single Exchange 2003 Standard Edition Service Pack 1 (SP1) server. This server had a maximum database size of 16GB. (The Enterprise Edition doesn't limit database size in this way, but the Standard Edition does.) During the migration, the Exchange Information Store service shut down because the database exceeded that limit. (Naturally, this occurred just before Microsoft released Exchange 2003 SP2, which raises the limit to 75GB.) Does this scenario sound all too likely (or familiar)? Have you ever felt overwhelmed by the ins and outs of managing Exchange databases? You can take some of the worry out of Exchange administration by improving the way you deal with your Exchange databases.

How Big Is Big?
Most Exchange consultants recommend that Exchange private and public stores be kept below 40GB. However, given the considerable improvement in backup and restore technologies, large organizations with appropriate storage and tape configurations can let their stores grow to between 60GB and 80GB. The reason for the traditional 40GB limit isn't architectural; the limit is operational and is driven by service level agreements (SLAs) and the time needed to recover the databases. Traditional backup and restore processes and technologies, such as direct-attached DLT tapes, have restore rates in the region of 40GB to 60GB per hour. Modern SAN-based environments, which use storage virtualization and state-of-the-art Linear Tape-Open (LTO) tape drives, let you back up or restore Exchange databases at a rate of about 100GB per hour. Large databases in Exchange environments can implement Volume ShadowCopy Services (VSS)-based backups and restores in seconds. (The 40GB limit is still valid for stand-alone Exchange 2003 server configurations that use DAS.) . . .