Discussion :

[CoeurDeSQL]

Bonjour

J'ai affiché par une requête mes tables fragmentées.
Derrière je reconstruis mes index mais mon pourcentage de fragmentation, lorsque je relance mon select sur mes tables fragmentées, reste le même.

J'utilise pour info un sql 2008R2 standard.

Si quelqu'un a une idée... Merci

[Invité]

Quel est la taille de votre table ?
Si elle est petite, il n'est pas possible de réduire la fragmentation à 0 %.
Si vous voulez plus de détails, je vous invite à faire une recherche sur ce forum, le sujet a été traité il y a peu.

[Boubou2020]

le sujet a été traiter dans cette discution
il peuvent vous aider
http://www.developpez.net/forums/d15...xes-important/

[CoeurDeSQL]

bonjour

oui j'ai vu ce sujet mais j'avais un doute sur la réponse
quelle taille minimale doit avoir la table pour pouvoir la défragmenter, et que ce soit visible ? car en effet mon test se fait sur de toutes petites tables...

[SQLpro]

bonjour

oui j'ai vu ce sujet mais j'avais un doute sur la réponse
quelle taille minimale doit avoir la table pour pouvoir la défragmenter, et que ce soit visible ? car en effet mon test se fait sur de toutes petites tables...

Au moins 65 pages

A +

[Boubou2020]

sur ce piste je pause cette question
Quel est l'utilité d'interoger le taux de fragmentation des index pour les petits tables ?
autrement dit quel serai le gain si je fait leur défragmentation ?

[SQLpro]

sur ce piste je pause cette question
Quel est l'utilité d'interoger le taux de fragmentation des index pour les petits tables ?

faible

autrement dit quel serai le gain si je fait leur défragmentation ?

négligeable

En revanche, il est important que les statistiques soient à jour ! Une table peut être minime (quelques lignes) et changer de valeurs plusieurs milliers de fois par jour !

A +

[CoeurDeSQL]

donc l'idéal, un script peut reconstruire les index, ça ne paye pas de pain, car on ne connaît pas toujours la taille réelle des tables et on enchaîne avec un calcul de statistiques.
Merci pour l'info, je vais faire un batch dans ce sens-là

[SQLpro]

sauf si vous avez 5374632416532416231 très petites tables !!!!!!

A +

[Invité]

sauf si vous avez 5374632416532416231 très petites tables !!!!!!
A +

C'est pas possible ! Tu as une limite de 2 147 483 647 objets par bd

[SQLpro]

Tu peut donc avoir 3 496 103 378 944 000 000 index en tout...
1) tu peut monter jusqu'à 32560 bases par instance
2) tu peut mettre 50 instances par machine
3) un objet peut avoir jusqu'à 1000 index (relationnel) - sans compter les index XML et géo

A +

[aieeeuuuuu]

Tu peut donc avoir 3 496 103 378 944 000 000 index en tout...

oui, mais a raison de 5 secondes pour créer un index et en supposant qu'on s'y attèle jour et nuit sans relâche, il faudrait un peu plus de 500 milliards d'années... sacrée deadline !

[julien94320]

Tu peut donc avoir 3 496 103 378 944 000 000 index en tout...
1) tu peut monter jusqu'à 32560 bases par instance
2) tu peut mettre 50 instances par machine
3) un objet peut avoir jusqu'à 1000 index (relationnel) - sans compter les index XML et géo

A +

On joue ?

[SQLpro]

On joue ?

Je veut bien, mais c'est moi qui gagne !!!!

A +

[elsuket]

donc l'idéal, un script peut reconstruire les index, ça ne paye pas de pain, car on ne connaît pas toujours la taille réelle des tables et on enchaîne avec un calcul de statistiques.

Attention si vous exécutez la maintenance dans ce sens là, à ne maintenir que les statistiques de colonne.
En effet, le moteur profite du fait que la reconstruction (REBUILD, par REORGANIZE) nécessite la lecture complète des données correspondantes pour collecter la distribution des valeurs dans les colonnes participant à l'index, et construire la statistique. Ceci est d'ailleurs l'équivalent d'un UPDATE STATISTICS ... WITH FULLSCAN

@++