Databases and Database Sizing

Exchange 2007 includes a number of noteworthy improvements with respect to the Exchange mailbox and public folder databases. Although Exchange databases still uses the Extensible Storage Engine (ESE), aka Jet database engine, rather than a SQL Server database, improvements allow greater scalability. The following are some of the changes that have been designed to improve scalability, improve performance, and make replication of data more feasible:

• The 64-bit version of the ESE database engine can access far more RAM for caching than previous versions.

• Each Exchange Server 2007 Enterprise Edition server supports up to 50 storage groups.

• Each Exchange Server 2007 Enterprise Edition server supports up to 50 databases.

• The database page size has been increased from 4KB (in previous editions) to 8KB in Exchange 2007 to improve read and write performance.

• Transaction log files are now 1MB in size rather than 5MB; this allows data to be replicated to a backup database location (in the case of LCR or CCR) much more quickly.

• The streaming store(STM) file found in previous versions of Exchange has been removed. Each Exchange database consists of a single EDB database file in which all content is stored.

We talked earlier about calculating the amount of disk space that you may require for Exchange Server 2007 mailbox servers. In Chapter 1, we reviewed the changing nature of e-mail and messaging technologies and emphasized that mail storage requirements are greater than ever. We always recommended planning for more disk space and e-mail capacity than you think you will require.

However, more e-mail storage means including in your Exchange server design a maximum size for each database. Why specify a maximum size for your database? As you saw earlier, specifying a maximum size gives you guidelines for distribution mailboxes and the maximum number of databases that your server must support. In general, there are a number of good reasons for limiting the maximum size of each database. Here are some thoughts and pointers on calculating maximum database size:

• Maximum database size when using streaming backups and restores should be around 50GB to 100GB.

• When using LCR as the primary database restoration mechanism, databases can be allowed to grow to 200GB.

• Always take into consideration the restoration time when calculating maximum database size and ensure that you can restore within a timeline specified by your service level agreement (SLA).

• Restoring from streaming tape backups can take significantly longer than restoring from backups on disk.

• Larger databases take longer for online maintenance procedures to run. Microsoft recommends online maintenance at least once every two weeks on each database for best performance.

One popular reason for limiting the size of a database or maximum mailbox sizes is the length of time it takes to restore a server. On one hand, this represents good planning, but often mail administrators wield that excuse like a sword in order to keep their user storage limits lower. An Exchange administrator commented one time that "keeping mailboxes smaller is easier on us," meaning the IT department.

Storage limits and maximum mailbox sizes are all fine and good, but limits should not be set for the sake of IT. You should set limits that allow users to effectively do their jobs and to access the information they need to access, but you should also consider the needs of operations, archiving, and budgeting. Also keep in mind that the default mailbox limit for mailbox databases is 2GB unless you change it, so make sure when you create new mailboxes databases that you also configure the correct limits. See more about establishing limits in Chapter 9, "Imposing Limits and Why."