Video Screencast Help
Protect Your POS Environment Against Retail Data Breaches. Learn More.

EV11 Metadata Store Sizing

Created: 13 May 2014 • Updated: 13 May 2014 | 5 comments
Rob.Wilcox's picture
This issue has been solved. See solution.

Hi all,
 

Is it a typo in the documentation when it talks about 'sizing' the Metadata Store for Search / Mail Connect?

 

It says:

Typically the MDS cache will only take a short while to build, depending on the schedule of the Client Access Provisioning task and Index Administration task. MDS information can be added at ~2.5 million items per hour. By enabling MDS the Vault Store databases will grow. As mentioned earlier in this section it is only recommended that fast browsing is enabled for active archives that require IMAP or Enterprise Vault Search. For the purpose of sizing the additional storage required for the databases, if all archives were to be enabled with an Exchange Mailbox Vault Store, it is expected that the database size can grow up to 100% in size, depending on the type and size of the items archived.

 

Really? 100% grow in the Vault Store DB size?

If this is a clean install of EV 11, where provisioning of search policies isn't used (because on a clean install everyone gets the 'new search') does that mean that ALL archives have this feature enabled by default, and that all previous sizing considerations will now need to be double what they were before?

 

Thanks

Operating Systems:

Comments 5 CommentsJump to latest comment

JesusWept3's picture

well its estimated 750b per item right?
so looking at a test store i have, it has 44,666,642 items for a total space of 43,294MB
750b x 44m items equates to 31,948MB, which is a 75% increase in size

And obviously like they said, it depends on the items.and how many people you are converting right off the bat. im sure if you have just an email from me to you that just says hello with no attachments, it will be just fine, but if you have lots of emails sent to thousands of users with lots of attachments, the size would breach that number.

So I guess the optimal word in the documentation is "Could" grow to 100%

 

Rob.Wilcox's picture

Looking in the SQL Best Practices Guide ... maybe I'm not 'seeing it'.. but where is the 750 bytes per item coming from?

JesusWept3's picture

ok true, this was actually coming from the beta stuff, in the labs at vision the avg was 430b
but looking in another test environment in my lab, 118K items equated to 713B on average, but by far the biggest table was saveset content.

The thing is growing by 100% would really be on the conditition that the Journal* tables and the WatchFile tables are empty, which isn't going to be likely really but is possible

SOLUTION
Rob.Wilcox's picture

Coolio. I can see a future blog post in the making, thanks.