Défragmentation d'index pour des bases de données Project Server 2007

Mis à jour: septembre 2008

 

Dernière rubrique modifiée : 2015-02-27

Les tâches de maintenance de base de données peuvent être effectuées à l'aide des commandes Transact-SQL ou en exécutant l'Assistant Maintenance de base de données. Cet article fournit des détails sur les deux approches.

Les tâches de maintenance de base de données recommandées pour les bases de données de Microsoft Office Project Server 2007 sont ci-après.

• Vérifier l'intégrité de la base de données

• Défragmenter les index en les réorganisant ou en les recréant

• Définir le facteur de remplissage pour un serveur

• Contrôler la taille de base de données pour augmenter au préalable ou réduire les bases de données

• Nettoyer l'historique

• Mettre à jour les statistiques

Défragmenter les index en les réorganisant ou en les recréant

La fragmentation se produit lorsque l'allocation de stockage logique et physique d'une base de données contient plusieurs zones de stockage éparpillées qui sont insuffisantes et non contiguës physiquement ou qui sont devenues trop fragmentées pour être utilisées efficacement. La fragmentation peut être le résultat de nombreuses insertions, mises à jour ou suppressions dans une table. Lorsqu'une table devient fragmentée, les index définis sur la table sont également fragmentés.

Office Project Server 2007 utilise les types GUID comme clés de cluster, ce qui évite que des insertions simultanées n'utilisent les mêmes pages de données (insérer des zones réactives), mais cela peut provoquer la fragmentation de table et d'index. La fragmentation peut se produire car de nouveaux enregistrements peuvent être insérés n'importe où dans l'arbre B (b-tree), plutôt qu'à la fin, ce qui accroît les risques de fractionnement de page (index et données) et par conséquent de fragmentation. Cela est atténué par la gestion de clusters sur des clés composites qui utilisent l'UID de Project pour garantir que les pages de données contiennent des données liées, mais une défragmentation régulière des tables plus volumineuses améliore les performances, en particulier dans les grands déploiements de Office Project Server 2007.

Au fil du temps, la fragmentation de base de données peut entraîner une dégradation des performances (activité de disque inutile) et l'utilisation inefficace d'espace. Pour atténuer la fragmentation et réduire la fréquence à laquelle la fragmentation se produit, configurez manuellement la taille des bases de données de contenu pour que celle-ci soit aussi élevée que possible, par rapport aux besoins et à l'architecture de base de données de votre entreprise. Si, par exemple, vous devez limiter la taille des bases de données de contenu à 100 gigaoctets (Go), après avoir créé vos bases de données de contenu, définissez leur taille sur 100 Go dans SQL Server Management Studio.

Bien que vous pouvez défragmenter des tables, la défragmentation d'index est plus avantageuse pour les performances de base de données et elle est beaucoup plus rapide. Cet article explique uniquement la défragmentation d'index.

Avant d'implémenter un plan de maintenance de fragmentation de base de données, déterminez les tables et index les plus fragmentés, puis créez un plan de maintenance pour reconstruire ou réorganiser ces index.

Pour mesurer la fragmentation, procédez comme suit :

• Dans SQL Server 2005, utilisez l'affichage de gestion dynamique sys.dm_db_index_physical_stats

• Dans SQL Server 2000, utilisez DBCC SHOWCONTIG

Notez que l'algorithme pour calculer la fragmentation est plus précis dans sys.dm_db_index_physical_stats que dans DBCC SHOWCONTIG. Par conséquent, les valeurs de fragmentation calculées par sys.dm_db_index_physical_stats semblent plus élevées.

Mesure de la fragmentation à l'aide de sys.dm_db_index_physical_stats (SQL Server 2005)

Dans SQL Server 2005, utilisez l'affichage de gestion dynamique sys.dm_db_index_physical_stats pour déterminer la fragmentation des index dans une table ou un affichage spécifique.

Pour le calcul de la fragmentation, il est recommandé de contrôler la colonne avg_fragmentation_in_percent. La valeur de avg_fragmentation_in_percent doit être le plus près possible de zéro pour obtenir des performances optimales. Cependant, les valeurs comprises entre 0 et 10 % peuvent être acceptables.

Pour plus d'informations sur l'utilisation de sys.dm_db_index_physical_stats, voir sys.dm_db_index_physical_stats (en anglais) (https://go.microsoft.com/fwlink/?linkid=128479\&clcid=0x40C) (en anglais)

Mesure de la fragmentation à l'aide de DBCC SHOWCONTIG (SQL Server 2000)

Pour vérifier la fragmentation des tables de bases de données, un administrateur peut utiliser la fonction DBCC SHOWCONTIG pour signaler la fragmentation d'analyse étendue et logique. Pour obtenir une explication de tous les résultats de la fonction DBCC SHOWCONTIG, voir DBCC SHOWCONTIG (en anglais) (https://go.microsoft.com/fwlink/?linkid=110841\&clcid=0x40C) (en anglais).

Pour mesurer la fragmentation, il est recommandé de contrôler la valeur de densité d'analyse renvoyée par la fonction DBCC SHOWCONTIG. Dans les tables où tout est contigu, la densité d'analyse est 100.

Réduire la fragmentation d'une base de données

Pour réduire le niveau de fragmentation d'index, appliquez la procédure stockée dans l'article de la Base de connaissances Microsoft Comment défragmenter les bases de données Windows SharePoint Services 3.0 et les bases de données SharePoint Server 2007 (https://go.microsoft.com/fwlink/?LinkId=102795\&clcid=0x40C).

Après avoir déterminé le niveau de fragmentation de vos bases de données, vous pouvez configurer la procédure stockée pour s'exécuter tous les jours, toutes les semaines ou tous les mois, selon vos besoins et la fréquence globale des modifications dans votre environnement. En règle générale, il est recommandé d'établir au minimum un calendrier de défragmentation hebdomadaire. Il est également conseillé de planifier les opérations de défragmentation après avoir exécuté les opérations DBCC CHECKDB REPAIR.

Cette procédure stockée modifie les index de vos bases de données de contenu. Aucune modification de la procédure stockée n'est prise en charge. Pour plus d'informations sur les modifications prises en charge pour les bases de données de contenu des produits et technologies SharePoint, voir Prise en charge des modifications apportées aux bases de données qui sont utilisées par les produits du serveur Office et Windows SharePoint Services (https://go.microsoft.com/fwlink/?linkid=110844\&clcid=0x40C) dans la Base de connaissances Microsoft.

Réduire la fragmentation d'une table spécifique et de ses index

Si vous souhaitez défragmenter l'index associé à une table particulière, et non une base de données entière, vous pouvez réorganiser ou reconstruire l'index. Pour plus d’informations, voir les Structures des index cluster (https://go.microsoft.com/fwlink/?LinkId=108403\&clcid=0x40C) .

La réorganisation d'un index signifie que le niveau feuille de cet index va être réorganisé. La réorganisation d'index défragmente et compacte les index cluster et non cluster dans les tables et les affichages. Cette opération peut considérablement améliorer les performances d'analyse d'index. La réorganisation s'effectue toujours en ligne, afin que la table sous-jacente soit disponible pour les utilisateurs. La réorganisation est équivalent à l'instruction SQL Server 2000 DBCC INDEXDEFRAG.

La reconstruction d'index signifie que l'index va être reconstruit à l'aide des mêmes colonnes, type d'index, attribut d'unicité et ordre de tri. La reconstruction améliore les performances des analyses et de recherches d'index. Vous pouvez reconstruire l'index à l'aide d'une table en ligne ou hors connexion. La reconstruction est équivalente à l'instruction SQL Server 2000 DBCC DBREINDEX.

Le niveau de fragmentation d'un index détermine la méthode à utiliser pour le défragmenter et si cela doit se faire en ligne ou hors connexion.

Niveau de fragmentation	Méthode de défragmentation
Jusqu'à 10 %	Réorganiser (en ligne)
de 10 à 75 %	Réconstruire (en ligne)
75 % ou plus	Reconstruire (hors connexion)

Notez que l'utilisation des commandes DROP INDEX et CREATE INDEX n'est pas prise en charge sur les bases de données des produits SharePoint et technologies.

Vous pouvez réorganiser et reconstruire des index à l'aide de l'instruction SQL Server 2005 ALTER INDEX, l'Assistant Maintenance de SQL Server 2005, les instructions SQL Server 2000 DBCC INDEXDEFRAG et DBCC DBREINDEX ou l'Assistant Maintenance de SQL Server 2000. Cette rubrique présente uniquement les options de SQL Server 2005 en détail. Pour plus d'informations sur les options de SQL Server 2000, voir les ressources suivantes :

• https://technet.microsoft.com/fr-fr/virtualization/default.aspx

• https://go.microsoft.com/fwlink/?linkid=124883&clcid=0x40C

• Options de ligne de commande (https://go.microsoft.com/fwlink/?linkid=111127\&clcid=0x40C)

Utilisation de l'instruction ALTER INDEX

ALTER INDEX autorise un administrateur de base de données à effectuer des opérations de maintenance sur un index de table ou d'affichage existants. Il peut servir à désactiver, reconstruire et réorganiser des index ou, éventuellement, définir des options dans l'index. ALTER INDEX remplace les instructions de DBCC DBREINDEX et DBCC INDEXDEFRAG.

Dans la plupart des cas, vous pouvez reconstruire les index tandis que la base de données est en ligne, car une reconstruction des index en mode hors connexion n'offre pas vraiment d'intérêt. Toutefois, il est important de noter que lorsqu'un index est en cours de reconstruction, un verrou de table partagée est appliqué à la table pour empêcher l'exécution de toute opération à l'exception des opérations SELECT.Les bases de données des produits et technologies SharePoint utilisent des index spécifiquement organisés en clusters. Lorsqu'un index cluster est en cours de reconstruction, un verrou de table exclusif est appliqué à la table pour empêcher les utilisateurs finaux d'accéder à la table.

Vous pouvez personnaliser le script exemple suivant pour reconstruire tous les index sur une table.

USE Contoso_Content_1
GO
ALTER INDEX ALL ON [database_name. [ schema_name ] . | schema_name. ]table_or_view_name
REBUILD WITH (FILLFACTOR = 70, SORT_IN_TEMPDB = ON, ONLINE = ON,
STATISTICS_NORECOMPUTE = ON)
GO

Mention spéciale pour la base de données de création de rapports

Étant donné que nous supposons que les clients vont implémenter des rapports personnalisés basés sur des champs personnalisés et des données disponibles dans la base de données de création de rapports, nous recommandons d'appliquer les meilleures pratiques d'écriture T-SQL et de création d'index pour garantir une solution évolutive et de création de rapports de performances. Office Project Server 2007 n'indexe pas ces tables (générées dynamiquement) en dehors de la clé primaire. La Mise à jour d’infrastructure pour les produits serveur de Microsoft Office fournit des fonctionnalités supplémentaires. Pour plus d'informations, voir la section « Optimisations RDS pour les champs personnalisés » de l'article téléchargeable intitulé Publication de mise à jour de l'infrastructure Project 2007 pour serveur et client (https://go.microsoft.com/fwlink/?LinkId=121912, éventuellement en anglais).

Lorsque vous travaillez avec les services de support technique Microsoft client, un technicien du support technique peut vous demander de supprimer les index supplémentaires créés ou de supprimer toutes les colonnes supplémentaires ajoutées aux index existants. Cela est dû au fait que des index supplémentaires peuvent modifier les chemins d'accès des données et dans certaines cas entraîner des performances inattendues, ainsi que des problèmes de verrouillage ou de blocage.

Définir le facteur de remplissage pour un serveur

Le facteur de remplissage peut servir à optimiser le stockage de données et les performances d'index. Lorsque les index sont créés ou reconstruits, la valeur du facteur de remplissage (1 - 100) détermine le pourcentage d'espace sur chaque page niveau feuille qui peut être renseignée avec des données. L'espace restant est conservé pour une croissance future. Dans beaucoup de cas, le niveau par défaut du facteur de remplissage à l'échelle du serveur de 0 est optimal. Toutefois, pour Microsoft Office SharePoint Server 2007, un paramètre de 70 à l'échelle du serveur est optimal pour prendre en charge la croissance et réduire la fragmentation.

Il est déconseillé de définir le facteur de remplissage pour des tables ou des index individuels, même si cela est faisable.

Pour afficher la valeur du facteur de remplissage d'un ou plusieurs index, interrogez l'affichage de catalogue sys.indexes. Pour plus d'informations sur l'affichage, voir sys.indexes (Transact-SQL) (https://go.microsoft.com/fwlink/?linkid=128510\&clcid=0x40C).

Pour configurer la valeur du facteur de remplissage à l'échelle du serveur, utilisez la procédure système stockée sp_configure. Pour plus d’informations, voir spconfigure (Transact-SQL) (https://go.microsoft.com/fwlink/?linkid=128512\&clcid=0x40C).