Résumé - download.microsoft.comdownload.microsoft.com/.../DatabaseMaintenanceShareP… · Web viewbases de données Word Automation ... CHECKDB pour vérifier la cohérence interne

Maintenance des bases de données pour les produits Microsoft® SharePoint® 2010

Auteurs : Bill Baer

Bryan Porter

Réviseur technique :Paul S. Randal (SQLskills.com)

Publication : Juillet 2011Résumé :Ce document décrit les stratégies de maintenance recommandées pour les bases de données qui hébergent du contenu et des paramètres de configuration pour les produits SharePoint 2010.

Microsoft SharePoint 2010 juillet 2011

Ce document est fourni en l’état. Les informations et les vues contenues dans ce document, y compris les URL et autres références de site Web Internet, sont susceptibles d’être modifiées sans préavis. Vous les utilisez à vos risques.Les exemples fournis ici le sont à titre d’illustration uniquement et sont fictifs. Aucune association ou connexion réelle n’est voulue ni suggérée.Ce document ne vous confère aucun droit sur la propriété intellectuelle contenue dans quelque produit Microsoft que ce soit. Vous pouvez copier ou utiliser ce document pour vos propres besoins de référence internes.

© 2011 Microsoft Corporation. Tous droits réservés.

© 2011 Microsoft Corporation. Tous droits réservés. Page | 2Pour commenter ce document ou demander de la documentation supplémentaire sur ces fonctionnalités, contactez le service de documentation informatique SharePoint

mailto:[email protected]?subject=Customer%20feedback


RésuméCe livre blanc fournit des informations et des conseils sur la maintenance des bases de données qui hébergent des données et des configurations Microsoft® SharePoint® 2010. Exemples à l’appui, il décrit les tâches de maintenance de base de données recommandées lors de l’utilisation de SharePoint 2010.

Avant d’implémenter des tâches de maintenance de base de données ou de modifier des bases de données SharePoint 2010, lisez l’article du support technique suivant :Prise en charge des modifications apportéesaux bases de données utilisées par les produits serveur Office et par Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110812&clcid=0x409).



http://go.microsoft.com/fwlink/?linkid=110812&clcid=0x40C




Sommaire

RÉSUMÉ........................................................................................................................................ 3Introduction................................................................................................................................... 5Recherche d’erreurs de cohérence à l’aide de DBCC CHECKDB............................................5À propos de DBCC CHECKDB.....................................................................................................6DBCC CHECKDB et performances..............................................................................................7Mesure et réduction de la fragmentation des index..................................................................7Reconstructions d’index en ligne ou hors connexion...............................................................8Mesure de la fragmentation dans une base de données SQL Server 2008 ou 2005 (sys.dm_db_index_physical_stats).............................................................................................9

Pour utiliser la vue de gestion dynamique sys.dm_db_index_physical_stats.........................9Réduction de la fragmentation d’une base de données..........................................................10

Exécution des règles de l’analyseur d’intégrité de maintenance de base de données.............10Réduction de la fragmentation d’une table spécifique et de ses index.................................13

Utilisation de l’instruction ALTER INDEX..................................................................................14Affinement des performances des index en définissant le taux de remplissage..................14Réduction des fichiers de données...........................................................................................15

Réduction d’une base de données à l’aide de commandes Transact-SQL..............................16Pour réduire une base de données à l’aide de SQL Server 2008 Management Studio............17

Création de plans de maintenance SQL Server 2008..............................................................18Pour configurer un plan de maintenance de base de données SQL Server 2008....................18

RÉSUMÉ...................................................................................................................................... 26




IntroductionUne maintenance des bases de données de routine est indispensable au bon fonctionnement des bases de données Microsoft® SharePoint® 2010. Ce livre blanc décrit les tâches de maintenance de base de données prises en charge pour SharePoint 2010.

Les tâches de maintenance recommandées pour les bases de données SharePoint 2010 sont les suivantes :

vérification de l’intégrité des bases de données ;

défragmentation des index en les réorganisant ou en les reconstruisant ;

définition du taux de remplissage pour un serveur.

Remarque : cet article présente la maintenance des bases de données, mais n’aborde pas la planification de la capacité ou des performances. Pour plus d’informations sur la capacité ou sur sa planification, voir Planification et configuration de la capacité de SQL Server et du stockage (SharePoint Server 2010) (http://go.microsoft.com/fwlink/?LinkId=217482).

Bien que les versions précédentes des produits et technologies SharePoint nécessitent une intervention manuelle pour la réalisation de la défragmentation des index et de la maintenance basée sur les statistiques, SharePoint 2010 automatise ce processus pour ses bases de données. Ces opérations sont accomplies par plusieurs règles de l’analyseur d’intégrité SharePoint. Ces règles évaluent l’intégrité des index et des statistiques de base de données de façon quotidienne et gèrent automatiquement ces éléments pour les bases de données suivantes :

bases de données de configuration ;

bases de données de contenu ;

bases de données de profils d’application de service de profil utilisateur ;

bases de données sociales d’application de service de profil utilisateur ;

bases de données de création de rapports d’application de service Web Analytics ;

bases de données de zone de transit d’application de service Web Analytics ;

bases de données Word Automation Services.

Vous pouvez également réaliser les tâches de maintenance de base de données en exécutant des commandes Transact-SQL ou l’Assistant Maintenance de base de données. Nous allons dans un premier temps présenter les commandes Transact-SQL que vous pouvez utiliser, puis nous expliquerons comment créer des plans de maintenance de base de données à l’aide de l’Assistant Maintenance de base de données Microsoft SQL Server®.

Remarque : dans ce document, les exemples détaillés ne concernent que SQL Server 2008 R2 et SQL Server 2005.

Recherche d’erreurs de cohérence à l’aide de DBCC CHECKDBCommencez vos opérations de maintenance de routine en réalisant des vérifications de cohérence afin de vous assurer que les données et les index ne sont pas endommagés. Vous pouvez utiliser l’instruction DBCC (Database Console Command) CHECKDB pour vérifier la cohérence interne des données et des pages d’index.

La grande majorité des problèmes de cohérence de base de données est due à des erreurs du sous-système d’E/S. Toutefois, la cohérence des bases de données peut être affectée en cas d’arrêt inapproprié d’un serveur de bases de données ou de défaillance d’un lecteur. Des






problèmes perceptibles de performance et de disponibilité peuvent parfois être les symptômes de problèmes de cohérence de base de données sous-jacents. Vous devez vérifier la cohérence des bases de données au moins une fois par semaine sur vos bases de données SharePoint 2010, et chaque fois que se produisent des événements tels que la défaillance d’un serveur de bases de données ou du sous-système d’E/S.

À propos de DBCC CHECKDBL’instruction DBCC CHECKDB vérifie l’intégrité logique et physique de tous les objets contenus dans la base de données spécifiée en réalisant les opérations suivantes :

Elle exécute l’équivalent de DBCC CHECKALLOC (http://go.microsoft.com/fwlink/?LinkId=110815&clcid=0x409) pour vérifier les structures d’allocation dans la base de données.

Elle exécute l’équivalent de DBCC CHECKTABLE (http://go.microsoft.com/fwlink/?LinkId=162093) sur chaque table et vue de la base de données pour vérifier leur intégrité logique et physique.

Elle exécute l’équivalent de DBCC CHECKCATALOG (http://go.microsoft.com/fwlink/?LinkId=110834&clcid=0x409) sur la base de données pour vérifier la cohérence de ses métadonnées.

Cela signifie que vous n’avez pas besoin d’exécuter DBCC CHECKALLOC, DBCC CHECKTABLE ou DBCC CHECKCATALOG en plus de DBCC CHECKDB.Il est recommandé d’exécuter DBCC CHECKDB plutôt que les opérations individuelles, car cette instruction identifie la plage d’erreurs la plus vaste possible, ce qui rend son exécution plus sûre dans un environnement de production.

L’instruction DBCC CHECKDB est très gourmande en ressources en termes de mémoire, d’opération d’E/S et de processeur. Au lieu d’exécuter DBCC CHECKDB sur votre système de production, vous pouvez l’exécuter sur une sauvegarde restaurée de vos bases de données SharePoint sur un autre serveur, afin que la vérification de la cohérence ne revienne pas au système de production.

Il est recommandé d’exécuter DBCC CHECKDB, puis, si des erreurs sont détectées, de restaurer la base de données affectée à l’aide des sauvegardes les plus récentes.

Important : l’exécution de DBCC CHECKDB avec REPAIR_ALLOW_DATA_LOSS n’est pas prise en charge. Toutefois, l’exécution de DBCC_CHECKDB avec REPAIR_FAST et REPAIR_REBUILD est prise en charge, car ces commandes ne mettent à jour que les index de la base de données associée.

Le tableau suivant contient des exemples de sortie de DBCC CHECKDB.

Résultats DBCC pour 'Contoso_Content_1'.

Message Service Broker 9675, état 1 : Types de messages analysés : 14.

Message Service Broker 9676, état 1 : Contrats de service analysés : 6.

Message Service Broker 9667, état 1 : Services analysés : 3.

Message Service Broker 9668, état 1 : Files d’attente du service analysées : 3.

Message Service Broker 9669, état 1 : Points de terminaison de conversation analysés : 0.

Message Service Broker 9674, état 1 : Groupes de conversation









analysés : 0.

Message Service Broker 9670, état 1 : Liaisons de service distant analysées : 0.

Résultats DBCC pour 'sys.sysrowsetcolumns'.

Il y a 2663 lignes dans 21 pages pour l’objet "sys.sysrowsetcolumns".

Résultats DBCC pour 'sys.sysrowsets'.

Il y a 309 lignes dans 4 pages pour l’objet "sys.sysrowsets".

…plus

CHECKDB a trouvé 0 erreurs d’allocation et 0 erreurs de cohérence dans la base de données 'Contoso_Content_1'.

Exécution de DBCC terminée. Si DBCC vous a adressé des messages d’erreur, contactez l’administrateur système.

Tableau 1. Exemple de sortie de DBCC CHECKDB

Pour plus d’informations sur l’utilisation de DBCC CHECKDB avec SQL Server 2008, voir DBCC CHECKDB (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=217483).

DBCC CHECKDB et performancesIl est recommandé d’exécuter les vérifications de cohérence en dehors des heures de production, car l’instruction DBCC CHECKDB est extrêmement gourmande en ressources (en termes d’opérations d’E/S, de processeur, de mémoire et d’espace de base de données temporaire). Selon une idée fausse répandue, DBCC CHECKDB acquiert des verrous persistants ; cela n’est pas le cas depuis SQL Server 2000. Pour plus d’informations sur la non-acquisition de verrous persistants par DBCC CHECKDB, voir « Un mythe par jour pour l’administrateur de base de données SQL Server : (2/30) DBCC CHECKDB entraîne un blocage » (http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx).

Il est possible que l’exécution de DBCC CHECKDB s’avère trop gourmande en ressources pour votre système de production. Dans ce cas, n’essayez pas d’exécuter les vérifications de cohérence sur une table à la fois, car cela engendrerait une situation globale plus problématique. La meilleure façon de réduire la charge liée à la vérification de l’intégrité sur le système de production consiste à effectuer l’une des opérations suivantes :

utiliser l’option WITH PHYSICAL_ONLY pour réduire l’utilisation du processeur et de la mémoire ;

restaurer une sauvegarde de base de données sur un serveur SQL distinct et exécuter les vérifications de cohérence sur la copie restaurée de la base de données.

Pour plus d’informations sur ces options, voir ce billet de blog rédigé par Paul S. Randal.

Mesure et réduction de la fragmentation des indexLa fragmentation des index se produit lorsque l’ordre logique des pages dans une table ou dans un index (tel que défini par la clé d’index) diffère de l’ordre physique des pages dans les fichiers de données. Cela peut également traduire une faible densité des données dans les pages des fichiers de données, avec pour corollaire un gaspillage de l’espace disque, de la mémoire et des



http://www.sqlskills.com/BLOGS/PAUL/post/CHECKDB-From-Every-Angle-Consistency-Checking-Options-for-a-VLDB.aspx

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx

http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-(230)-DBCC-CHECKDB-causes-blocking.aspx




opérations d’E/O. La fragmentation des index peut être le résultat d’un nombre élevé d’insertions, de mises à jour ou de suppressions dans une table. Les figures suivantes illustrent un index non fragmenté nouvellement construit, puis un index fragmenté après de nombreuses insertions, mises à jour et suppressions. La flèche rouge montre l’ordre physique de l’index, tandis que les flèches noires indiquent l’organisation logique des pages d’index.

Figure 1. Index non fragmenté (source de l’image : Paul S. Randal)

Figure 2. Index fragmenté (source de l’image : Paul S. Randal)Étant donné que les insertions, les mises à jour et les suppressions ne sont pas réparties de façon égale dans les lignes de la table et des index, le remplissage (ou densité de données) de chaque page peut varier dans le temps. Dans le cas des requêtes qui analysent une partie ou la totalité des index d’une table, la fragmentation peut entraîner des lectures de page supplémentaires, ce qui gêne l’analyse parallèle de données et peut affecter sensiblement les performances de recherche.

La fragmentation des index peut se traduire par une dégradation des performances et par une utilisation inefficace de l’espace. En outre, elle peut se produire rapidement, même sur les bases de données modérément utilisées.

Avant d’implémenter un plan de maintenance pour la fragmentation des index, vous devez déterminer les tables et les index les plus fragmentés, puis créer un plan de maintenance pour reconstruire ou réorganiser ces index.

Dans SharePoint 2010, un exemple de table qui devient souvent fragmentée est la table AllDocs, qui contient des bibliothèques de documents, les documents, listes et éléments de liste associés à celles-ci, ainsi que les métadonnées correspondantes.

Le niveau de fragmentation d’un index est exprimé par le pourcentage de pages d’index qui ne se trouvent pas dans les mêmes ordres logique et physique.

Reconstructions d’index en ligne ou hors connexionLa reconstruction d’index en ligne n’est disponible que dans les éditions SQL Server Enterprise, Developer et Evaluation. Les méthodes présentées dans ce livre blanc en tiennent compte. Les procédures indiquées basculent vers une reconstruction d’index hors connexion si l’édition de SQL Server qui héberge une base de données spécifique ne prend pas en charge les reconstructions d’index en ligne ou que l’index reconstruit ne peut pas faire l’objet d’une reconstruction d’index en ligne. La présence de colonnes LOB (Large Object), telles que des colonnes de type de données NVARCHAR(MAX), IMAGE, etc., peut empêcher la reconstruction en ligne d’un index.




Pour plus d’informations sur les reconstructions d’index en ligne, voir Fonctionnement des opérations d’index enligne (http://go.microsoft.com/fwlink/?LinkId=217492). Lorsqu’un index fait l’objet d’une reconstruction hors connexion, des verrous de niveau table sont placés pendant le processus de reconstruction. Cela peut empêcher l’écriture de données dans la table, voire l’accès à celle-ci dans son ensemble. De nombreux index dans les bases de données SharePoint sont systématiquement reconstruits en mode hors connexion en raison de la présence de colonnes LOB.

Même si la reconstruction d’index en ligne est utilisée, il existe toujours deux points dans l’opération où les verrous de table sont conservés momentanément, ce qui peut être source de blocage. Par conséquent, il est recommandé de planifier les activités de reconstruction d’index de manière à ce qu’elles se déroulent systématiquement pendant des périodes de faible activité.

Mesure de la fragmentation dans une base de données SQL Server 2008 ou 2005 (sys.dm_db_index_physical_stats)Dans SQL Server 2008 ou SQL Server 2005, utilisez la vue de gestion dynamique sys.dm_db_index_physical_stats pour déterminer la fragmentation des index sur une table ou vue spécifiée.

Pour mesurer la fragmentation, il est recommandé de surveiller la colonne avg_fragmentation_in_percent. La valeur de la colonne avg_fragmentation_in_percent doit être aussi proche de zéro que possible pour des performances maximales. Toutefois, des valeurs comprises entre 0 % et 10 % peuvent être acceptables. Pour plus d’informations, voir sys.dm_db_index_physical_stats (http://go.microsoft.com/fwlink/?LinkId=110839&clcid=0x409).

Le tableau 2 montre un exemple de résultats de sys.dm_db_index_physical_stats, avec une valeur de 9,375 pour avg_fragmentation_in_percent dans une ligne.

database_id index_type_desc

alloc_unit_type_

desc

avg_fragmentation_

in_percent

10 CLUSTERED INDEX IN_ROW_DATA 0

10 NONCLUSTERED INDEX IN_ROW_DATA 0


10 CLUSTERED INDEX IN_ROW_DATA 0


10 CLUSTERED INDEX IN_ROW_DATA 9.375

Tableau 2. Exemple de résultats de sys.dm_db_index_physical_stats

Pour utiliser la vue de gestion dynamique sys.dm_db_index_physical_stats1. Dans la barre des tâches, cliquez sur Démarrer, pointez sur Tous les programmes,

pointez sur Microsoft SQL Server 2008, puis cliquez sur SQL Server Management Studio.







Pour utiliser sys.dm_db_index_physical_stats avec un objet de base de données, vous devez connaître l’ID de base de données et l’ID d’objet.

2. Sélectionnez la base de données de contenu dans l’Explorateur d’objets, puis cliquez sur Nouvelle requête. Exécutez le script suivant.

SELECT DB_ID() AS [ID de base de données];

Remarque : si vous utilisez DB_ID sans spécifier de nom de base de données, le niveau de compatibilité de la base de données actuelle doit être 100 (base de données SQL Server 2008) ou 90 (base de données SQL Server 2005). Si vous avez effectué une mise à niveau depuis une version antérieure de SQL Server, vous devez spécifier un nom de base de données dans l’instruction DB_ID. Pour plus d’informations sur les niveaux de compatibilité, voir sp_dbcmptlevel (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110840&clcid=0x409).

3. Exécutez sys.dm_db_index_physical_stats sur la base de données ou sur l’objet que vous avez sélectionné. Vous pouvez spécifier la base de données, mais également une table ou un index. Syntaxe :

sys.dm_db_index_physical_stats (

{ id_base_de_données | NULL | 0 | DEFAULT }

, { id_objet | NULL | 0 | DEFAULT }

, { id_index | NULL | 0 | -1 | DEFAULT }

, { numéro_partition | NULL | 0 | DEFAULT }

, { mode | NULL | DEFAULT }

)

Vous devez utiliser la vue de gestion dynamique sys.dm_db_index_physical_stats avec précaution, car elle peut s’avérer très gourmande en ressources. Un guide complet expliquant les différentes façons de l’utiliser est disponible à la pageInsidesys.dm_db_index_physical_stats (http://www.sqlskills.com/BLOGS/PAUL/post/Inside-sysdm_db_index_physical_stats.aspx).

Réduction de la fragmentation d’une base de donnéesPour réduire le niveau de fragmentation d’index, suivez l’aide indiquée ci-après.

Exécution des règles de l’analyseur d’intégrité de maintenance de base de donnéesSharePoint 2010 contient l’infrastructure des règles de l’analyseur d’intégrité. Cette infrastructure de règles comporte une série de règles qui permettent de surveiller l’intégrité et l’état d’un environnement SharePoint et, dans certaines situations, procède à la correction de certains types de problèmes.

SharePoint 2010 contient plusieurs règles pertinentes pour la maintenance des bases de données de contenu. Certaines règles réduisent automatiquement la fragmentation des index pour certaines bases de données SharePoint, tandis que d’autres recherchent les statistiques obsolètes et les mettent à jour si cela est nécessaire. Ces règles de l’analyseur d’intégrité remplacent le travail du minuteur Statistiques de la base de données mis à jour introduit dans le Service Pack 2 des produits et technologies SharePoint. Par défaut, ces règles sont configurées de manière à s’exécuter chaque jour, chaque semaine ou à la demande suivant la cible de la règle.



http://www.sqlskills.com/BLOGS/PAUL/post/Inside-sysdm_db_index_physical_stats.aspx



Toutes les règles de l’analyseur d’intégrité configurées de manière à s’exécuter chaque jour et associées à un service SharePoint particulier sont exécutées par le même travail du minuteur. L’ajustement de la planification de ce travail du minuteur permet d’ajuster à quel moment de la journée seront exécutées les règles de l’analyseur d’intégrité configurées pour une exécution quotidienne et associées à ce service. Toutes les règles abordées dans ce livre blanc sont associées au service du minuteur SharePoint.

Les règles de l’analyseur d’intégrité configurées de manière à s’exécuter selon une fréquence différente (par exemple, une fois par semaine) ou associées à un autre service dépendent de travaux du minuteur distincts. Si une règle de l’analyseur d’intégrité est configurée de manière à s’exécuter selon une fréquence hebdomadaire, cette règle s’exécute avec le travail du minuteur qui est configuré de manière à s’exécuter chaque semaine pour le service auquel la règle est associée. Cette exécution se produit à la fréquence définie pour ce travail du minuteur.

Vous pouvez exécuter les règles de l’analyseur d’intégrité manuellement en sélectionnant « Exécuter maintenant » dans le Ruban depuis la page des règles de l’analyseur d’intégrité dans l’Administration centrale. L’exécution de ces règles entraîne l’évaluation de l’intégrité des index et des statistiques et, le cas échéant, la reconstruction et le recalcul des index.

Des bases de données utilisées par SharePoint comportent des index fragmentés - Lorsque vous exécutez cette règle, les tâches suivantes sont réalisées :

La règle indique la présence d’index fragmentés. En effet, l’évaluation de l’intégrité des index est une opération coûteuse. L’exécution de la règle de l’analyseur d’intégrité se traduit systématiquement par l’indication de la présence d’index fragmentés afin que soit déclenchée l’action corrective.

Pour chaque base de données SharePoint, l’action de la règle recherche la procédure stockée proc_DefragmentIndices, puis l’exécute si elle la trouve. Pendant l’exécution de cette procédure stockée, une liste de tous les index contenus dans la base de données est créée. Chaque index est évalué en fonction de son niveau de fragmentation actuel. Tous les index dont le niveau de fragmentation est supérieur à 30 % sont susceptibles de faire l’objet d’une reconstruction.

Dans l’hypothèse où l’édition de SQL Server prend en charge les reconstructions d’index en ligne, une reconstruction d’index en ligne est tentée pour chaque index. En cas d’échec, peut-être lié au fait que l’index sous-jacent ne prend pas en charge les reconstructions en ligne en raison de l’utilisation de colonnes LOB, une reconstruction d’index hors connexion est réalisée.

Comme indiqué plus haut, toutes les bases de données dans un environnement SharePoint ne sont pas gérées par cette règle. Certaines bases de données utilisent des règles différentes pour des activités de maintenance similaire.

Rechercher - Une ou plusieurs bases de données de propriétés contiennent des index fragmentés - Cette règle gère les index dans les bases de données de propriétés de recherche de contenu d’entreprise SharePoint 2010. Par défaut, cette règle est configurée de manière à s’exécuter chaque semaine sur n’importe quel serveur de la batterie de serveurs. Tout le traitement lié à cette règle, notamment les actions correctives, se produit pendant la phase de vérification de l’exécution de la règle. Cela signifie que si vous souhaitez gérer les reconstructions d’index pour la base de données de propriétés de recherche de contenu d’entreprise, il ne suffit pas de configurer cette règle de manière à ce que les index ne soient pas reconstruits automatiquement. Vous devez désactiver la règle complètement afin d’éviter que SharePoint 2010 exécute automatiquement des opérations de maintenance d’index.

Lorsque vous exécutez la règle « Rechercher - Une ou plusieurs bases de données de propriétés contiennent des index fragmentés », les tâches suivantes sont réalisées :

La règle vérifie que l’environnement se trouve dans un état approprié pour la réalisation d’une reconstruction d’index.




Pour chaque base de données de propriétés configurée pour des applications de recherche au sein de la batterie de serveurs locale, la règle exécute la procédure stockée proc_MSS_DefragSearchIndexes. Pendant l’exécution de cette procédure stockée, une liste de tous les index dont la fragmentation moyenne est supérieure à 10 % est créée.

Parmi les index recensés dans la liste, tous ceux qui affectent les performances de la base de données de propriétés sont reconstruits. Si l’édition de SQL Server prend en charge les reconstructions d’index en ligne, une reconstruction d’index en ligne est effectuée. Si une reconstruction d’index en ligne échoue, l’index est reconstruit hors connexion.

Rechercher - Une ou plusieurs bases de données d’analyse peuvent contenir des index fragmentés - Cette règle gère les index dans les bases de données d’analyse de recherche de contenu d’entreprise SharePoint 2010. Par défaut, cette règle est configurée de manière à ne s’exécuter qu’à la demande. Son exécution intervient depuis n’importe quel serveur de la batterie de serveurs. Lorsqu’elle est exécutée, cette règle indique systématiquement la présence d’index fragmentés dans les bases de données d’analyse. Cela est dû au caractère coûteux de la recherche de fragmentation dans une base de données. Par conséquent, la simple désactivation de l’activité « Réparer » pour cette règle entraîne l’indication selon laquelle toutes les bases de données d’analyse sont instables, même si les index de celles-ci ont récemment fait l’objet d’une reconstruction.

Pour gérer manuellement la maintenance des index dans les bases de données d’analyse, vous devez désactiver complètement la règle « Rechercher - Une ou plusieurs bases de données d’analyse peuvent contenir des index fragmentés ».

Lorsque vous exécutez la règle « Rechercher - Une ou plusieurs bases de données d’analyse peuvent contenir des index fragmentés », les tâches suivantes sont réalisées :

La règle vérifie que l’environnement se trouve dans un état approprié pour la réalisation d’une reconstruction d’index.

Pour chaque base de données d’analyse configurée pour des applications de recherche au sein de la batterie de serveurs locale, la règle exécute la procédure stockée proc_MSS_DefragGathererIndexes.

Parmi les index recensés dans la liste, tous ceux qui affectent les performances de la base de données d’analyse sont reconstruits. Si l’édition de SQL Server prend en charge les reconstructions d’index en ligne, une reconstruction d’index en ligne est effectuée. Si une reconstruction d’index en ligne échoue, l’index est reconstruit hors connexion.

Il est important de noter que la règle « Rechercher - Une ou plusieurs bases de données d’analyse peuvent contenir des index fragmentés » reconstruit chaque index de toutes les bases de données d’analyse indépendamment du niveau de fragmentation. En outre, elle active la compression des données au niveau de la page, si cette fonctionnalité est prise en charge par l’édition de SQL Server qui héberge la base de données d’analyse.

En raison de sa nature, la base de données d’analyse n’est pas appelée à subir des défragmentations fréquentes. Exécutez cette règle après avoir réalisé une analyse complète de votre contenu. Ensuite, surveillez les index de la base de données d’analyse afin d’évaluer leur fragmentation et exécutez cette règle chaque fois que la fragmentation des index augmente. Cela peut se produire en cas d’ajout ou de suppression soudains d’une grande quantité de contenu analysé, par exemple, pendant la suppression de contenu liée au nettoyage de l’environnement ou après l’intégration d’une nouvelle source de contenu, telle qu’un partage de fichiers ou une application Web SharePoint volumineuse.

Il n’existe pas de mécanisme automatisé pour la maintenance des bases de données ci-après. Ces bases de données ne sont pas supposées subir un taux de fragmentation élevé. Surveillez




ces bases de données afin d’évaluer leur fragmentation et reconstruisez les index de ces bases de données lorsque la fragmentation est supérieure à 30 %.

Base de données de l’administration de la recherche Base de données Banque d’informations sécurisée Base de données de service d’états temporaires Base de données de synchronisation de profil Base de données d’utilisation Base de données des métadonnées gérées Base de données Business Connectivity Services Base de données PerformancePoint Services

Pour plus d’informations sur les modifications prises en charge pour les bases de données SharePoint 2010, voir Prise en charge des modifications apportées aux bases de données utilisées par les produits serveur Office et par Windows SharePoint Services (http://go.microsoft.com/fwlink/?LinkId=110844&clcid=0x409) dans la Base de connaissances Microsoft.

Si une défragmentation fréquente ne permet pas d’améliorer sensiblement les performances d’une base de données ou d’une table très fragmentée, vous devez vérifier les performances du sous-système d’E/S.

Réduction de la fragmentation d’une table spécifique et de ses indexSi vous souhaitez défragmenter un index associé à une table particulière plutôt qu’une base de données entière, vous pouvez réorganiser ou reconstruire l’index.

La réorganisation d’un index entraîne la réorganisation de son niveau feuille. La réorganisation d’un index défragmente et compacte les index cluster et non-cluster sur les tables et les vues, et peut améliorer sensiblement les performances d’analyse d’index. La réorganisation d’un index utilise l’espace existant alloué à l’index. La réorganisation est systématiquement réalisée en ligne, de sorte que la table sous-jacente est disponible pour les utilisateurs.

La reconstruction d’un index entraîne la reconstruction de la totalité d’une nouvelle copie de l’index. Cela signifie qu’une opération de reconstruction requiert suffisamment d’espace supplémentaire pour construire la nouvelle copie de l’index avant de supprimer l’ancien index fragmenté. La reconstruction améliore les performances d’analyse d’index et les recherches. Vous pouvez reconstruire l’index avec une table en ligne ou hors connexion.

Le niveau de fragmentation d’un index détermine la méthode à utiliser pour le défragmenter et s’il peut demeurer en ligne ou doit être mis hors connexion. Le tableau suivant décrit la méthode de défragmentation recommandée suivant le niveau de fragmentation.

Niveau de fragmentation Méthode de défragmentationJusqu’à 10 % Réorganiser (en ligne)

10-75% Reconstruire (en ligne)

75% Reconstruire (hors connexion)

Remarque : l’utilisation des commandes DROP INDEX et CREATE INDEX n’est pas prise en charge sur les bases de données SharePoint 2010.

Vous pouvez réorganiser et reconstruire les index à l’aide de l’instruction ALTER INDEX SQL Server 2008 ou SQL Server 2005 ou de l’Assistant Plan de maintenance SQL Server 2008 ou SQL Server 2005. Ce document ne décrit que les options SQL Server 2008 ou SQL Server 2005.© 2011 Microsoft Corporation. Tous droits réservés. Page | 13Pour commenter ce document ou demander de la documentation supplémentaire sur ces fonctionnalités, contactez le service de documentation informatique SharePoint





Utilisation de l’instruction ALTER INDEXL’instruction ALTER INDEX permet à un administrateur de base de données d’effectuer des opérations de maintenance par rapport à un index d’une table ou d’une vue. Elle permet de désactiver, reconstruire et réorganiser les index. Éventuellement, elle permet de définir des options sur l’index. En règle générale, vous pouvez reconstruire les index pendant que la base de données est en ligne, ce qui rend les données plus accessibles que dans le cadre d’une reconstruction d’index hors connexion.

Important : SQL Server 2000 prenait en charge l’utilisation de DBCC DBREINDEX et DBCC INDEXDEFRAG pour la maintenance des index. Ces commandes ont été désapprouvées à partir de SQL Server 2005 et seront supprimées dans une version future de SQL Server. N’utilisez pas ces commandes pour effectuer une maintenance d’index sur une base de données SharePoint 2010.

Remarque : lorsqu’un index fait l’objet d’une reconstruction hors connexion, un verrou de table partagé est placé sur la table, ce qui empêche l’exécution de toute opération, à l’exception des opérations SELECT. Les bases de données SharePoint 2010 utilisent des index cluster. Lorsqu’un index cluster fait l’objet d’une reconstruction hors connexion, un verrou de table exclusif est placé sur la table, rendant celle-ci inaccessible aux utilisateurs finaux.

Vous pouvez personnaliser l’exemple de script suivant pour reconstruire tous les index d’une table.USE Contoso_Content_1

GO

ALTER INDEX ALL ON [nom_base_de_données. [ nom_schéma ] . | nom_schéma. ]nom_table_ou_vue

REBUILD WITH (FILLFACTOR = 80, SORT_IN_TEMPDB = ON,

STATISTICS_NORECOMPUTE = ON)

GO

Affinement des performances des index en définissant le taux de remplissageLe taux de remplissage permet d’améliorer davantage les performances et le stockage des données d’index. Lorsque des index sont créés ou reconstruits, la valeur du taux de remplissage (1 à 100) détermine le pourcentage d’espace de chaque page de niveau feuille pouvant être rempli avec des données. L’espace restant est réservé pour une croissance future. Dans de nombreuses situations, le niveau de taux de remplissage par défaut à l’échelle du serveur (0) est optimal (ce qui signifie que chaque page est remplie à hauteur de 100 %). Toutefois, dans le cas de SharePoint 2010, un paramétrage de 80 à l’échelle du serveur est optimal pour la prise en charge de la croissance et la réduction au minimum de la fragmentation.

Remarque : il est déconseillé de définir le taux de remplissage pour des tables ou des index spécifiques. Bien que cela soit la méthode par défaut pour les bases de données SQL Server non-SharePoint, des tests ont montré que les bases de données SharePoint fonctionnent de façon optimale avec un taux de remplissage de 80 %.

Pour afficher la valeur du taux de remplissage d’un ou de plusieurs index, interrogez l’affichage catalogue sys.indexes. Pour plus d’informations sur l’affichage, voir sys.indexes(Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110850&clcid=0x409).

Pour configurer la valeur du taux de remplissage à l’échelle du serveur, utilisez la procédure stockée système sp_configure. Pour plus d’informations, voir spconfigure (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110851&clcid=0x409).






Réduction des fichiers de donnéesDans SQL Server 2008 et SQL Server 2005, vous pouvez réduire chaque fichier d’une base de données (extensions .mdf, .ldf et .ndf) pour supprimer les pages inutilisées et récupérer de l’espace disque. Les bases de données SharePoint 2010 ne réduisent pas automatiquement les fichiers de données, bien que de nombreuses activités créent de l’espace inutilisé dans ces bases de données. Les activités qui peuvent créer de l’espace inutilisé comprennent l’exécution de la commande Windows PowerShellMove-SPSite (http://technet.microsoft.com/en-us/library/ff607915.aspx) et la suppression de documents, de bibliothèques de documents, de listes, d’éléments de liste et de sites.

Figure 3. Allocation d’espace dans une base de données

L’espace disponible n’est libéré qu’à partir de la fin du fichier : par exemple, un fichier de base de données de contenu de 60 Go avec une taille cible spécifiée de 40 Go libérera autant d’espace que possible à partir de la dernière tranche de 20 Go du fichier de base de données (cette tranche représente conceptuellement l’extrémité droite). Si la dernière tranche de 20 Go comprend des pages utilisées, celles-ci sont déplacées vers la tranche de 40 Go initiale conservée du fichier. Vous pouvez réduire les fichiers de base de données séparément ou en tant que groupe.

Les opérations de réduction doivent être exécutées rarement et uniquement après l’exécution d’une opération qui supprime une très grande quantité de données d’une base de données et ce seulement lorsque cet espace disponible n’est pas appelé à être réutilisé. Les opérations de réduction de fichiers de données entraînent une fragmentation d’index intensive et sont extrêmement gourmandes en ressources. Par exemple, une réduction de fichiers de données de base de données est appropriée lors du déplacement d’un nombre élevé de collections de sites depuis une base de données de contenu vers une autre base de données de contenu ou de la suppression d’une grande liste, ces deux opérations pouvant créer des quantités élevées d’espace inutilisé. Les fichiers de base de données ne peuvent être réduits que jusqu’au point où il n’existe plus d’espace disponible. Par conséquent, une base de données de contenu dont le contenu n’est pas souvent supprimé risque de peu tirer parti de la réduction et verra probablement ses performances amoindries lorsqu’elle devra croître pour gérer des données supplémentaires sans accommodations particulières. Pour plus d’informations, voir Initialisation des fichiers de base de données (http://msdn.microsoft.com/en-us/library/ms175935.aspx).

Étant donné que la réduction entraîne une fragmentation des index, vous ne devez jamais réduire des fichiers de base de données de façon régulière ; les bases de données ne doivent être réduites que lorsque de grandes quantités d’espace inutilisé apparaissent après des opérations ayant une incidence significative sur la quantité relative d’espace utilisé dans une base de données. Dans la mesure du possible, évitez d’exécuter une réduction de base de données.

Suivez les conseils suivants pour réduire les bases de données :

Ne réduisez pas automatiquement les bases de données ou ne configurez pas un plan de maintenance qui réduit vos bases de données par programme.

Réduirez une base de données uniquement lorsqu’au moins 50 % de son contenu a été enlevé par des opérations de suppression effectuées par l’utilisateur ou l’administrateur et que l’espace inutilisé n’est pas appelé à être réutilisé par d’autres données.

Il est recommandé de réduire uniquement les bases de données de contenu. En règle générale, la base de données de configuration, la base de données de contenu de



http://msdn.microsoft.com/fr-fr/library/ms175935.aspx


http://technet.microsoft.com/fr-fr/library/ff607915.aspx


l’Administration centrale et différentes bases de données d’application de service ne subissent pas suffisamment de suppressions pour contenir un espace disponible significatif.

La réduction des bases de données est une opération extrêmement gourmande en ressources. Par conséquent, si vous devez absolument réduire une base de données, planifiez l’opération de réduction avec précaution.

Après une opération de réduction de base de données, les index au sein de cette base de données sont fragmentés. Gérez cette fragmentation à l’aide de l’instruction ALTER INDEX… REORGANIZE. Si votre configuration n’autorise pas l’initialisation de fichier instantanée, vous devez réduire la base de données à une taille cible qui permette la prise en charge de tout espace nécessaire dans la perspective d’une croissance à court terme. Pour plus d’informations, voir Initialisation des fichiers de base de données (http://msdn.microsoft.com/en-us/library/ms175935.aspx). Si vous supprimez la fragmentation en reconstruisant les index, la base de données croîtra de nouveau, avec à la clé l’apparition d’espace inutilisé.

Vous pouvez réduire les bases de données et les fichiers de base de données manuellement pour récupérer de l’espace en exécutant les instructions DBCC SHRINKFILE et DBCC SHRINKDATABASE, à l’aide de SQL Server 2008 ou de SQL Server 2005 Management Studio.

Pour plus d’informations sur les raisons pour lesquelles la réduction d’une base de données nuit aux performances et ne doit être réalisée qu’en cas d’absolue nécessité, voir Raisons pour lesquelles vous ne devez pas réduire vos fichiers de données (http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx).

Réduction d’une base de données à l’aide de commandes Transact-SQLDBCC SHRINKDATABASE réduit les fichiers de données et journaux d’une base de données spécifique. Pour réduire des fichiers particuliers, utilisez DBCC SHRINKFILE.

DBCC SHRINKDATABASESyntaxe :

DBCC SHRINKDATABASE

( 'nom_base_de_données' | id_base_de_données | 0

[ ,pourcentage_cible ]

[ , { NOTRUNCATE | TRUNCATEONLY } ]

)

[ WITH NO_INFOMSGS ]

nom_base_de_données| id_base_de_données| 0 spécifie le nom ou l’ID de la base de données. Pour sélectionner la base de données actuelle, utilisez 0.

pourcentage_cible est, en pourcentage, l’espace disponible que vous souhaitez conserver une fois la base de données réduite.

NOTRUNCATE compacte les données des fichiers de données en déplaçant les pages allouées depuis la fin d’un fichier vers des pages non allouées au début du fichier.

TRUNCATEONLY libère tout l’espace disponible à la fin du fichier pour le système d’exploitation, mais n’effectue pas de déplacement de page à l’intérieur du fichier.



http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx

http://www.sqlskills.com/BLOGS/PAUL/post/Why-you-should-not-shrink-your-data-files.aspx



Remarque : l’utilisation de l’option TRUNCATEONLY n’est pas prise en charge pour les bases de données de contenu SharePoint 2010.

Pour plus d’informations, voir DBCC SHRINKDATABASE (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110852&clcid=0x409).

DBCC SHRINKFILESyntaxe :

DBCC SHRINKFILE

(

{ 'nom_fichier' | id_fichier }

{ [ , EMPTYFILE ]

| [ [ , taille_cible ] [ , { NOTRUNCATE | TRUNCATEONLY } ] ]

}

)

[ WITH NO_INFOMSGS ]

nom_fichier | id_fichier spécifie le nom ou l’ID du fichier.

EMPTYFILE migre toutes les données depuis le fichier spécifié vers d’autres fichiers du même groupe de fichiers.

Remarque : l’utilisation de l’option EMPTYFILE n’est pas prise en charge pour les fichiers de base de données SharePoint 2010.

taille_cible est la taille cible du fichier en mégaoctets, exprimée sous la forme d’un entier.

NOTRUNCATE compacte les données des fichiers de données en déplaçant les pages allouées depuis la fin d’un fichier vers des pages non allouées au début du fichier.

TRUNCATEONLY libère tout l’espace disponible à la fin du fichier pour le système d’exploitation, mais n’effectue pas de déplacement de page à l’intérieur du fichier.

Remarque : l’utilisation de l’option TRUNCATEONLY n’est pas prise en charge pour les bases de données de contenu SharePoint 2010.

Pour plus d’informations, voir DBCC SHRINKFILE (Transact-SQL) (http://go.microsoft.com/fwlink/?LinkId=110853&clcid=0x409).

Pour réduire une base de données à l’aide de SQL Server 2008 Management Studio1. Dans la barre des tâches, cliquez sur Démarrer, pointez sur Tous les programmes,


2. Dans l’Explorateur d’objets, connectez-vous à une instance du moteur de base de données SQL Server 2008, puis développez cette instance.

3. Développez Bases de données, cliquez avec le bouton droit sur la base de données à réduire, pointez sur Tâches, pointez sur Réduire, puis cliquez sur Fichiers.

4. Sélectionnez le type de fichier et le nom de fichier.5. Sélectionnez Réorganiser les fichiers avant de libérer l’espace inutilisé. Vous devez

également définir la valeur Réduire le fichier à. La sélection de cette option entraîne la






libération de tout espace inutilisé dans le fichier pour le système d’exploitation et, dans la mesure du possible, le déplacement des lignes vers des pages non allouées.

6. Cliquez sur OK.

Création de plans de maintenance SQL Server 2008De nombreuses opérations de maintenance de base de données abordées dans ce livre blanc peuvent être appliquées par programme par le biais de l’implémentation de plans de maintenance SQL Server. Les plans de maintenance peuvent automatiser et planifier des tâches essentielles pour la protection de vos données. En utilisant des plans de maintenance dans SQL Server 2008 ou SQL Server 2005, un administrateur peut planifier des opérations telles que l’exécution de vérifications de la cohérence de la base de données et la réorganisation ou la reconstruction des index. Pour plus d’informations, voir les ressources suivantes :

Assistant Plan de maintenance (http://go.microsoft.com/fwlink/?LinkId=110855&clcid=0x409) pour SQL Server 2008

Assistant Plan de maintenance de base de données (http://go.microsoft.com/fwlink/?LinkId=217494) pour SQL Server 2005

Pour configurer un plan de maintenance de base de données SQL Server 20081. Dans la barre des tâches, cliquez sur Démarrer, pointez sur Tous les programmes,


2. Dans l’Explorateur d’objets, connectez-vous à une instance du moteur de base de données SQL Server 2008, puis développez cette instance.

3. Cliquez sur Gestion, cliquez avec le bouton droit sur Plans de maintenance, puis cliquez sur Assistant Plan de maintenance.

4. Cliquez sur Suivant jusqu’à ce que vous ayez atteint la page Sélectionner les propriétés de plan.

5. Dans les champs Nom et Description, tapez un nom et une description.






6. Indiquez si vous souhaitez configurer un plan de maintenance ou plusieurs. Pour configurer un seul plan de maintenance, sélectionnez Planification unique pour la

totalité du plan ou pas de planification.

Pour configurer plusieurs plans de maintenance avec des tâches spécifiques, sélectionnez Planification distincte pour chaque tâche.

Si votre environnement comprend au moins 10 bases de données de contenu ou plus de 200 Go de contenu, il est recommandé de configurer des plans de maintenance distincts pour fournir les spécificités appropriées et optimiser la fenêtre de maintenance.

Si vous configurez plusieurs plans de maintenance pour une base de données, spécifiez un nom ou une description qui permette de différencier les plans et leurs objectifs, notamment leurs planifications.

7. Cliquez sur Modifier pour définir une planification pour un ou plusieurs plans. La boîte de dialogue Propriétés de la planification du travail apparaît.

8. Terminez la planification, cliquez sur OK, puis cliquez sur Suivant. 9. Dans la page Sélectionner des tâches de maintenance, sélectionnez les tâches de

maintenance à inclure dans le plan, puis cliquez sur Suivant.




Remarques :

Un plan de maintenance doit comprendre une réorganisation d’index ou une reconstruction d’index, mais pas les deux.

Un plan de maintenance ne doit jamais inclure la réduction d’une base de données.

Pour déterminer la durée de chaque tâche, testez-la séparément avant de combiner les tâches dans un plan unique. Vous devrez peut-être définir plusieurs plans de maintenance sur des planifications distinctes pour que les tâches puissent s’exécuter pendant des plages horaires au cours desquelles les opérations des utilisateurs finaux ne seront pas affectées.

La tâche de nettoyage de maintenance supprime les fichiers qui restent à l’issue de l’exécution d’un plan de maintenance.

10. Dans la page Sélectionner l’ordre des tâches de maintenance, modifiez, si nécessaire, l’ordre des tâches du plan de maintenance. Sélectionnez une tâche, puis cliquez sur Monter ou Descendre. Une fois les tâches correctement organisées, cliquez sur Suivant.Remarque : si vos bases de données sont très volumineuses, vous pouvez créer un plan de maintenance distinct pour vérifier l’intégrité des bases de données moins fréquemment que la maintenance des index.




Ensuite, l’Assistant vous guide tout au long de la procédure de définition des détails de chaque tâche.

11. Dans la page Def. la tache vér. l’intégrité de la base de données, sélectionnez les bases de données dont vous souhaitez vérifier l’intégrité, puis cliquez sur Suivant.Remarque : vous pouvez vérifier l’intégrité de toutes les bases de données SharePoint 2010 en toute sécurité.




12. Dans la page Définir la tâche Réorganiser l’index, dans la liste BdD, spécifiez les bases de données dont vous souhaitez réorganiser les index, activez la case à cocher Compacter les objets importants, puis cliquez sur Suivant.

13. Dans la page Définir la tâche Reconstruire l’index, si vous avez choisi de reconstruire les index au lieu de les réorganiser, dans la liste BdD, spécifiez les bases de données dont vous souhaitez réorganiser les index.

14. Sélectionnez Modifier l’espace disponible par pourcentage de page de, tapez 80, puis cliquez sur Suivant.




La modification de l’espace disponible par pourcentage définit le taux de remplissage pour la base de données.

15. Dans la page Tâche de nettoyage de maintenance, définissez les valeurs en fonction de vos besoins, puis cliquez sur Suivant. Il est recommandé de supprimer les fichiers textes des rapports de plan de maintenance.







16. Dans la page Sélectionner des options de rapport, sélectionnez Enregistrer un rapport dans un fichier texte, sélectionnez un emplacement pour les fichiers, puis cliquez sur Suivant jusqu’à la fin de l’Assistant.

RésuméQuelle que soit la méthode que vous choisissez d’utiliser, la maintenance cohérente des bases de données qui hébergent SharePoint 2010 peut améliorer sensiblement l’intégrité et les performances de votre système.

Avant d’implémenter les opérations de maintenance et les plans de maintenance, vérifiez que vous disposez de sauvegardes fiables pour toutes les bases de données.

Avant d’implémenter des opérations de maintenance à exécution cohérente ou un plan de maintenance, évaluez l’impact des opérations sur votre système et la durée nécessaire pour les exécuter.

Dans la mesure du possible, configurez les opérations de maintenance ou les plans de maintenance de manière à ce qu’ils s’exécutent pendant des heures creuses afin de réduire au minimum l’incidence sur les performances du point de vue des utilisateurs.



Documents

Résumé - download.microsoft.comdownload.microsoft.com/.../DatabaseMaintenanceShareP… · Web viewbases de données Word Automation ... CHECKDB pour vérifier la cohérence interne