How to deal with orphaned SharePoint sites

Copy from http://www.cjvandyk.com/blog/Lists/Posts/Post.aspx?ID=299

 

“in my case do all the step below cannot resolved , once do the step detach and attach db problem resolved” > keep track the nice step from

Cornelius J. van Dyk

 

Whatever causes it, orphaned sites in SharePoint can be a very painful issue to deal with.  One way in which an orphaned site can occur is when a STSADM command it terminated during execution because of a drop of your remote desktop connection.

If you are working with STSADM, be sure to configure your Remote Desktop settings in order to keep disconnected sessions alive.  Failure to do so, WILL cause problems for you in the future.

The toughest orphaned site I've ever had to deal with occurred during such a case.  The site was being restored from a STSADM backup.  The server's Remote Desktop settings were not set to keep the session alive and when a blip in the wireless network cause the connection to be broken, Windows simply killed the session causing the site collection to become orphaned.  This was evident when the restore command was re-attempted:

stsadm -o restore -url http://server/site -filename site.stsadm.bak -overwrite

Which returned this puzzling message:

Another site already exists at http://server/site. Delete this site before attempting to create a new site with the same URL, choose a new URL, or create a new inclusion at the path you originally specified.

This is a puzzling message because... didn't we specify the "-overwrite" switch?  Why yes we did!  So what is going on here?
OK, OK.  So the site is there and the "-overwrite" switch isn't working.  Let's just delete the site.  The following command is issued:

stsadm -o deletesite -url http://server/site

Only thing is, the site collection delete statement failed with the following error:

The system cannot find the path specified. (Exception from HRESULT: 0x80070003)

No problem you say.  Just use the -force switch with the deletesite command.  Doing that, the following command is issued:

stsadm -o deletesite -force -siteid 2a9fbc10-4a60-427b-8e6e-e1565d7e5796 -databaseserver sql -databasename Site_Content

Unfortunately, the response is not what you expected.  This is the error returned:

Database "Site_Content" is not associated with this Web application

Of course, the message would make sense if the database was not associated with the web application, but it was.  It is time for the good old orphan identification and handling swich... databaserepair
We begin by identifying the orphaned content.  We issue the following command:

stsadm -o databaserepair -url http://server/site -databasename Site_Content

As expected, the command dumps a bunch of orphaned content.  Time to delete the corrupted content so we can restore the site again.  Simply add the -deletecorruption switch thus:

stsadm -o databaserepair -url http://server/site -databasename Site_Content -deletecorruption

Once the corrupted content has been deleted, rerunning the command without the -deletecorruption switch yields a clean bill of health for our database thus:

<OrphanedObjects Count="0" />

Unfortunately, retrying the restore still fails by with the same "site exists" error.  This is where I had the idea to detach and re-attach the database to try and clear up the issue.  Two quick STSADM commands later thus:

stsadm -o deletecontentdb -url http://server/site -databasename Site_Content

and

stsadm -o addcontentdb -url http://server/site -databasename Site_Content

yielded:

Operation completed successfully.

Now retrying the restore thus:

stsadm -o restore -url http://server/site -filename site.stsadm.bak -overwrite

finally yielded the result we were looking for:

Operation completed successfully.

Hopefully this will help you get sticky orphaned sites handled quickly so you can move on to more important things!

Later
C