Discussion :

[Mothership]

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

[SQLpro]

et alors ???

[Mothership]

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

[Mothership]

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 :

Sélectionner tout - Visualiser dans une fenêtre à part

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 ?

[SQLpro]

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 +

[dily0403]

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