Determining the best database size requires the evaluation of many factors. Smaller databases are generally better because they can be backed up and restored more quickly than larger databases. However, database size should be balanced against other factors, especially capacity and complexity. Immediately deploying the maximum number of databases may add unnecessary complexity to your system. For example, you may end up managing more databases and logical unit numbers (LUNs) than is necessary.

We recommend that Exchange databases be approximately 50 gigabytes (GB) in size. For databases in storage groups that are not enabled for continuous replication, we recommend a maximum database size of 100 GB. For databases in storage groups that are enabled for continuous replication, we recommend a maximum database size of 200 GB. For more information, see Planning Storage Configurations.

We recommend that you place each new database in its own storage group until the maximum number of storage groups is reached. This recommendation provides several advantages:

• It allows you to spread the load of mailboxes across as many databases and storage groups as possible.
  
  
• It creates an Exchange storage topology that can be managed more easily.
  
  
• Databases can be smaller.
  
  
• Log files and log traffic are not shared between multiple databases.
  
  
• Drive input/output (I/O) can be better managed.
  
  
• Recoverability is improved.
  
  
• It provides more aggregate checkpoint depth per user.
  
  

Databases in a storage group are not fully independent because they share transaction log files. As the number of databases in a storage group increases, more transaction log files are created during normal operation. This larger number of transaction log files requires additional time for transaction log replay during recovery procedures. An increase in time for transaction log replay consequently results in an increase in recovery times.

For more information about transaction logging, see Understanding Transaction Logging. For more information about disaster recovery, see Disaster Recovery Strategies.

Storage Groups Enabled for Continuous Replication

Because I/O to log files is sequential and I/O to database files is random, for increased performance, we recommend placing log files on a separate disk from database files. By using one log file for many databases, you can reduce the number of disks that are required. However, there are two disadvantages to this approach:

• If the disk that contains the log files fails, multiple databases are corrupted or lost instead of just one.
  
  
• Recovery from log files takes longer because the logs replay data for more databases.
  
  

For detailed guidance about designing and validating a storage solution for Exchange 2007, see Planning Storage Configurations.

For maximum performance and reliability, we recommend that even comparatively simple systems, such as systems that contain a single storage group, should also place log files and database files on separate disks.

For more information about managing storage groups and databases in Exchange 2007, see Managing Storage Groups and Databases.

For information about managing public folders, see Managing Public Folders.

For information about managing mailbox databases, see Managing Mailbox Databases.

To learn more about storage in Exchange 2007, see Transport Server Storage Design and Planning Storage Configurations.

For a list of the Exchange Management Shell cmdlets that you can use to manage storage groups and databases, see Storage Group and Database Cmdlets.