Admin tool - Obliterate

[erik]

I have just finished my import from VSS to Vault (which took about 4days), now I need to clean it up a bit. The repository is quite big (The vault DB is about 14GB). Anyway I have deleted a couple of projects that needs to be destroyed, when I click on the Obliterate tab, the listbox starts to load all the deleted folders... The problem is that I waited about 30 minutes and it still was not ready. If I click on properties for the repository it shows that I have 4520 folders +16479 deleted folders. I think the problem is that you can't load that many folders into the listbox....

I need a solution on how to manage this, anyone that have a good solution for it ?

// Erik Törnquist

[jeremy_sg]

Unfortunately, you've stumbled across a part of Vault that is just slow. The large number of deleted items is slowing down Vault. If you're using version 3.0.6 or later of Vault, you could use the command line client's obliterate command to obliterate the data without having to list all of the deleted items.

[erik]

ok, I'm trying that one now... Anyway this obliterate seems to be very inefficient, I looked i the SQL Profile and it runs dbo.splistdeletedobjects thousands and thousands of times, looks strange to me since the project only contains a couple of file with no shares etc...

[jeremy_sg]

You're right, building the obliterate list in the obliterate pane is slow, because listdeleted items is being called once for each folder. It was written for the use case of only finding out the deleted items in one folder (triggered by the properties dialog on a folder in the main GUI client). I'll add your vote to the list of people who want this fixed in a future release.

[erik]

I have now tried the client's command line obliterate command, without any success. I tested it o a very slow folder, (4 subfolders, toal of 11 files) and most of the files only have 1 revision. This seems to be a 'quick and easy' thing to obliterate. Guess what happens ? It runs for a couple of hours, with heavy load on the sql server, and then boom an error message at the comman line saying that the connection to the server is lost, the operation timed out and success = no.

I hope that you can come up with a solution for this, since it's useless the way it is working right now.

// Erik

[jeremy_sg]

Erik,

Do you see anything that might be helpful in your Vault server log file?

Obliterate also obliterates any deleted items in a folder, and it's possible that a large number of your 16479 deleted folders are located in the folder that you are obliterating.

[Guest]

I don't find anything unusual in the logfile, just logins and logouts...
The folder im trying to obliterate does not have many deleted folders, it has been used very rarely.

On the other hand I don't know where all the deleted folders are coming from It seems to have something to do with the VSS import, since when listing folders there seems to be many many folders with the name VSSIMPORT.

[jeremy_sg]

The import will create lots of deleted items if there are folders and files in a label that have been deleted or moved in VSS since that label was applied When this happens, Vault will add the item, put it into the label, and then delete them in Vault. This is done so that the import can promise that the label in Vault matches what you would get if you downloaded the label in VSS.

Also, is that when listing deleted folders, showing history, or are VSSIMPORT items showing up in your tree?

[aedell]

Unfortunately, you've stumbled across a part of Vault that is just slow. The large number of deleted items is slowing down Vault. If you're using version 3.0.6 or later of Vault, you could use the command line client's obliterate command to obliterate the data without having to list all of the deleted items.

I just wanted to add that this is our experience with Obliterate - it is painfully slow (VERY painfully) Additionally, different errors pop-up too, some defined (like "can't delete such and such because it has a branch") and some .Net type errors (such as null object reference null errors and the like)... Lastly, pressing obliterate simply hangs our server for hours - and we are very wary of using it at all... I *hope* our database is in a good state after hanging during an obliterate.

FYI, we didn't import from VSS, but simply have used Vault consistently for two years, and thus have accumulated a lot of deleted files and folders that would do best to be obliterated...

[GregM]

You're right, building the obliterate list in the obliterate pane is slow, because listdeleted items is being called once for each folder. It was written for the use case of only finding out the deleted items in one folder (triggered by the properties dialog on a folder in the main GUI client). I'll add your vote to the list of people who want this fixed in a future release.

How about making obliterate a tree instead of a list? That way, you only have to list one folder at a time. If the user is looking to obliterate a specific item, they know exactly where to find it, and can avoid the cost of having to see everything that could possibly be obliterated anywhere in the respository.

[jeremy_sg]

Good idea. I'll post that as a feature request.

[erik]

The VSSImport folders only appears when I try to list deleted folders.

The treeview thing sounds like a good idea to me.

// Erik