I've been in the process of transferring our VSS databases over into Vault. What baffles me is that sometimes the process proceeds rather quickly, but other times it's painfully slow. I transferred over a 9 GB VSS database in just over 10 hours, but now I've had a 2 GB database running for three days, and the utility is telling me I've got 42 days remaining.
At this point, it's spent well over a day transferring one file. The file does have 120 versions worth of history, and it is a 2 mb file. But still, it shouldn't take a day to transfer over 240 mb worth of data.
Now, it isn't like the Vault service is hung, because I can log into the other repositories just fine and with no noticeable performance loss. Likewise, I can get these files out of VSS quick as can be. So I'm a little perplexed here at just what the heck could be taking so long. Is there anything I can look at doing to try and speed this thing up?
VSS Import performance
Moderator: SourceGear
A few things to check:
If the VSS Import Tool is having a problem retrieving items from VSS, this could slow things down and also increase the use of system resources.
Look at the Import Tool. Does it appear to be reconnecting frequently to the Vault Server (every few transactions or even every transaction)?
Check the import.log file in the Vault Import Tool directory to see if errors are being reported, particularly *Failed* to get Version "x". If the VSS Import Tool can't get a particular file/version, it keeps trying -- maybe as much as 20 times. The Import Tool communicates with the VSS database through the SourceSafe automation component, which is sensitive to even minor database corruption.
If there's a file the automation component can't get, and the file has 120 versions and the Import tool tries 20 times it get each version -- you'll have a lot of activity with very few results.
Also, check the Vault Server log, sgvault.log in %windir%\temp\sgvault. It will show any errors on the Vault side of things -- failures to commit, duplicate object version errors (if you're trying to import over exising data), etc.
Check your system resources. Do you have enough disk space? A VSS Import, particularly one that's generating errors, can cause the sgvault_log.ldf file to grow quite large, especially if SQL is in Full recovery mode. Check the memory usage for SQL Server. Are you running out of memory?
Let us know what you find out.
If the VSS Import Tool is having a problem retrieving items from VSS, this could slow things down and also increase the use of system resources.
Look at the Import Tool. Does it appear to be reconnecting frequently to the Vault Server (every few transactions or even every transaction)?
Check the import.log file in the Vault Import Tool directory to see if errors are being reported, particularly *Failed* to get Version "x". If the VSS Import Tool can't get a particular file/version, it keeps trying -- maybe as much as 20 times. The Import Tool communicates with the VSS database through the SourceSafe automation component, which is sensitive to even minor database corruption.
If there's a file the automation component can't get, and the file has 120 versions and the Import tool tries 20 times it get each version -- you'll have a lot of activity with very few results.
Also, check the Vault Server log, sgvault.log in %windir%\temp\sgvault. It will show any errors on the Vault side of things -- failures to commit, duplicate object version errors (if you're trying to import over exising data), etc.
Check your system resources. Do you have enough disk space? A VSS Import, particularly one that's generating errors, can cause the sgvault_log.ldf file to grow quite large, especially if SQL is in Full recovery mode. Check the memory usage for SQL Server. Are you running out of memory?
Let us know what you find out.
Linda Bauer
SourceGear
Technical Support Manager
SourceGear
Technical Support Manager