Sql orphelin

FORMATIONS SHAREPOINT

MEG-JIC - Pierre Erol GIRAUDY

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



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.

http://blogs.technet.com/corybu/archive/2007/05/31/sharepoint-orphans-explained.aspx

http://blogs.msdn.com/krichie/archive/2005/10/25/484889.aspx



http://blogs.msdn.com/joelo/archive/2006/06/23/644954.aspx



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

http://nom_serveur

Oui Nom d’URL de l’application Web

en cours de réparation.

databasename (dn) Nom de base de données

valide, tel que « BD1 »

Oui Nom de la base de données de

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+''')

mailto:'''+@dbname+'''

mailto:'''+@configdb+'''


mailto:'''+@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.



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



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.

1. What's an Orphaned Site?

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.

2. What do we know about what causes Orphaned Sites?

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 :)

3. How do I determine if I truly have an orphaned site?

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 :)

4. What we've done to prevent Orphaned Sites

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.

5. What we're doing to cleanup Orphaned Sites

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

http://support.microsoft.com/?id=906336



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:

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

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:


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

http://support.microsoft.com/default.aspx?scid=kb;EN-US;918744

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 Shared\Web Server Extensions\60\Bin

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

http://support.microsoft.com/kb/918742/



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 Server\Bin 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 :

http://www.microsoft.com/downloads/details.aspx?familyid=47405143-F586-4941-92F5-048BF00CF332&displaylang=en&displaylang=en




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

Education

Transcript of Sql orphelin