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

  • Thread starter HendersonD
  • Start date Views 654
Status
Not open for further replies.
H

HendersonD

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.
 
M

mjolinor

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 " "
 
T

TWHarrington

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.
 
B

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.

 
A

AndyD_ [MVP]

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