Today I was exporting a number of sub sites so that they could be imported as new site collections. After exporting the sites I used a batch file to delete them. For whatever reason (one that I'm not willing to admit to) I decided to <CTRL>C the batch file. This left the "Are you sure you want to quit?" message in the command window.

This resulted in a lock that prevented the web application from being able to render any sites in the content database. Given that this was a single site collection Intranet (this is why I have to move the non-publishing team sites into a managed path) it meant that nothing was working until I selectect "Y" to end the batch file!

Just as well I wasn't doing this on the production platform.

The other thing I wanted to confirm while testing this process was what areas would affect performance. Two key things I found were:

• Export – default is to compress the files, this uses %temp% as a temporary location for the uncompressed files before creating the file you specify in the command. I will be setting this to something other than the c: drive as my servers currently have 16Gb ram disks (upgrade to 32Gb is part of the server rebuild process I'm working on) for the boot partition which are almost full and I have some 5Gb sub sites to export.
• Deleteweb – requires SQL transaction log space = sub site size, even with simple recovery mode. Auto-grow for each document being deleted from a library was taking 300ms to 2 seconds each time (on a VMWare dev server with i-SCSI attached disk). Switching to simple recovery empties the log, then extend if required to match largest site being deleted.