Addcontentdb : opération Stsadm (Windows SharePoint Services)
Mise à jour : 2008-07-15
Nom de l’opération : Addcontentdb
Crée une base de données de contenu ou ajoute une base de données qui doit être mise à niveau lorsque les paramètres url et databasename sont spécifiés.
Lorsqu’une base de données de contenu est créée, l’emplacement du fichier de données et du fichier journal est déterminé par les paramètres de base de données par défaut établis sur le serveur de base de données SQL. Une base de données de contenu est créée avec un groupe de fichiers principal hébergeant un fichier de données (.mdf) et un fichier journal de transactions (.ldf). Lorsque l’opération addcontentdb est utilisée pour créer une base de données de contenu, vous devez exécuter l’opération spsearch pour associer une base de données de contenu à un serveur spécifique exécutant le service Recherche Windows SharePoint Services. Pour plus d’informations sur l’opération spsearch, voir Spsearch : opération Stsadm (Windows SharePoint Services).
Important : |
---|
Si vous détachez et attachez de nouveau une base de données de contenu, sachez que la prochaine fois que le contenu dans cette base de données de contenu sera analysé, une analyse complète aura lieu même si une analyse incrémentielle a été demandée. Dans la mesure où une analyse complète analyse à nouveau tout le contenu rencontré par le robot, que ce contenu ait été analysé précédemment ou non, les analyses complètes prennent plus de temps que les analyses incrémentielles. |
Syntaxe
stsadm.exe -o addcontentdb
-url <nom_URL>
-[-assignnewdatabaseid]
-[-clearchangelog]
-databasename <nom_base_de_données>
[-databaseserver <nom_serveur_base_de_données>]
[-databaseuser <nom_utilisateur_base_de_données>]
[-databasepassword <mot_de_passe_base_de_données>]
[-sitewarning <nombre_avertissements_site>]
[-sitemax <nombre_maximal_sites>]
Paramètres
Nom du paramètre et forme abrégée | Valeur | Obligatoire ? | Description |
---|---|---|---|
url |
URL valide, par exemple http://nom_serveur |
Oui |
URL de l’application Web à laquelle la base de données de contenu est ajoutée. |
assignnewdatabaseid |
GUID valide, tel que "12345678-90ab-cdef-1234-567890bcdefgh" |
Non |
Crée automatiquement un nouvel ID de base de données lorsqu’une base de données de contenu est attachée. Ce paramètre a été introduit pour la première fois dans la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0. Pour plus d’informations, voir Remarques. |
clearchangelog |
<aucune> |
Non |
Efface le journal des modifications Force l’effacement du journal des modifications lorsque cela est nécessaire, par exemple lors de la restauration d’une base de données de contenu à un état antérieur à l’aide d’outils de sauvegarde séparés exécutés au niveau SQL Server. Ce paramètre a été introduit pour la première fois dans la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0. Pour plus d’informations, voir Remarques. |
databasename (dn) |
Nom de base de données valide, par exemple « BD1 » |
Oui |
Nom de la base de données. |
databaseserver (ds) |
Nom de serveur de base de données valide, par exemple « Ventes », où les instances nommées sont utilisées ; le format peut être le suivant : serveur\serveur |
Non |
Nom du serveur de base de données. Le serveur par défaut est utilisé si aucune valeur n’est fournie. |
databaseuser |
Nom d’utilisateur valide sous la forme « nom_utilisateur1 » |
Non |
Compte utilisé pour l’authentification SQL. Doit être utilisé conjointement avec le paramètre databasepassword. |
databasepassword |
Mot de passe SQL valide |
Non |
Le paramètre databasepassword ne doit être utilisé que lorsque l’authentification Windows n’est pas implémentée. Par conséquent, dans un scénario d’authentification Microsoft SQL Server, vous devez passer les paramètres databaseuser et databasepassword pour vous authentifier auprès du serveur de base de données. Dans le cadre de l’authentification Windows, vous pouvez omettre ces paramètres étant donné que les informations d’identification sont passées à l’aide de NTLM. |
sitewarning |
Nombre entier valide, par exemple 10 |
Non |
Nombre entier de collections de sites autorisées dans la base de données de contenu avant la génération d’un événement d’avertissement dans le journal des événements Windows. |
sitemax |
Nombre entier valide, par exemple 10 |
Non |
Spécifie le nombre maximal de collections de sites autorisées dans la base de données de contenu. |
Remarques
Si vous exécutez la Mise à jour d’infrastructure pour Windows SharePoint Services 3.0, l’identificateur (ID) de chaque base de données de contenu est conservé lorsque vous restaurez ou rattachez la base de données à l’aide des outils intégrés. Le comportement de rétention par défaut du journal des modifications est le suivant lorsque vous utilisez les outils intégrés :
Les journaux des modifications de toutes les bases de données sont conservés lorsque vous restaurez une batterie de serveurs.
Le journal des modifications d’une base de données de contenu est conservé lorsque vous rattachez la base de données.
Le journal des modifications d’une base de données de contenu N’EST PAS CONSERVÉ lorsque vous restaurez uniquement la base de données de contenu.
Pour plus d’informations, voir Déplacer des bases de données de contenu (Windows SharePoint Services 3.0) et Administration de la sauvegarde et de la récupération pour la technologie Windows SharePoint Services 3.0.
Si vous restaurez une sauvegarde SQL Server d’une base de données de contenu plus ancienne, l’index de recherche peut contenir plus d’entrées que les bases de données restaurées dans la batterie de serveurs. Commencez par utiliser la commande Stsadm stsadm –o deletecontentdb pour détacher la base de données de la batterie SharePoint, puis restaurez la base à l’aide des outils SQL Server. Utilisez ensuite la commande Stsadm stsadm –o addcontentdb –clearchangelog pour rattacher la base de données de contenu et effacer le journal des modifications. L’effacement du journal force le service Recherche à exécuter une analyse complète de la base de données, de sorte que l’index ne contienne plus de référence à des éléments inexistants.
En tant qu’administrateur, vous devez être en mesure de déterminer quand un journal des modifications doit être effacé. Par exemple, si une base de données de contenu est restaurée à un état précédant la dernière analyse à l’aide d’outils de sauvegarde exécutés au niveau de Microsoft SQL Server et que cette opération est utilisée pour rattacher la base à la batterie de serveurs, le fait de ne pas effacer le journal des modifications peut provoquer des problèmes. En effet, l’index risque de contenir des entrées relatives à des éléments de la base de données de contenu qui n’existent pas dans la base restaurée. Pour éviter ce problème dans un tel scénario, utilisez le paramètre clearchangelog pour effacer le journal. Si une base de données de contenu a été attachée par erreur sans spécifier le paramètre clearchangelog, détachez puis rattachez la base à l’aide du paramètre clearchangelog, de sorte que l’analyse suivante provoque la réinitialisation de l’index de cette base de données de contenu.
Par défaut, lorsqu’une base de données de contenu est attachée à la même application Web, le journal des modifications et l’ID de la base de données sont conservés. S’il s’avère nécessaire de modifier l’ID de la base de données, par exemple en cas de conflit d’ID, le paramètre assignnewdatabaseid forcera l’attribution d’un nouvel ID pour la base de données de contenu.
Vous recevrez l’erreur suivante si vous ne parvenez pas à attacher la base de données à la batterie à cause d’un conflit : Impossible de continuer l’opération d’attachement, car un autre objet de cette batterie de serveurs contient déjà le même ID. Les différents objets d’une batterie doivent tous être associés à un ID unique. Pour poursuivre l’opération d’attachement, vous devez attribuer un nouvel ID à cette base de données. Pour attacher cette base de données en utilisant un nouvel ID, utilisez l’opération "stsadm.exe -o addcontentdb" en spécifiant le paramètre -assignnewdatabaseid. Sachez que si cette nouvelle base de données et une base existante contiennent les mêmes collections de sites, l’attachement de cette base risque de rendre certaines collections de sites orphelines, en raison des conflits existant entre les deux bases de données.