Sql orphelin

FORMATIONS SHAREPOINT

Les orphelins sous SharePoint

ATTENTION: L'utilisation de requêtes SQL sur les bases SharePoint n'est
pas supporté ! Il faut donc dans la mesure du possible éviter d'utiliser
cette méthode directement sur un environnement de production.
Autrement, il est fortement recommandé d'ouvrir un incident auprès
du support Microsoft et se faire assister d'un ingénieur support pour
réaliser cette opération sur un environnement de production, afin de
conserver ainsi la supportabilité de votre plateforme.

Table des matières
Introduction............................................................................................................................................. 3
Databaserepair : opération Stsadm (Office SharePoint Server).............................................................. 4
Description .......................................................................................................................................... 4
Syntaxe......................................................................................................................................... 4
Paramètres .................................................................................................................................. 5
Exemples .............................................................................................................................................. 5
Détecter un site orphelin ....................................................................................................... 5
Supprimer un site orphelin ................................................................................................... 5
ANNEXES :............................................................................................................................................ 6
Sharepoint Orphans Explained ............................................................................................................ 6
How to Clean Orphans from your environment................................................................................ 11
There are 2 essential types of content database orphans. ........................................................... 11
How to help prevent orphans. .......................................................................................................... 12
SharePoint Orphans and Twins - Gotta love the little guys .................................................................. 12
Orphaned Sites - Part 1 ......................................................................................................................... 14
1. What's an Orphaned Site? .......................................................................................................... 14
2. What do we know about what causes Orphaned Sites? ............................................................ 15
3. How do I determine if I truly have an orphaned site? ................................................................ 15
4. What we've done to prevent Orphaned Sites ............................................................................ 16
5. What we're doing to cleanup Orphaned Sites............................................................................ 16

MEG-JIC - Pierre Erol GIRAUDY

6. What NOT to do to cleanup Orphaned Sites. ............................................................................. 16
Orphaned Sites - Part 2 ..................................................................................................................... 17
Cleaning Configuration Database Orphaned Sites ............................................................... 17
Cleaning Content Database Orphaned Sites ..................................................................................... 18
Orphaned Sites - Part 3 ......................................................................................................................... 20
If you have a SharePoint Portal Server 2003 environment, you may also need the following: ....... 20
Comment nettoyer les éléments orphelins dans SharePoint Portal Server 2003 & WSSv2 ................. 21
Étape 1: détecter et supprimer des orphelins éléments dans bases de données de contenu Windows
SharePoint Services 2.0 ......................................................................................................................... 21
Pour utiliser l'outil de ligne de commande Stsadm.exe avec l'opération databaserepair pour détecter
et supprimer des éléments orphelins, procédez comme suit : ............................................................. 21
Étape 2: exécuter l'outil Spsadm.exe si vous exécutez SharePoint Portal Server 2003 ........................ 22
Étape 3: supprimer et puis rattacher les bases de données contenus sur le serveur virtuel ............... 22
Comment nettoyer les éléments orphelins dans SharePoint Portal Server 2003................................. 24


Introduction

Plateforme MOSS 2007 avec Service Pack 2 apporte une nouvelle commande STSADM
prévue justement pour répondre aux besoins d’éradication des orphelins : stsadm -o deletesite
-force -siteid "GUID du site orphelin" -databaseserver "MonServeurSQL" -databasename
"BaseDeDonneeContenantLeSiteOrphelin". C'est un sujet bien souvent ignoré ou très mal
connu (cf. un des articles de Renaud COMTE). Les orphelins sont réellement un danger pour
tout serveur SharePoint. Ce sont des objets de stockage de SharePoint comme une base de
donnée, une collection, un site web qui suite à certaines manipulations (mise à jour,
migration, suppression non maitrisés...) ont perdus toute relations avec des données dans les
bases de contenus et configuration SharePoint. Les données existent dans SharePoint mais
elles ne sont pas reliés, hormis si vous tombez directement dessus. Elles sont là mais noyées
dans la masse, invisibles de tous système de navigation mais bien présentes en terme de
volume. Le problème est que ces orphelins viennent bien perturber l'organisation et la
maintenabilité de vos fermes SharePoint. Souvent, leur existence vient tous troubler le jour où
justement vous avez à mettre en place des processus comme :

 un "split" de base de contenu
 des imports exports
 un resizing des bases
 gérer des problématiques de places ou de quotas
 une migration ...

Il faut donc traquer les orphelins, puis nettoyer les bases, donc export / rattachement /
suppression... Il n'y a pas de moyen simple de faire ces actions sur le serveur SQL dans les
bases, puis en lignes de commandes. Voir les liens suivants :

1. SharePoint Orphans Explained par Cory Burns 1.
2. Orphaned Sites par Keith Richie2 :

Orphaned Sites - Part 1



3. SharePoint Orphans and Twins - Gotta love the little guys par Joel Oleson
Technical Product Manager for Office SharePoint Server.

1
The post de référence avec schéma et script SQL.
2
Les explications et même les commandes STSADM.


ANNEXES :

Databaserepair : opération Stsadm (Office SharePoint Server)

Description

Détecte et supprime les éléments orphelins dans les bases de données de contenu de Windows SharePoint
Services. Dans certains cas, il peut arriver qu’une base de données de contenu utilisée par Windows SharePoint
Services soit endommagée et contienne des éléments orphelins. Ainsi, un document peut ne pas avoir de
bibliothèque de documents parent ou une liste peut ne pas avoir de site Web Windows SharePoint Services
parent. L’opération databaserepair détecte et répare les bases de données endommagées uniquement pour
les types d’éléments orphelins d’une base de données de contenu suivants :

 un site Web Windows SharePoint Services qui n’a pas de site Web Windows SharePoint Services
parent ;

 un sous-site Web qui n’a pas de site Web Windows SharePoint Services parent ;

 une liste qui n’a pas de site Web Windows SharePoint Services parent ;

 un document qui n’a pas de bibliothèque de documents parent ;

 un élément de liste qui n’a pas de liste parent ;

 une page Web qui n’a pas de site Web Windows SharePoint Services parent.

Remarque :

Cette opération ne répare aucun autre type d’endommagement de base de données.

Syntaxe

stsadm -o databaserepair

-url <nom de l’URL>

-databasename <nom de la base de données>

[-deletecorruption]


Paramètres

Nom du paramètre et
forme abrégée Valeur Obligatoire ? Description

url URL valide, telle que Oui Nom d’URL de l’application Web
http://nom_serveur en cours de réparation.

databasename (dn) Nom de base de données Oui Nom de la base de données de
valide, tel que « BD1 » contenu qui doit être réparée.

deletecorruption <aucune> Non Supprime l’endommagement
d’une base de données de
contenu.

Exemples
Détecter un site orphelin

Pour détecter des éléments orphelins, utilisez la syntaxe suivante :

stsadm -o databaserepair -url http://<URL_du_site_WindowsSharePointServices> -databasename
<nom de la base de données contenant l’élément orphelin>

Supprimer un site orphelin

Pour supprimer des éléments orphelins, utilisez la syntaxe suivante :

stsadm -o databaserepair -url http://<URL_du_site_WindowsSharePointServices> -databasename
<nom de la base de données contenant l’élément orphelin à supprimer> -deletecorruption



ANNEXES :

Sharepoint Orphans Explained
What are Orphans in SharePoint?

Orphans have been coined the name for objects in a SharePoint schema that live without a parent or
child relationship in the database. In effect these database inconsistencies can be created due to many
different reasons. They cause confusion, helpdesk tickets and can cause your upgrade from wss2.0 /
sps2003 to MOSS 2007 / wss3.0 to fail. We will explore some of the ways these can be created, how to
locate them, methods for resolving orphans and a few key things you can do to help avoid them in the
first place.

In order to really understand orphans we need to understand a high level overview of how SharePoint
configuration databases and SharePoint content databases interact.

Figure 1.1 Configuration Database Content Database relationships

Orphans come from a host of different reasons. Unfinished create and delete transactions being the main
source. In SPS2003 if you were to create a new SharePoint site and click back, or close the window in
mid creation it would essentially stop where you clicked back. More often than not it would not roll back
the transaction or clean it in any shape or form, a very sloppy end to a standard task in SharePoint. This
in turn creates a Surface orphan. For the sake of this entry any site level orphan
(content>config/config>content) we will refer to as Surface orphans.


Figure 1.2 Surface Orphans

Another source of orphan creation is actually caused from farm maintenance. Any farm running a
mysitehost should proceed with caution while performing database maintenance. MySitehosts are root
portals that automatically provision a new site collection to a user when he/she visits the portal for the
first time. This can be very handy for on-boarding new employees etc. This can be a huge nightmare for
the operations team which supports the mysitehost. In SharePoint if you move a database from 1 SQL
server to another it requires you to detach the database from the Farm Admin GUI and reattach using
the new SQL instance name. The huge problem with doing this while the farm is accessible by its users is
the fact that once you remove that mysitehost database from the admin GUI that mysite host no longer
has entries for any site in the content database you are migrating. Thus any user that visits your mysite
host that has a site in the content database being moved will automatically be provisioned a new site.
Once you reattach that database in the Admin GUI it will repopulate all of its configuration database
entries. However if a site had been created with a same URL while that database was not attached, it will
skip that site collection as one already exists. Thus you have another surface orphan. This causes a great
deal of confusion from a customer standpoint.

Let’s step back and view this from the customer/user.

Monday – I visit http://mysitehost and my site is created, I add new documents, NEO information etc….
Throughout the week I update my Documents all is well.

Friday 7pm-11pm - the IT Team performs maintenance on mysitehost_database_1 they are migrating it
to another SQL server. It just so happens that my site lives in mysitehost_database_1, this migration
consists of the IT Team detaching the database from the FARM while it is in transit.

Friday 8:30pm – I the unknowing user to this maintenance visit http://mysitehost, since the content
database which contains my site has been detached from the farm it does not know of its existence. It in
turns creates a brand new site for me at http://mysitehost

I notice all of my documents I have been working on all week are missing; I file a restore request to
helpdesk to retrieve my documents.


Are the documents really gone? Nope, they are in that database being migrated. However SharePoint
now has a new entry in that darn configuration database for this same site. When the IT Team at
11:00pm reattaches mysitehost_database_1 to the farm it will not write an entry in the configuration
database to point to this week old site. It already exists right!? We just created a new one 2.5 hours
ago… Thus a new surface orphan.

Below is a 3 step story board showing this visually.

Phase 1 Before Database Migration

Phase 2 During Migration


Phase 3 End result.

Now imagine that your company of 5000 employee’s all have their mysite host site living on 2 databases.
I think you start to get the picture, if even 100 users visit their site while the migration is underway of 1
of those databases that’s 100 helpdesk tickets and 100 new orphans in your farm.

Alas, there is a bit of light throughout this dark tunnel with these different types or orphans. You can
reverse the process. It is neither pretty, nor fun for the IT Team  but it is possible. And most
importantly it is preventable for the most part.

How to find Surface Orphans

So you have orphans, before we can fix them we need to find them!

You can only detect orphans through SQL, there is no real out of the box way to detect them from the
web UI. That’s ok SQL is fun anyway  Into SQL we go. To use the following script all you require is an
open Query window with read access to all databases within your farm. The following script assumes you
run all of your databases on the same SQL instance. This script is an example for finding orphans
in MOSS 2007/WSS3.0

PS. I am not a SQL Guru

ps#2 Use these SQL scripts at your own risk, even querying the database is not supported!


Use MSDB
Drop table orphanlist

CREATE TABLE [dbo].[orphanlist](
[farm] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[databasename] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[SiteID] [uniqueidentifier] NULL,
[sitepath] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,
[type] [varchar](250) COLLATE SQL_Latin1_General_CP1_CI_AS NULL
)

drop table orphan_hopper
declare
@dbname as varchar(250),
@cmdstr as varchar(2000),
@dbid as varchar(250),
@configdb as varchar(250)

/** only change the following line and nothing else, change spskills_config_db to your config db name
**/
select @configdb = 'spskills_config_db'

/** Change nothing below this line **/
select @cmdstr =
'select distinct b.name as ''databasename'', b.id as ''dbid'' into orphan_hopper
from
[' + @configdb + '].dbo.sitemap as a inner join
[' + @configdb + '].dbo.objects as b on a.databaseid=b.id inner join
[' + @configdb + '].dbo.objects as c on c.id=a.applicationid inner join
[' + @configdb + '].dbo.objects as d on b.parentid=d.id inner join
[' + @configdb + '].dbo.objects as e on d.parentid=e.id '
exec (@cmdstr)

DECLARE DBCursor CURSOR For
Select databasename, dbid
From orphan_hopper

OPEN DBCursor
FETCH NEXT FROM DBCursor into @DBName, @dbid

WHILE @@FETCH_STATUS =0
BEGIN
INSERT INTO orphanlist([Type], farm, databasename,[sitepath], SiteID)
EXEC
('
select ''Potential ConfigDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm],
'''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap
where id not in (select id from ['+@dbname+'].dbo.sites) and databaseid = '''+@dbid+'''
union
select ''Potential ConfigDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm],
'''+@dbname+''' as [databasename],path as [sitepath], id as [SiteID] from ['+@configdb+'].dbo.sitemap
where id not in (select siteid from ['+@dbname+'].dbo.webs where parentwebid is null) and databaseid
= '''+@dbid+'''
union
select ''Potential ContentDB orphans:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm],
'''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from
['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from
['+@configdb+'].dbo.sitemap where databaseid = '''+@dbid+''')


union
select ''Potential ContentDB orphan:'' + '''+@dbname+''' as [Type], '''+@configdb+''' as [farm],
'''+@dbname+''' as [databasename],fullurl as [sitepath], siteid as [SiteID] from
['+@dbname+'].dbo.webs where parentwebid is null and siteid not in (select id from
['+@dbname+'].dbo.sites)
')
FETCH NEXT FROM DBCursor into @DBName, @dbid
END
CLOSE DBCursor
DEALLOCATE DBCursor

select * from orphanlist

Running this script will give you ConfigurationDatabase, ContentDatabase, SitePath, SiteID and Potential
Type of orphan(contentDB or ConfigDB). Wonderful now we have a list of items to clean!

How to Clean Orphans from your environment.

(Be smart have backups prior whenever you are performing maintenance on your
farm, use suggestions at your own risk.)

Configuration Orphans: These are the orphans that reside in your configuration database but have no
child counterpart (contentDB entry). Cleaning these are the easiest of all the orphans. Simply detach
the content database from your farm that was included in the result set and reattach it. This will refresh
the sitelist that is tied to that content database and will remove the stale entry.

Content Database Orphans: This is where it gets tricky.

There are 2 essential types of content database orphans.

Type 1

Scenario (reactive maintenance): Your site that has the content you need is not mapped to the
configuration database but resides in a content database that is connected to the farm, additionally a
blank new site is mapped to the configuration database. This would hold true to the second scenario
explained above. To resolve this simply backup the site that is accessible, then delete it. Once done
detach and reattach the database that contains the real site. This will remap the site to the configuration
database. You now have access to a once orphaned site and all of your content is restored.

Type 2

Scenario (Planned Maintenance): The correct site is mapped to the configuration database, however you
have stale orphans in other databases. Simply backup your production site and delete it. Once that
completes detach and attach the database that contains the stale orphan, this will in effect map the
orphan to the configuration database and render it accessible. You can then delete it using


STSADM. Perform these steps until you have cleaned all orphans. Once all orphans are clean you can
then restore your production site back into the farm. Viola, orphan free :)

How to help prevent orphans.

- User Education

Remind users that creating and deleting a site can be a sometimes several minute process. Regardless
of how long it takes let the application finish what it is doing. If it times out then try again but never
click back, stop, or close the window when performing these types of administration tasks. Network
Latency, Web front end performance and SQL backend performance can all attribute to a slow create or
delete statement. Be patient :).

- Operations Maintenance

When performing maintenance to a database where you are taking it offline for any reason consider it a
good practice that if possible takes the entire portal offline. Even though you may be only working with
a small fraction of the farm you could potentially be creating a lot more problems than you realize. If
you are not able to bring down the entire portal a suggestion to alleviate the potential for orphans it to
leave the database attached to the farm UI while it is in transit / detached from SQL. The user will then
get a "Cannot connect to database error." Rather than being able to create a potential orphan. Then as
your last step for the migration perform the detach/attach in the admin UI very quickly limiting the
possibility for orphan creation.

SharePoint Orphans and Twins - Gotta love the little guys

So as not to confuse... I'm referring to orphans in WSSv2 & SPS 2003. Keith's blog and tool
are the best out there for now. Keith refers to a fix that's coming in his blog. I'll post info on
that as soon as I can.

I've had some threads with some PSS folks lately about our issues we had with orphans in
Microsoft IT. I also ran into someone last week at Tech Ed that described this scenario this
blog covers. One scenario that wasn't given much attention was an orphan problem I liked to
call the dupe orphan problem. It really doesn't become a problem until you're trying to solve
other orphan problems or when you drop your config db.

Before I go deeper on the orphan problem let me describe an orphan. There are two type of
orphans, 1) they are entries in the config db with no correlation to the site table in the
site/content database or 2) entries in the site/content database that have no entry in the config
db.

Early on, and likely in KB articles you may still be able to locate, you would be told to drop
your config database and re-add your content databases. This works well to create entries in
your config databases for the entries that are in your site database creating a relevant entry in
the config db for all sites in the content db. Seems good enough right. Works too.


So if you've got orphans of type 1, they go away when you create the new config db. If
you've got orphans of type 2, you assume they will show up with the new config db.

Before you run off and drop your config db and create a new one and re-attach all your
content dbs, let me give you a few warnings...

1. When you run stsadm to add your web parts including the plus pack... they are entries in
the config db
2. More obvious things like email server are server topology are stored in the config db.

One thing that we found as well is orphan twins. These new orphans that have entries in
multiple content databases. Sometimes they actually both *need* to exist. For example. I
create a site called foo. Down the road I want to branch it off to create a copy of the content
and take it a different direction. I ask the SharePoint guys to backup and restore it with a new
-url. This will fail if there's only one content database. With 2 content databases, it works. I
now have two sites with the same content. Behind the scenes I have an entry for each site
looking exactly the same in the 2 content databases and my config db has it sorted out by
using 2 different URL path or site names. We've seen the same thing with restores. User
says, hey I want this list back. We happen to have an old stsadm backup of the site, so we
restore it to the farm, it goes to a different database and we plan to delete it when they say,
hey I've got it. That's how you create the problem of twins (two sites with same data (GUID)
in 2 different content databases belonging to the same farm (same config db). Not yet a
problem... but we'll see what happens.

They may both be valid sites, or one may be a copy in time. Both become issues if you
happen to drop your config db to fix orphan issues. In fact now, you have new orphans. With
your new config db, only 1 of the sites wins. In my experience, the last content db to be
added knocks out any site with the same URL / GUID in the content db. So, if this happens to
be the site that was a copy in time from an old restore, your users freak! What happened to
my site? This one is old. You look in the config db and it looks right. You look in the
content db and see it looks valid. But then you look in other content databases and find the
right one. Great! How do I get this one in the config db, or in the case of the branching...
how do I get both online at the same time?

Let's start with. I'm reading this blog and want to make sure I don't have any "twins" that
shouldn't belong. Let's take the case of 1 should only be the real one. From a UI stand point
if you're off hours you can create that new config db and one by one add the content databases
and delete the sites that shouldn't belong. Keith Richie's SPSiteManager has the ability to fix
orphans. Be careful that you don't delete a valid site that's become an orphan through this
process. The orphan can come back in the family if he needs to belong by having the
database be disconnected and reconnected. Having two sites belong at the same time is a
trick. You'll have to carefully add a database then rename the site to it's renamed name. So
pick the content db of the one that was renamed first and deal with it first. Then attach the
database that was owning the original name. Sound confusing? Even though you may
have been counseled not to backup your config db. I say, it's not a bad idea. 2 cases. 1) You
have a full catastrophic failure... boom you got everything you need to restore your
database. 2) You have orphan problems or this twins or triplets problem and want to know
which one was the live one, and which ones were attached with what GUIDs in which content
db. Believe me your users won't know which database their "real" site was living in.


Best Practice... Lesson out of all this....

1. Don't allow site collection restores within the same farm - believe me you may forget to
delete the restored site
2. Don't allow renames without deleting the original site.
3. Don't make copies of sites within the same farm as "templated" or branched. For copy
requests create an .stp. Save the site as a template. Understand this has a 10 MB limit, so
make sure your users that are trying to create site templates understand that if they want to
have some content in their templates they don't pass this up. Making backup and restores
within your content dbs is not a valid way of creating "templated sites".


There's been a good deal of action around the whole issue of Orphaned sites
recently, so I wanted to take some time and provide you the following information in
regards to this problem.

1. What's an Orphaned Site?
2. What do we know about what causes Orphaned Sites?
3. How do I determine if I truly have an orphaned site?
4. What we've done to prevent Orphaned Sites
5. What we're doing to cleanup Orphaned Sites
6. What NOT to do to cleanup Orphaned Sites

DISCLAIMER: This post shows using Query Analyzer to query data in your
SharePoint sites. By no means does this mean that you should change any
thing in the database. This is simply for "READING" values. And even this
should be done during Off-Peak hours.


An Orphaned Site is where SharePoint only has partial information and not a
complete set of data for a given site collection in your Windows SharePoint Services
or SharePoint Portal Server content databases or configuration databases. The site
may in fact still be viewable via the browser, but you may notice that many things are
broken. 99% of the cases I have seen though, the orphaned site is just unavailable.

You may notice you have an orphaned site via the following operations:

1. STSADM -o restore fails to restore the site, even with the -overwrite option when you
know the URL exists.
1. You may receive an error code 0x80040E2F
2. 0x80040E2F means “Violation of PRIMARY KEY constraint”, this equates to
STSADM already finding previous rows in the database for the items it's trying
to restore.
3. STSADM first looks at the Configration and Content Databases to ensure that
the site does not already exist, and if so (And you didn't use the -overwrite


switch) it would bail out, but if it does not find this information, it begins
restoring...Then runs into the problem noted above.
2. STSADM -o deletesite fails to delete the site
1. You may receive and error which states "The site does not exist"
2. Same thing. No site information in Configuration or Content database in their
respective Sites tables. Thus the other remnants of the site cannot be
cleaned up.


We have only found two identifiable causes for Orphaned Sites.

You cannot restore a Windows SharePoint Services Web site when the number
of sites reaches the warning limit
You expect that you can restore a Windows SharePoint Services Web site until the
number of sites reaches the maximum limit. The maximum limit is specified in
Maximum number of sites that can be created in this database. However, you cannot
restore a Web site when the number of sites reaches the warning limit. The warning
limit is specified in Number of sites before a warning event is generated. When you
try to restore a Web site and the number of sites reaches the warning limit, you
receive the following error message:

The content databases in this cluster have exceeded the warning Web site count.

Either change the content database Web site capacity settings or add more content
databases

You interrupt an STSADM -o restore operation, or the operation is interrupted
by other non human interference :)


Consider that you have a theory that your site collection at
http://yourserver/sites/coolstuff is orphaned. The quickest way to determine this is as
follows:

Use a query tool (Such as SQL Query Analyzer or OSQL) to run the following query
on the Configuration Database in your SharePoint farm.

select * from Sites where UrlPath LIKE '/sites/coolstuff'

If this returns data, then the Configuration database does have information about
your site. Proceed to next step.

Use a query tool (Such as SQL Query Analyzer or OSQL) to run the following query
on the Content Database in your SharePoint farm.

select * from Sites where FullUrl LIKE
'%/sites/coolstuff'



Notice that this URL string has the mask character at the beginning (Because we
store absolute URLs)
If this returns data, there should be sufficient information for a STSADM -o deletesite
to work properly to delete your site. i.e., you don't have an Orphaned Site.

If you get results from querying the Configuration Database but not the Content
Database then you have a Configuration Database Orphaned Site.
This is the easiest to clean up. Simply visit the Managed Content Databases page in
the Windows SharePoint Services UI and remove the content database. Then just
re-add it back in.

This cleans up the entries from the Configuration Databases' Sites table. This is
because the Column “DatabaseID” in this table refers to the Content Databasethat
the site belongs to. When you remove the Content Database from the Virtual Server,
we clean up all entries related to that DatabaseID from the Configuration Databases'
Sites table.

If you get results from querying the Content Database, but not the Configuration
Database, then you have a Content Database Orphaned Site.

This is not so easy to clean up :). See Section 5 :)


The good news, is that we've already completed and released work to prevent this
problem in the future and these fixes are included in the Windows SharePoint
Services SP2 update.

See http://support.microsoft.com/?id=906336 for more information.


We are currently working on a fix (it will probably show up as a new STSADM
operation) to clean up these orphaned site entries. We're certainly aware of this
issue, and the importance of it. I would say we're probably still a month off from the
date of this posting before we'll have the official hotfix ready (Lots of testing)

In the mean time, I'll be detailing how to clean up the orphaned site issue in my next
post titled "Orphaned Sites - Part 2".

6. What NOT to do to cleanup Orphaned Sites.

Whatever you do, do NOT PERFORM DIRECT EDITS TO THE SHAREPOINT
DATABASE.

 Do NOT manually update records
 Do NOT manually insert records
 Do NOT manually delete records


 Do NOT MODIFY SHAREPOINT DATA!!!

A perfect example of this, is when I saw the numerous posts where folks were just
doing direct edits to the UserInfo table when the users account was migrated
between domains. They'd go in and just update the SID directly for the users record
in the UserInfo table. They said "Hey this is all that's needed, it works great!!!"

Well, surprise guys...You just created a security hole if your using
search. Why? Because we store the ACL for the webs, etc in the indexes to do
proper security trimming :) If you changed the SID information directly, then we
CAN'T do proper security trimming on any indexes that are not updated yet. The
indexes will never be updated properly until you go into the SharePoint UI and
change the security settings on the web because the web was not updated to a dirty
state.

Of course our Developers knew this when they created the MigrateUser APIs to mark
the web as "Dirty" so that the indexer will re-crawl the security information for proper
security.


In my previous post "Orphaned Sites - Part 1" I detailed the following points:

6. What NOT to do to cleanup Orphaned Sites

In this post, I'll detail the steps needed to cleanup after an orphaned site problem

DISCLAIMER: This post shows using Query Analyzer to query data in your
SharePoint sites. By no means does this mean that you should change any
thing in the database. This is simply for "READING" values. And even this
should be done during Off-Peak hours.

Cleaning Configuration Database Orphaned Sites

This is definitely the easiest type of orphan to clean up as all you need to perform is
basically removing and re-adding the Content Database that the Configuration
Database an entry for. When the content database is removed from the virtual
servers list of content databases, clean up logic is performed to remove the entries
from the Configuration database. You then simply re-add the content database back
in, and the sites from the content database are re-added to the configuration
database.


Here are the steps:

1. Use a query tool (Such as SQL Query Analyzer or OSQL) to run the following
query on the Configuration Database in your SharePoint farm to get the
information about the Orphaned site that we have.

SELECT * FROM Sites WHERE UrlPath LIKE
'/sites/coolstuff'

In the results from this query, you'll notice the DatabaseId column. This
column contains the GUID of the content database that is "supposed" to have
the site.
2. Query the "Databases" table to get the name of the Content Database

SELECT * FROM Databases WHERE DatabaseID = '{FB038985-
874B-4C10-BCBD-DED638B30B71}'

In the results from this query, get the name of the database from the Name
column. This is the name of the content database you want to remove and re-
add from the virtual servers list of content databases
3. You could of course use a join query to get the name for you, such as the
following:

SELECT d.Name FROM Databases d, Sites s
WHERE d.DatabaseId = s.DatabaseId AND s.UrlPath LIKE
'/sites/coolstuff'
4. Once you have the name of the database to remove, then proceed with the
following:
1. Visit the Windows SharePoint Services Central Administration page
2. Select Configure Virtual Server Settings
3. Select the appropriate virtual server
4. Select Manage Content Databases
5. Select the database identified by Steps 1-3.
6. Make note of the Database Server, Number of sites.... and Maximum
number of sites... settings
7. Choose the Remove content database check box and choose ok.
8. Choose Add a content database from the Manage Content Databases
page
9. Populate the appropriate information back in that was noted from step 6.

Your Configuration Database Orphan is now gone.

Cleaning Content Database Orphaned Sites

This cleanup method is definitely not the most trivial, and extreme care should be
taken before executing. In other words, be sure to have a complete backup of
everything before performing these steps.

In order to have a clean Content Database without any orphaned entries, you
basically have to move all the "Non-Orphan" sites into a new content database, then


remove and delete content database with the remaining orphans. In other words,
you have to re-partition the good sites into different databases.

In order to repartition Site Collections in and out of content databases you have to use the
following steps:

1. If you have not done so already:
a. Create a new content database to place the backed up site into.
2. STSADM –o backup (to backup the site collection to disk)
3. STSADM –o deletesite (To delete the site from the current content database)
4. Visit the Content Database management page from the Windows SharePoint
Services Central Admin pages.
a. Select the First content database and either:

i. Set it’s status to Offline or

ii. Set it’s max-sites and warning-sites counts
to that equal to the number of current sites in the content database (Be
sure to have a notebook handy to write down all of the original values
so that you can re-set them in a later step.)

b. Repeat step 4.a for each content database EXCEPT the one you are restoring
to (This prevents the WSS Logic from load balancing the existing content
databases, to determine which content database to restore the site in)
5. STSADM –o restore (restore the site into the new targeted database)
6. Visit the Content Database management page from the Windows SharePoint
Services Central Admin pages.
b. Select the First content database and either:

i. Set it’s status back to Online (If it was
online to begin with) or

ii. Set it’s max-sites and warning-sites counts
to their previous values (refer to the notes taken in Step 4.a.ii)

b. Repeat step 6.a for each content database
7. Repeat steps 2-6 (unless you need to create more content databases, in which case
you restart at step 1).

As you can see this is a very labor intensive and time consuming process. If you had to do
this for many sites, although you could be smart, and handle a batch of sites steps 2, 3 and
5, it becomes impractical to do all of this manually.

As an aid to doing just this task, I wrote SPSiteManager which is located in the
SharePoint Utility Suite located here:

http://www.microsoft.com/sharepoint/downloads/components/detail.asp?a=724

This is of course an unsupported tool by PSS, but I'm am always open to taking
direct email to assist with the tool.


Give it a look-see, and remember..Before doing anything so en-masse, be sure to
take a complete backup of your environment.

And of course, remember we are working on a STSADM extension to allow you
to clean up orphaned sites, and WSS SP2 prevents them in the future.


Finally, the Orphan Repair extensions to STSADM are complete:

For WSS Alone:

Description of a new command-line operation that you can use to repair content databases in
Windows SharePoint Services
http://support.microsoft.com/default.aspx?scid=kb;EN-US;918744

If you have a SharePoint Portal Server 2003 environment, you may also
need the following:

Description of a new command-line operation that is available for the Spsadm.exe command line tool
that you can use to clean up orphaned items in the configuration database in SharePoint Portal Server
2003
http://support.microsoft.com/default.aspx?scid=kb;EN-US;918742


Comment nettoyer les éléments orphelins dans SharePoint Portal
Server 2003 & WSSv2

Étape 1: détecter et supprimer des orphelins éléments dans bases de
données de contenu Windows SharePoint Services 2.0

Pour utiliser l'outil de ligne de commande Stsadm.exe avec l'opération databaserepair
pour détecter et supprimer des éléments orphelins, procédez comme suit :

1. Cliquez sur Démarrer , cliquez sur Exécuter , tapez cmd et cliquez sur OK .

2. Tapez la ligne suivante à l'invite de commandes et appuyez sur ENTRÉE :

CD /d %commonprogramfiles%Microsoft SharedWeb Server Extensions60Bin

3. Détecte les éléments orphelins dans la base de données. Pour ce faire, tapez la ligne suivante à

l'invite de commandes et appuyez sur ENTRÉE :

stsadm-o databaserepair - url http:// URLofWindowsSharePointServicesSite -

databasename DatabaseName

Une liste de conteneurs qui contiennent des orphelins éléments qui sont détectées par l'outil de

ligne de commande Stsadm.exe s'affiche. Le numéro qui apparaît dans la < nombre

OrphanedObjects = "Number " > ligne représente le nombre de conteneurs orphelins. L'exemple

suivant est un exemple d'une liste qui indique que 10 conteneurs orphelines ont été détectées

par l'outil :

<OrphanedObjects Count="Number">
<Orphan Type="SPList" Id="{ID}" SiteId="{ID}" />


</OrphanedObjects>

4. Supprimer des éléments orphelins. Pour ce faire, tapez la ligne suivante à l'invite de commandes

et appuyez sur ENTRÉE :

stsadm-o databaserepair - url http:// URLofWindowsSharePointServicesSite -

databasename DatabaseName - deletecorruption

5. Répétez les étapes 4 et 5 jusqu'à ce que l'outil Stsadm.exe ne détecte plus tous les éléments

orphelins. Lorsque orphelins des éléments plus détectés, les données suivantes s'affiche après

avoir utilisé l'outil de ligne de commande Stsadm.exe :

<OrphanedObjects Count="0" />

Étape 2: exécuter l'outil Spsadm.exe si vous exécutez SharePoint
Portal Server 2003
Si vous exécutez SharePoint Portal Server 2003, exécutez l'outil de ligne de commande Spsadm.exe avec

l'opération de ligne de commande repairorphans pour réparer orphelins articles qui peuvent être

présentes dans la base de données de configuration. L'opération repairorphans supprime et puis

reattaches PortalSiteName _SITE contenu celle-ci. Lorsque vous exécutez l'outil Spsadm.exe avec

l'opération repairorphans , éléments orphelins qui existe peut-être pour base de données

PortalSiteName _SITE de contenu sont supprimés de la base de données de configuration.

Pour plus d'informations sur l'utilisation de l'outil Spsadm.exe pour nettoyer les éléments orphelins dans

la base de données de configuration, cliquez sur le numéro ci-dessous pour afficher l'article

correspondant dans la Base de connaissances Microsoft :

918742 Description d'une nouvelle opération de ligne de commande qui est disponible pour l'outil de

ligne de commande Spsadm.exe que vous pouvez utiliser pour nettoyer les éléments orphelins dans la

base de données de configuration dans SharePoint Portal Server 2003

Étape 3: supprimer et puis rattacher les bases de données contenus
sur le serveur virtuel
Lorsque vous supprimez une base de données de contenu à partir d'un serveur virtuel, les sites Windows

SharePoint Services 2.0 Web qui sont stockées dans cette base de données ne sont pas disponibles


jusqu'à ce que vous rattachez la base de données de contenu pour le serveur virtuel. Pour éviter le

temps pour les utilisateurs, effectuez cette étape pendant les heures creuses sur un jour et en un temps

lorsque le serveur fortement n'utilisé.

Pour supprimer et puis rattacher la base de données contenu ou les bases de données contenus sur le

serveur virtuel, procédez comme suit :

1. Cliquez sur Démarrer , sur Outils d'administration , puis cliquez sur Administration

centrale de SharePoint .

2. Sous Configuration du serveur virtuel dans la page Windows SharePoint Services 2.0

Administration centrale, cliquez sur Configurer les paramètres du serveur virtuel .

3. Cliquez sur le serveur virtuel que vous souhaitez configurer, puis cliquez sur Gérer les bases

de données de contenu sous Gestion du serveur virtuel dans la page Paramètres du

serveur virtuel.

4. Dans la page Gérer les bases de données de contenu, cliquez sur la base de données contenu

que vous souhaitez supprimer.

5. Dans la page Gérer les paramètres de la base de données contenu, notez les paramètres

suivants :

o Le serveur de base de données

o Le nom de la base de données

o Les paramètres de capacité de la base de données de

6. Activez la case à cocher Supprimer la base de données de contenu , puis cliquez sur OK .

Lorsque vous êtes invité à confirmer que vous souhaitez supprimer la base de données de

contenu, cliquez sur OK .

7. Cliquez sur OK .

8. Dans la page Gérer les bases de données de contenu, cliquez sur Ajouter une base de

données de contenu .

9. Dans la page Ajouter un base de données de contenu, spécifiez le serveur de base de données,

le nom de la base de données, ainsi que les paramètres de capacité de la base de données de.

Ensuite, cliquez sur OK .

important N'exécutez pas la commande « repairorphans spsadm » par rapport à une batterie de portail

direct qui n'est pas entièrement suspendue. Lorsque vous exécutez l'outil Repairorphans sur une batterie

de serveurs du portail, le problème suivant est remplie :

 La batterie de serveurs portail ne sont pas accessibles par les utilisateurs.

 La batterie de serveurs portail ne peut pas être sauvegardé par SQL ou un autre logiciel de

sauvegarde sur le côté SQL de la batterie de serveurs ou le côté de SharePoint.


 La batterie de serveurs portail ne peut pas avoir externe code de modèle objet exécuté lors de

l'opération entière de la commande « repairorphans ».

Vous devez configurer SharePoint Portal Server afin que les utilisateurs ne peut pas créer sur cette ou

ajouter du contenu. Vous devez également définir le serveur pour en lecture seule. Pour plus

d'informations, site le suivant Web obtenir le Portal Server 2003 Guide de l'administrateur SharePoint :

http://www.microsoft.com/downloads/details.aspx?familyid=47405143-F586-4941-92F5-

048BF00CF332&displaylang=en&displaylang=en

Le correctif logiciel ajoute une nouvelle opération de ligne de commande repairorphans que vous

pouvez utiliser avec l'outil de ligne de commande Spsadm.exe pour nettoyer les éléments orphelins dans

la base de données de configuration. L'opération repairorphans utilise le paramètre portalURI.

L'espace réservé portalURI est l'URI (Uniform Resource IDENTIFIER) du site portail.

La syntaxe que l'outil de ligne de commande Spsadm.exe et l'opération repairorphans utilisent est la

suivante :

spsadm repairorphans portalURI

Comment nettoyer les éléments orphelins dans SharePoint Portal
Server 2003
Pour utiliser l'outil de ligne de commande Spsadm.exe avec l'opération repairorphans pour nettoyer les

éléments orphelins dans la base de données de configuration, procédez comme suit :

1. Cliquez sur Démarrer , cliquez sur Exécuter , tapez cmd dans la zone Ouvrir et puis cliquez

sur OK .

2. Tapez la ligne suivante à l'invite de commandes. , puis appuyez sur ENTRÉE :

CD /d %programfiles%Sharepoint ServerBin Portal

3. Tapez la ligne suivante à l'invite de commandes et appuyez sur ENTRÉE :

spsadm repairorphans portalURI

Par exemple, si l'URI du site portail est http://Server1, tapez la ligne suivante à l'invite de
commandes et appuyez sur ENTRÉE :


spsadm repairorphans http://Server1

important N'exécutez pas la commande « repairorphans spsadm » par rapport à une batterie de portail

direct qui n'est pas entièrement suspendue. Lorsque vous exécutez l'outil Repairorphans sur une batterie

de serveurs du portail, le problème suivant est remplie :

 La batterie de serveurs portail ne sont pas accessibles par les utilisateurs.

 La batterie de serveurs portail ne peut pas être sauvegardé par SQL ou un autre logiciel de

sauvegarde sur le côté SQL de la batterie de serveurs ou le côté de SharePoint.

 La batterie de serveurs portail ne peut pas avoir externe code de modèle objet exécuté lors de

l'opération entière de la commande « repairorphans ».

Vous devez configurer SharePoint Portal Server afin que les utilisateurs ne peut pas créer sur cette ou

ajouter du contenu. Vous devez également définir le serveur pour en lecture seule. Pour plus

d'informations, site le suivant Web obtenir le Portal Server 2003 Guide de l'administrateur SharePoint :

http://www.microsoft.com/downloads/details.aspx?familyid=47405143-F586-4941-92F5-

048BF00CF332&displaylang=en&displaylang=en


Sql orphelin

Recomendados

Recomendados

Más contenido relacionado

Destacado

Destacado (12)

Similar a Sql orphelin

Similar a Sql orphelin (20)

Más de UGAIA

Más de UGAIA (20)

Último

Último (20)

Sql orphelin