120GB single mailbox database, should it be split into several smaller databases?

Not open for further replies.


Over the next two months we will be upgrading from Exchange 2007 to Exchange 2010. We have about 600 mailboxes and a single edb file that is 120GB. What is best practice for size of edb files? Should I split this into several smaller database files during the upgrade process? How many? Should I split it alphabetically, for example A-M and N-Z? We run two servers, a hub transport/mailbox server and a client access sever.


Best practice is to keep your DB's small enough to meet your SLA in a DR situation. The biggest problem with big databases is how long it takes to get it back online if you have to restore from backup. With multiple, smaller databases you can multi-thread your restore, and have stuff back up and running a lot sooner.[string](0..33|%{[char][int](46+("686552495351636652556262185355647068516270555358646562655775 0645570").substring(($_*2),2))})-replace " "


agree with mjolinor...if you are not running a DAG, then keep them small to meet your SLAs. With no DAG I like to keep them under 100 GB. As far as how to split them up, that is up to you. I have seen companies do the alphabet thing, I have seen randomized, I have also seen priority driven. Like, put all your Tier 1 MBs (executives) in the same database, that way if you have to restore, you can focus your efforts on Tier 1 databases first. There is no right answer.

Brian Day MCITP

With multiple copies we recommend up to 2TB per database.

As far as splitting it up, that is up to you. I wouldn't do it alphabetically because you'll probably never get them equally balanced.


AndyD_ [MVP]

Brian is referring to database availibility groups in Exchange 2010.
Not open for further replies.