SQL database size

[Rob_Walker_2]

According to my training literature from Symantec, EV should add about 240 bytes of data to the appropriate store's SQL database for each email or file archived. So far we're experiencing something in the region of ten times that. Is there some setting I need to tweak to reduce this?

[MichelZ]

Rob

Some sample Data from our own Environment:

EnterpriseVaultDirectory: 40 MB
EnterpriseVaultMonitoring: 190 MB
VaultStoreDatabase: 1.3 GB

Total number of items in Vault Store : 1'794'715
Total size of items in Vault Store : 228'860 MB
Average size of items in Vault Store : 131 KB

So, we have got 777 bytes per Element.

I don't think you can tweak this...

How many Elements have you got?


Cheers
Michel

[Rob_Walker_2]

I've got 621,000 files archived which total around 43GB. The corresponding SQL database is 1.829GB. The worrying thing is that it's running on MSDE as we were told for a site with around 100 users a seperate SQL server was overkill(!)

[Rob_Walker_2]

Just a little more info:

Total number of items in Vault Store : 621,155

Total size of items in Vault Store : 43,207 MB

Average size of items in Vault Store : 71 KB

[MarkB_2]

I don't think it is as easy as just dividing the amount of storage used in the partition and the number of items in the vault store. If you are using single instancing then this would mean sharing of DVS files. For instance you have 1 email sent to 100 users, single instancing would store 1 DVS file and update the Per User information, but each users would have a seperate entry in the database for their link to the DVS.

I have copied the text below from the EV7 performance guide, something which may help you correlate your figures?

Disk space used by vault stores

When an item is archived, it is first compressed and then metadata is added to it. As a general rule, the item is compressed to half its original size, and the metadata comprises approximately 5 KB. When an item is shared, only the metadata is added.

The following gives some general rules for estimating the amount of storage needed:

1. Halve the total size of items to be archived.

2. Divide by the average number of sharers (typically between 1.2 and 1.5).

3. Add 5 KB multiplied by the total number of items.

The compression ratio may vary considerably. Office documents tend to compress very well. Other document types, such as ZIP and JPEG files, are already compressed and cannot be compressed further. The rule is therefore to overestimate the amount of storage that you need. You must also factor in growth in the number of mailboxes and number and size of messages. Because of these extra factors, a more conservative method of estimating storage is to assume that space used by archiving equals the space used by Exchange in storing items.

Hope this helps!

[Rob_Walker_2]

Thanks for all the help. I've contacted support and it appears there's nothing wrong. File system archiving just uses more space in SQL. The info in plain to see in the documentation. It appears it has increased in EV 7 however which may be why it's bigger than we originally thought.

Anyone know any special offers on SQL licences :)