Error Deleting Site Collection

When trying to delete a site collection, the following error pops up:

Command: stsadm -o deletesite -url http://servername/sites/sitename
Error: The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

An error like this prevents you from upgrading SharePoint aswell, because you won't be able to access the site collection either. I found out the hard way.

To resolve the error, detach and attach the content database of the afflicted site collection.
i.e.

stsadm -o deletecontentdb -databasename wss_content_name -url http://servername

stsadm -o addcontentdb -databasename wss_content_name -url http://servername

The resource cannot be found.

A user was complaining that he can't create a library or a list on his sub site. The library was indeed created, but when the user navigated to the library, i.e. /sites/sitename/listname/forms/allitems.aspx, then the error displayed was:

Server Error in '/' Application.

The resource cannot be found.

Description: HTTP 404. The resource you are looking for (or one of its dependencies) could have been removed, had its name changed, or is temporarily unavailable. Please review the following URL and make sure that it is spelled correctly. Requested URL: /xxxx/sitename/listname/forms/AllItems.aspx

This was strange, since the library was successfully created, and you could navigate to the library with SP Designer or with Site Settings -> Content and Structure. Looking into the ULS Logs showed that the site was configured to use a master page that did not exist anymore, e.g.

10/16/2009 11:25:00.34 w3wp.exe (0x10B0) 0x1920 Windows SharePoint Services General 8nca Verbose Application error when access /sites/sitename/listname/Forms/AllItems.aspx, Error=The file /sites/sitename/sitename/sitename/sitename/_catalogs/masterpage/default.master does not exist. at Microsoft.SharePoint.ApplicationRuntime.SPRequestModuleData.GetWebPartPageData(HttpContext context, String path, Boolean throwIfFileNotFound) at Microsoft.SharePoint.ApplicationRuntime.SPVirtualFile.CalculateFileDependencies(HttpContext context, SPRequestModuleData basicRequestData, ICollection& directDependencies, ICollection& childDependencies) at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureDependencies(HttpContext context, SPRequestModuleData requestData) at Microsoft.SharePoint.ApplicationRuntime.SPDatabaseFile.EnsureCacheKeyAndViewStateHash(HttpContext context, SPRequestModuleData re...

Navigate to Site Settings -> Master Page, will reveal the error as well, e.g.

The system master page setting currently applied to this site is invalid. Please select a new master page and apply it.

Fixed easily enough by choosing a valid master page.

DeadLock Detected Event 2262

Error in the Application Event Log:

Event Type: Warning
Event Source: W3SVC-WPEvent
Category: None
Event ID: 2262
Date: 2009/09/10
Time: 07:31:36 AM
User: N/A
Computer: XXXXXXXXXXXXXXXXX
Description:ISAPI 'C:\WINDOWS\Microsoft.NET\Framework64\v2.0.50727\aspnet_isapi.dll' reported itself as unhealthy for the following reason: 'Deadlock detected'.

Checking the SQL server revealed over 30 deadlocks on one content database. Every site in the affected content database was inaccessable. The rest of the sites on other content databases were fine.

While many different reasons could cause the Deadlock, such as third party applications running SQL queries on the content databases with the "No Lock", our problem seemed to be something else.

Further investigation showed that the SQL Server was not configured optimally. The server is 64bit SQL Server 2005 Enterprise. Things we checked and changed:

Make sure that AutoGrow on the Content Databases are set to more than 500MB. As well as the Log files AutoGrow is set to 500MB. IF the log file size increases over 10GB in one day then set the initial size to 10GB.

Max degree of Parallelism, check this blog: http://blogs.msdn.com/grahamk/archive/2009/06/15/troubleshooting-sql-server-deadlocks-and-performance-when-running-sharepoint.aspx

We set our servers Max Degree of Parallelism to 1.

Our server has 16GB Ram. SQL Max memory was set to 14GB, which left 2 GB for the OS and other applications. The number of worker threads in a 64bit environment is 576. Each worker thread requires 2MB of RAM. That equals 1GB of RAM just for the worker threads. AS I understand, if there is not enough memory available for the worker threads, then memory contention occurs.

This could create deadlocks, as some of the worker threads are waiting for the other worker threads to complete.

So, leave 2GB for the OS, 2GB for the worker threads, and at 2 GB for other Applications. So means you set the maximum memory for SQL to 10GB on a 16GB box in a 64bit environment.

All these changes definately increased our server performance.

The parameter is incorrect.

This error: "The parameter is incorrect.", is displayed in the crawl log of a content source. The result is of the error is the problematic site collection is not indexed. After researching the problem on the internet, it became evident that the site collection has an ACL list exceeding ~1000 users. See this blog .

Our problematic site had a lot of broken inheritance and a lot of SharePoint Groups. But I still wasn't sure that the ACLs exceeded 1000 users. So I wrote this little program to get the exact size of the ACL in the site collection:

try
{
using (SPSite _site = new SPSite(url))
{
try
{
IDictionary AllReusableAcls;
AllReusableAcls = _site.GetAllReusableAcls();
System.Console.WriteLine("Count of Values in ACL: {0}", AllReusableAcls.Values.Count);

foreach (KeyValuePair kvp in AllReusableAcls)
{
SPReusableAcl spRACL = kvp.Value;
SPBasePermissions spBase = _site.GetEffectiveRightsForAcl(spRACL);

System.Console.WriteLine(kvp.Key + ": " + spBase.ToString());
}
}
catch (Exception ex)
{
System.Console.WriteLine("Error: " + ex.Message);
}
}
}
catch (Exception ex)
{
System.Console.WriteLine("Error: " + ex.Message);
}

This confirmed my suspicion. There were 2383 keys in the ACL.

As the above mentioned blog propose, we had to reduce the number of keys in the ACL.

While reducing the number of keys in the ACL, as reported by the program, did not solve the problem, it could have compounded the problem.

Further investigation revealed a SharePoint user group with more than 6000 users. When a SharePoint user group exceeds 1000 users, then use an AD Group.