how to analyze / fix vault database

grant · Post by **grant** » Tue Sep 27, 2005 5:41 am

i had bad stuff happen when importing into an already live database. i'm nervous about what effect this might have had on the database. eg admin tool now seems to be hanging (but i suppose that might be for other reasons). because we are alive already, i don't have the option to uninstall everything and start again from scratch. is there a tool (maybe akin to VSS's analyze -f) i can use to scan for / repair any errors that may have cropped up in vault?

Post by **jclausius** » Tue Sep 27, 2005 8:25 am

What version of Vault are you using? Since SQL Server is used as the back end, you won't see the type of corruption issues as seen in Vaisual SourceSafe. So, Vault doesn't really have an Analyze type tool.

Besides the Admin Tool's security rights slowdown (which was reported earlier - http://support.sourcegear.com/viewtopic.php?t=4712) do you have any other symptoms?

grant · Post by **grant** » Tue Sep 27, 2005 8:34 am

hi, i'm with 3.1.2. that admin tool slowdown issue is someone else. my one is here http://support.sourcegear.com/viewtopic.php?t=4768
i haven't had any further symptoms in server or client yet, but import attempts continue to fail.

Post by **jclausius** » Tue Sep 27, 2005 8:37 am

Obliterate. Ah yes. I see.

Obliterate is an extremely long operation. It has to remove all history of an item out of all versions of every folder where the object existed since the beginning of the repository. For now it just takes time.

We realize the frustration of people trying to obliterate and will be trying to improve performance in the next major release of Vault.

grant · Post by **grant** » Tue Sep 27, 2005 8:46 am

as i wrote back to dan, i don't think it is just a lengthy-operation thing that is going on there. i did not actually get as far as to start obliterating yet.

Post by **jclausius** » Tue Sep 27, 2005 8:57 am

We seem to use the same response as soon as the word "Obliterate" appears. Sorry about that.

The Admin tool will refresh the list on the change of the repository combo box. Is there possibly something in there triggering the "change" event? By chance have you tried the fill the obliterate list from an Admin Tool on a totally different machine?

Post by **jclausius** » Tue Sep 27, 2005 9:00 am

One other suggestion, if you can find a different machine, if possible, try to use one with only the 1.1 .Net framework installed.

grant · Post by **grant** » Tue Sep 27, 2005 9:01 am

aha! this is sounding good. thanks, i didn't even thing about the possibility of installing the admin tool on a second machine. i'm not at work now, but in the morning i will try doing that and see what happens.

grant · Post by **grant** » Tue Sep 27, 2005 9:08 am

sorry, i think i've taken this thread off on a detour. if you decide to move some of it over to the other one, ok by me.

grant · Post by **grant** » Tue Sep 27, 2005 8:56 pm

hi, thanks the admin tool issue seems to be sorted now. thanks also for the advice about the analyze tool. just one more question, though. is there something i should do after a failed import (eg. look for temp files to delete, kick VSS, reboot?) before trying to import again?

Post by **jeremy_sg** » Wed Sep 28, 2005 8:19 am

The import should clean up after itself as far as disk resources go, but you should make sure to delete and obliterate the failed import from Vault. One thing that hasn't come up yet is why your import is failing. Do you know? Have you looked at your # import log file?

grant · Post by **grant** » Wed Sep 28, 2005 4:41 pm

having an import log is a great idea. thanks for that. maybe can you add some pointers somewhere about how to read it? for example, i'm not sure where the logging for each file starts and finishes. (i wonder if the extra line of whitespace is not between files?) maybe also a collection of some tips for what to do when encountering various common errors?

about some of my errors (from the log excerpt below):

seems strange to see the "Invalid DOS path" error just once, because presumably the same DOS path is being used for all the other files that succeeded.

about checking available disk space: you've mentioned already that the import will clean up all it's temp files, so logging a suggestion to check disk space is maybe not so useful. how about get the import tool to programmatically check the available disk space on the appropriate drive at the time of the error, and then only issue a disk space message if the results indicate that disk space is truly relevant (add the space-check results to the log message, even)?

log excerpt:
Created ($/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe) at 2005/02/18 15:46:44
Change set type: AddFile
Unable to get $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe from the VSS Database.
Invalid DOS path: D:\Program Files\Microsoft Visual Studio\VSS\temp

**Failed** to Get version 1 of $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe to upload.
Checked in $/Component/F8ComponentsD7/F8Protect/Tools ($/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe) at 2005/03/05 16:26:58
**Failed**. File not found in tree: $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe Converting action to a ChangeSetItem_AddFile message.
Change set type: AddFile
Unable to get $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe from the VSS Database.
Invalid DOS path: D:\Program Files\Microsoft Visual Studio\VSS\temp

**Failed** to Get version 2 of $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe to upload.
Checked in $/Component/F8ComponentsD7/F8Protect/Tools ($/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe) at 2005/03/18 20:34:40
**Failed**. File not found in tree: $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe Converting action to a ChangeSetItem_AddFile message.
Change set type: AddFile
Unable to get $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe from the VSS Database.
SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.

**Failed** to Get version 3 of $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe to upload.
Checked in $/Component/F8ComponentsD7/F8Protect/Tools ($/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe) at 2005/03/22 13:34:24
**Failed**. File not found in tree: $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe Converting action to a ChangeSetItem_AddFile message.
Change set type: AddFile
Unable to get $/Component/F8ComponentsD7/F8Protect/Tools/F8Rus.exe from the VSS Database.
SourceSafe was unable to finish writing a file. Check your available disk space, and ask the administrator to analyze your SourceSafe database.

grant · Post by **grant** » Wed Sep 28, 2005 6:26 pm

oops. just realised that i bundled up 3 really great ideas into one message. hope that doesn't disqualify my post for the "Suggestion of the Day" award. is the prize still a single-seat licence for Vault? i can't seem to find the page anymore.

grant wrote:maybe can you add some pointers somewhere about how to read it?

grant wrote:maybe also a collection of some tips for what to do when encountering various common errors?

grant wrote:about checking available disk space: you've mentioned already that the import will clean up all it's temp files, so logging a suggestion to check disk space is maybe not so useful. how about get the import tool to programmatically check the available disk space on the appropriate drive at the time of the error, and then only issue a disk space message if the results indicate that disk space is truly relevant (add the space-check results to the log message, even)?

Post by **jeremy_sg** » Thu Sep 29, 2005 8:00 am

grant,

Did you make sure that the D:\Program Files\Microsoft Visual Studio\VSS\temp directory exists?

How much space is left on your D drive? VSS and the Import Tool will both write out temp files, so you need to make sure that there is lots of free space on the drives (or run the Import on a different computer with more disk space).

grant · Post by **grant** » Thu Sep 29, 2005 7:20 pm

jeremy_sg wrote:Did you make sure that the D:\Program Files\Microsoft Visual Studio\VSS\temp directory exists?

there truly is no D:\Program Files\Microsoft Visual Studio\VSS\temp directory.

so that's a cause of some of the failures? if this temp directory truly is critical for the import, maybe the tool could check for it programmatically before beginning the import? and either create it empty, or warn the user, if it's not found?

my candidate for today's "Suggestion of the Day" award: you might find other kinds of checks that might be useful to handle that way. do you sometimes get logs from people who have waited hours and hours, only to find out there is something simple that they could've rectified up front if only they had known?

jeremy_sg wrote:How much space is left on your D drive?

D: has 48Gb free.