VSS Import freeze

[lanemet]

Hello,

I'm trying Vault with demo licence.

I tried to import one of our VSS databases, first time with size ~2G.
It ran all night but in the morning I realized Windows was totally freezed. On the freezed screen I could see the import process stopped somewhere about 75%.

As a second try, I "purged" the VSS database so that it had ~500 MB. The same happened.

In each case no cause of freeze could be identified. Nothing special could be found in System log or SQL log. (I don't know how to check IIS log.) VSS Import tool logs are simply cut, no errors indicated. The second time I examined the result Vault SQL database size also, and it was only ~600 MB. So size propably is not a problem.

After this I carefully read your article titled "Tips for a successful VSS Import" and did the checks. I could find only 1 potential problem: in machine.config file responseDeadlockInterval was 3 minuted. (But to be honest I'm a programmer and not system guy so I might miss something.)

Now for the third time I set responseDeadlockInterval to 1 hour, and started an import on the 500 Mb database to a new repository.

I guess it will run all day, and maybe I can check it only tomorrow.

My config:
Win XP, SP3. 4 CPUs. SQL Server Express with update (SP2). IIS 5.1. VSS 2005 with service pack.
Vault and SQL server is on the same machine.

If you can give me any advise yet, please do so, because experimenting with VSS import is a very long process.

Thank you very much,
Laszlo

[lbauer]

What version of SQL Server Express are you using?

What is your SQL Server database size -- the size of the sgvault.mdf file? SQL Server Express has a database size limit of 4 GB.

If SQL Server database size does not seem to be the issue, then we would need to see the logs from the import and the Vault server log that covers the time of the import. If the current import fails or freezes again, zip up the logs and email them to support at sourcegear.com, Attn: Linda.

Please add a link to this post in your email.

[lanemet]

> SELECT @@VERSION
result:

Microsoft SQL Server 2005 - 9.00.3042.00 (Intel X86)
Feb 9 2007 22:47:07
Copyright (c) 1988-2005 Microsoft Corporation
Express Edition on Windows NT 5.1 (Build 2600: Service Pack 3)

If I remember correctly then the size of sgvault.mdf was not greater than 2.5 GB after the first two attempts.

Actually (VSS Import running, now approximately first quarter of job's been done) its file size is 2.8 GB. Server Management Tool reports 3.4 GB database size. This a little bit suprises me - too much for the 1/4 of the whole source code. I'm sure my second attempt (with the same 500Mb VSS databse) passed half of the import job.

After the second attempt I only deleted the repository but did not reinstall Vault server. Could that leave so much space allocated in SQL Server? Even it did I think that should be an already deleted space, taking up room in SQL server still. If it's the case I expect SQL Server re-allocates that for the current import, and size won't be a problem.

But maybe SQL server operates in another way - I don't know.

Tomorrow we'll see anyway.
Greetings: Laszlo

[lbauer]

When you delete something, SQL Server doesn't automatically shrink the database. You can shrink the database using SQL Server tools. Let me know if you need more details.

[lanemet]

This time I got a little further.
The Import seems to take its final steps, it's pinning the files - though very slowly: 5-6 files/minute.

Probably because the SQL database size is 6.9 Gb actually, albeit the sgvault.mdf is only 2.9 Gb. I attached a screenshot of the progress.

There are totally ~3900 pinned files in this VSS database, therefor pinning would take 10-13 hours - assuming that its speed is constant (5-6 files/minutes). From the VSS Import log I see that pinning started at 6:30 am (CET). It would end about at 16:30-19:30 (CET) consequently.

But I won't wait that, because the VSS Import log shows errors from 6:27 am (CET) continously. Errors appeared before pinning, in labeling phase already, I think because of full SQL database. I attahced an excerpt from log.

I will cancel the import now, and consider how to continue Vault evaluation for our company has at least 4-5 VSS databases having 1-3 Gb each.

I would like to suggest two improvements also:

1. In section "--Start over if the import fails" of article "Options for a VSS import": you should add advising to shrink SQL database before import (after deleting repository).
2. The Import Tool should handle a full SQL database somehow.

Greetings,
Laszlo

[lbauer]

Exception during label import $/med/PlanarInterview6 (SW231000-XXXX00-1.04.041.0080-P) : VaultServiceAPILib.VaultSoapException: 1103 : FailDBInsert
at VaultService.VaultService.BeginLabelQuery(Int32 nRepID, String strItemPath, Int64 nObjID, Boolean bGetRecursive, Boolean bGetInherited, UInt16 nObjTypeFlags, Int64 nRowLimit, Int64& nRowsRetrieved, Int64& nRowsRetrievedRecursive, String& strQryToken)

FailDBInsert means Vault is having a problem communicating with the database. I'd need a copy of the the Vault server log to know more. It's sgvault.log and is in %windir%\temp\sgvault on the server machine. If you want to troubleshoot further, zip it up and email to support at sourcegear.com, Attn: Linda. Include a link to this forum post.

On a brighter note, we've greatly streamlined the import process for Vault 5.0, due out later this year.

[lanemet]

Thanks, I'll send you the log.
Laszlo

[lbauer]

The latest import logs showed few errors, so we're still trying to determine whether there's a problem with Vault or the import machine itself.

HS: 215047

[augustandre]

Did you find a solution for this problem?
When I reboot my computer it works (not freezinng)

Thanks for help!

Aug.

[lbauer]

The import process was fine -- the machine was the problem. The user changed to a different machine and that worked.