Video Screencast Help

Opinions on sizing of SQL databases in EV10

Created: 21 Feb 2013 • Updated: 26 Feb 2013 | 4 comments
KeirL's picture
This issue has been solved. See solution.


Just reviewing the SQL best practive guide - which I do from time to time :o)

And looking at the very comprehensive and somewhat complex formula's on calculating the disk size requirement for each database.

My question is really - 'Does anyone realistically utilise these calculations when designing an EV solution?'  or is it more the case of 'Let's create a, say 250GB, volume on fast disk for everything and keep an eye on it'  - obviously separating Logs and Dbs onto different spindles.....

So effectively base it less on the maths but more on the features (FSA, Email\Journal archiving, Sharepoint etc) and number of users (<1000, 1000 - 5000, >5000) etc

And which DB's should always exist separate from each other regardless of environment size etc

I'd be interested if anyone has any rules of thumb that they have found successful which requires less intial metrics than the best practice guide suggests.

many thanks

Discussion Filed Under:

Comments 4 CommentsJump to latest comment

GertjanA's picture

Hello Keir,

I see your a partner, you should have access to the Sizing Calculator from the Partner site. That is really cool (and usefull too) to answer these kind of questions. It all depends on amounts of mail etc. The sheet is very good in helping you establish needs, requirement and estimated future growth.

In general:

Directory database, Audit database, monitoring database, fingerprint database (or if you have multiple stores, more), at least 1 store database. If proper maintenance is being done on the logdb's, that can be about 500GB (is what we use, more than sufficient). SQL db's can grow, but that is 'see what happens'.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS

KeirL's picture


Thanks for the info and yes, I have seen the sizing calculator (which I agree is good) and also the EMA. It was when playing with the EMA that I starting thinking - "is it really worth it?"

It's very slow, quite invasive, takes time to set up and can impact performance whislt running - and if the client has several hundred GBs of available SAN storage (which I find that most do) do I really need to be that precise - could I just say "you've got 2000 active mailboxes and want Exchange email archiving and Journaling only so 300GB for SQL databases will be plenty"..... perhaps a bit simplistic? :o)

I guess it's all about the ingest rate - so if I were to look back at their Journal mailbox for the past 24 - 48 hrs then I'd get a good idea of that figure, and perhaps if it seems very high for the size of the company then do further investigation?

thanks again


GertjanA's picture

I agree on EMA. I assume (...) you do have experience on EV, and therefor can make an educated guess using the reprot data from the Journal Mailbox to estimate SQL size.

live example: :-)

Journaling approximately 2 to 3 million (000.000) messages a day. databases (we have 5 for legal) 185, 125, 42, 210 and 29GB, logdisks are150GB. 1 logdisk, 2 data disks (sql01)

Mail archiving (older than 30 days, and quota) approximately 800000 a night. Mail archiving 9 databases (62,61,66,64,27,52,22,18GB and 500MB (new), fingerprint is approx 70GB, 1 datadisk, 1 logdisk

Directory database is 1.7GB

Directory and Journal databases and monitoring and audit are on SQL01, mailarchivedb's on SQL02. Mirrored SQL servers.

Do take in account that working away the backlog might make sql logfiles grow quick. Best practice is to make sure you backup and truncate every 15 minutes.

Thank you, Gertjan, MCSE, MCITP,MCTS, SCS, STS

KeirL's picture

Wow! - 2-3 million messages a day is a far bigger environment then I'm ever likely to be involved in. Most of my customers are <250,000 and generally without legal compliance constraints

And if you can run that on 500GB then I should be fine saying 250GB for my average client :o)