Obliterate failing

asills · Post by **asills** » Sun Jan 30, 2005 12:09 pm

I just finished importing my VSS database to Vault (~2gb : 2 days) and one of the top-level folders failed so I deleted it and am importing it again. I figured I would permanently delete the failed top-level folder but every time I go to obliterate it, it tells me it can't connect to the database and to check my network connection.

I can connect to the server and database doing anything other than obliterate. When I choose even a single file to obliterate the SQL process jumps to ~50% CPU usage and the admin UI hangs for a while then reports that the server couldn't connect to the database.

I'm in the middle of importing again so I don't want to try the obliterate again, but I will later to see if the log file contains any info (it has nothing in it right now).

asills · Post by **asills** » Sun Jan 30, 2005 3:40 pm

So I guess to have a question in here, is the Obliterate feature really that slow or could something else going on? I'm running the admin tool from the server and everything else works perfectly except obliterate (the regular client works fine too).

The top-level folder I'm importing takes roughly 11 hours to import (that's it's current estimate) so it is pretty big so I understand obliterate taking a while, but come on, I need to obliterate the part of the import that failed (it had 1400 errors but obviously a good deal of it succeeded).

Post by **jeremy_sg** » Mon Jan 31, 2005 1:43 pm

Yes, obliterate is really that slow. Because there is so much history that was imported, it must go be very careful not to delete too much data. Can you check your Vault server log file to see if there is a problem there that is causing the obliterate to fail.

asills · Post by **asills** » Mon Jan 31, 2005 2:45 pm

Here is the exact error coming from the admin UI:

"The Vault server could not be contacted to perform the operation. Your network connection to the server may have been interrupted. Please verify your network settings using the Options dialog under the Tools menu in the Vault GUI Client."

Which I know to be crap, because before it I obliterated a folder with no history and after it I did the same thing.

There's nothing in the log but login attempts.

asills · Post by **asills** » Mon Jan 31, 2005 2:49 pm

Oh and that error message occurred before the normal "you are about to permanently delete XXXX" warning.

Post by **jeremy_sg** » Mon Jan 31, 2005 3:01 pm

If you're using a 2003 server, there may be a connection timeout occuring, which means that IIS would kill the client connection after a couple of minutes. You can get to this setting by opening the IIS manager, right clicking on Web Sites\Default Web Site (or whichever web site is running the Vault service), and choosing Properties. The Web Site tab will have the setting that you should adjust.

asills · Post by **asills** » Mon Jan 31, 2005 3:11 pm

Hm, I am using Win2k3, however did they change the meaning of connection timeout?

"Type a number in the box to set the length of time in seconds before the server disconnects an inactive user. This ensures that all connections are closed if the HTTP protocol fails to close a connection."

This should have nothing to do with a currently active request that's being handled.

Post by **jeremy_sg** » Mon Jan 31, 2005 3:18 pm

My experience is that by default, 2003 will kill any request that takes over 120 seconds, even if the web service or the database are hard at work.

asills · Post by **asills** » Mon Jan 31, 2005 3:19 pm

I set the connection timeout to 86400, and it times out after a minute or less (which means it wouldn't have been a connection timeout, since that was originally 120).

I have all the Vault timeouts set pretty high as suggested by the SourceSafe import suggestions.

asills · Post by **asills** » Mon Jan 31, 2005 3:21 pm

I'm not going to mess with the server any more today, I'm going to wait until night time tomorrow to fiddle with (so I can reboot it and do some other things) and double-check all the timeout values everywhere.

dan · Post by **dan** » Mon Jan 31, 2005 3:57 pm

There's additional info on Win2003 timeouts here:

http://support.sourcegear.com/viewtopic.php?t=1014

asills · Post by **asills** » Wed Feb 02, 2005 6:43 pm

Okay, I've officially set every single timeout to an incredibly high value (usually 24 hours). I rebooted the machine to make sure it was "clean" and I obliterated a test folder first and that worked fine. When I attempted to obliterate this specific folder (which by itself on disk is at least 200MB, but in history it probably accounts for 1/3 of the entire SQL database size of 6GB) it did exactly like it did before.

Unfortunately I didn't time it (and I can't at the moment because I can see SQL Server still working on the request) but it was roughly 2 minutes (give or take half a minute) and the error message was "the Vault server could not be contacted". SQL Server stayed at about 25% utilization for about 6 or 8 minutes and I got tired of waiting and just restarted it.

Does the admin tool have a logging component available to it? Is it at all possible that there's a client-side webservice timeout?

Post by **jeremy_sg** » Thu Feb 03, 2005 8:19 am

---Edited by jeremy_sg to remove potentially dangerous advice---

asills · Post by **asills** » Thu Feb 03, 2005 6:11 pm

Okay, well, the query is running and it's been 24 minutes. I rechecked IIS and the only timeout I hadn't set was the "ASP script timeout" which I wouldn't think would affect ASP.NET, but I set it to 24 hours anyway.

So now that I've run this query, is it safe to assume it creates its own transaction within the stored proc (since they're encrypted and I can't use Enterprise Manager to find out on my own)? If this thing takes 5 hours to run, I would like to be able to stop it without screwing anything up (which is why I ran it with "reallyobliterate=0" first just to see how long it would take).

asills · Post by **asills** » Thu Feb 03, 2005 9:19 pm

Okay well it took 3 hours, so now I know how long it'll take to actually delete it.