Estimation du taux de fragmentation des index

Bonjour à tous,

J'effectue plusieurs tests actuellement afin d'obtenir un taux de fragmentation de mes tables suites à des mouvements de données.
Les mesures sont récupérées après REBUILD puis une insertion d'un lot de données #1 et une insertion d'un lot de données #2 qui reproduisent mes mouvements du weekend.


Lire #4 pour la fin de l'histoire

et alors ???

J'ai été présomptueux sur le résultat de ma requête, je reformule tout ça demain matin.

Re bonjour,

Désolé d'avoir créé un message incomplet.
Voici les requêtes que j'utilise en ce moment pour analyser mes indexs. Suite à mon message "Réindexation" sur ce même forum, j'ai voulu évaluer pourquoi et comment mes index se fragmentaient, notamment à quelle vitesse.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41

--- Requête #1 utilisée régulièrement pour visualiser l'effet des reconstructions et qui d'après ce que j'ai lu était utilisée sous SQL2000---- USE MaBase DBCC SHOWCONTIG ('MaTable'); GO   ---- résultat #1---- DBCC SHOWCONTIG analyse la table 'MaTable'... Table*: 'MaTable' (494390022)*; index ID*: 1, base de données ID*: 5 Analyse du niveau TABLE effectuée. - Pages analysées................................: 1070834 - Extensions analysées..............................: 133867 - Commutateurs d'extension..............................: 134456 - Moyenne des pages par extension........................: 8.0 - Densité d'analyse [meilleure valeur:valeur réelle].......: 99.55% [133855:134457] - Fragmentation d'analyse logique..................: 0.19% - Fragmentation d'analyse d'extension...................: 21.67% - Moyenne d'octets libres par page.....................: 554.6 - Densité de page moyenne (complète).....................: 93.15% Exécution de DBCC terminée. Si DBCC vous a adressé des messages d'erreur, contactez l'administrateur système.   ---- requête #2 utilisée lors de nos plans de maintenance pour le calcul des index depuis SQL2005   DECLARE @maxfrag Int SELECT @maxfrag = 5 SELECT object_id, index_id, avg_fragmentation_in_percent FROM sys.dm_db_index_physical_stats (DB_ID('MaBase') ,OBJECT_ID('MaTable') ,NULL ,NULL ,'DETAILED') WHERE avg_fragmentation_in_percent > CONVERT(CHAR(2),@maxfrag) and Index_id > 0 ORDER BY CONVERT(DECIMAL(9,2),avg_fragmentation_in_percent) DESC;   ---- résultat #2---- object_id index_id avg_fragmentation_in_percent 494390022 1 96,2962962962963 494390022 2 50 494390022 1 11,5730337078652 494390022 2 10,8540925266904

---

Les index de la table sont analysés et sortent deux résultats différents. Or avec le code #2 certains de mes index semblent continuellement fragmentés (en fonction de la table et de leur utilisation évidemment).
Du coup la reconstruction parait inefficace en fonction de la méthode d'analyse (visible sur la #1 et mitigé sur la #2).

Je dois mal interpréter ces résultats, est ce le cas ?

tout dépend de la taille d'un index. La fragmentation est calculée à l'extent. Un index de 8 pages ou moins sera donc toujours fragmenté !

A +

Bonjour,

Mais à partir de combien de pages peut-on considérer que le taux de fragmentation d'un index devient "représentatif" et appel à une maintenance (Rebuild ou Reorganize) ?

Bonjour,

C'est à vous de le mesurer.
Il est clair que pour un index comme celui que vous montrez, de 133867 extents, il est nécessaire d'avoir une fragmentation faible pour avoir de bonnes performances.
Pour des indexes dont le nombre de pages | extents est faible, vous pouvez considérer qu'en dessous de 25% de fragmentation, vous pouvez les réorganiser, et pour un pourcentage sensiblement supérieur, vous pouvez les reconstruire.
Mais là encore c'est purement indicatif.

Je vois que vous êtes en version 2005, donc ne vous fatiguez plus à mesurer la fragmentation de vos indexes avec la commande DBCC SHOWCONTIG : utilisez les fonction et vue de gestion dynamique sys.dm_db_index_physical_stats et sys.dm_db_index_usage_stats ;)

@++ ;)