5Go pour quelques lignes?!

[Sergejack]

Bonjour.

Je viens de "résoudre" un problème de façon plus que hasardeuse et j'aimerais comprendre ce qui a pu se passer pour éviter d'avoir ce problème à l'avenir.

J'ai une table de 53180 lignes qui pesait plus de 5Go (!!) ayant pour seul index un index non cluster.
J'ai aussi une table "sosie" ayant le même nombre de ligne dans une autre DB et qui elle pesait (et pèse encore) +/- 10Mo.

Impossible pour moi de comprendre l'espace faramineux occupé par la première table.
J'ai essayé de voir le taux de fragmentation (+/-7%) et j'ai "rebuild" l'index mais rien ne changeait.
J'ai même fait un DBCC CLEANTABLE et (à tout hasard) un UPDATEUSAGE.
Sans progrès pertinent.

J'ai donc fini par apporter à la table la correction de la plus significative des différence avec la table "sosie" de 10Mo : lui donner un index cluster.

J'ai donc transformer l'index non cluster en index cluster.
Et là, miracle (au sens propre ?!) : la base pèse 8Mo.


Je ne comprends pas comment l'absence d'un index cluster peut avoir causé ce problème.
Vous y comprenez quelque chose, vous ?

[Jinroh77]

Quelle est la version de l'instance ?
C'est un problème que l'on retrouve régulièrement.
J'ai déjà eu ça sur un SQL 2000 que j'ai effectivement corrigé en ajoutant un cluster.
Quelques

infos

infos

.

EDIT : loupé dans l'URL

[Sergejack]

C'est un 2005 SP 3.

[Jinroh77]

Voici la kb.

[Sergejack]

Ce n'est pas ça.

Les 5Go étaient la partie utilisée (!!) de la table.
Aucun shrink n'y changeait quoi que ce soit.


J'ai l'impression que cette question est bien obscure ^^

[mikedavem]

Difficile de répondre maintenant que le problème est résolu. On ne peut faire que des suppositions.

Un ajout puis une suppression de plusieurs colonnes fixes par exemple peuvent considérablement augmenter le stockage d'une table sans pour autant libérer l'espace. La construction ou reconstruction d'un index cluster permet de résoudre ce genre de problème.

++