Size of Vault SQL database vs VSS database

[rbrown13579]

Hi,
I am currently evaluating Vault Pro. Yesterday I created a clean repository in my Vault server (alongside two existing repositories). Using SQL Server Management Studio on the server I determined that the size of the sgvault database was approx 720mb at the time.

I then did a full import on a VSS database of size 638mb. Once this completed, I went back to the SQL management studio and saw that the sgvault database was now 1.8gb in size. So it had increased by approx 1.08gb.

Should I expect the same data to take up considerably more room in the Vault SQL database than in the original VSS database?

Regards

Richard Brown

[lbauer]

If the sgvault database was originally 720 MB amd you imported a 638 MG VSS database, then a 1.08 GB final size seems reasonable.

The sgvault database would grow by approximately the size of the VSS database being imported.

[rbrown13579]

Hi Linda,

Yesterday the final size was 1.8gb.

Since then I have created a new repository and imported another VSS database (VSS size 2.2gb).
The SQL database now stands at 7.49gb, an increase of 5.69gb.

This is not necessarily a problem, I am just surprised that it takes multiples of the space of the same VSS database. We are running the full version of SQL server, so the 10gb database limit with SQL Express does not apply.

I have just checked and all of our VCS databases combined come to around 37gb, so I estimate if I create repositories for all of these and do a full import, we may end up with a 100gb SQL database.

Do you think this is going to be a problem...? An option is VSS Handoff but we thought it better to get everything into Vault and make a clean break.

Thanks

Richard

[lbauer]

What size is the sgvault.mdf and what size is the sgvault_log.ldf?

Is there available free space in the .mdf file?

[rbrown13579]

Linda,

The sgvault.mdf file is 7.49GB and the sgvault_log.ldf file is 101MB.

I don't know if there is free space in the .mdf file, how do I check this? I have the default settings i.e. it is set to auto-grow by 1MB.

A lot of the files in our VSS databases are large binary files (20-50MB), but I am still surprised that Vault requires 2-3x the storage that VSS did...

Regards

Richard

[lbauer]

To see if there is unused space in the database:

Open SQL Server Management Studio.

Right-click on the sgvault database and select Tasks->Shrink->Files to see if there is unused space.
Don't make any changes just yet.

Also, run this query in SQL Management Studio.

Code: Select all

use sgvault
go
sp_spaceused tblfileinfo
go

[rbrown13579]

Linda,

I checked the free space using the 'shrink' command and found that 8565MB was allocated, and 49MB free.
Using the SQL query returned a value of 16MB unused space.

So it appears that the database is genuinely growing by 2-3x the space required for the same files in VSS.
Can you advise if this is normal? If not should I be worried by this?

Regards

Richard

[lbauer]

Could you provide me with the results of this SQL query? It might tell us if the space in the sgvault database is primarly for file content:

use sgvault
go
sp_spaceused tblfileinfo
go

[rbrown13579]

Linda

I have attached the result of the query.

Regards

Richard

[lbauer]

This looks like there are 1032 files or parts of file import into the file table, comprising 8.6 GB of data.

The partial files are the "diffs" between one version and the other. If you have 10 versions of a file for instance, Vault stores a baseline in the database, then a certain number of "diffs" or just the changes between versions before storing another baseline. Plus we compress the files. So the difference between the VSS size and Vault size could be the way we store the info, how big the diffs are, how much the files compress.

If your other VSS databases have similar file contents, they could also increase the Vault database size like this VSS database. Make sure you have enough disk space.

You might want to consider Handoff for any databases where history is not as critical (it still will be available, but in VSS).

Another option would be to archive off more recent versions of files in VSS, and import only the last X versions, rather than years and years of history.