2009-06-05 7 views
3

J'ai une grande table dans SQL Server 2005 qui prend environ 3,5 Go d'espace (selon sp_spaceused). Il a 10 millions d'enregistrements et plusieurs index. J'ai juste laissé tomber un tas de colonnes, de sorte que la longueur de l'enregistrement a été réduite à la moitié, et à ma grande surprise, il a fallu zéro temps pour le faire. De toute évidence, sp_spaceused signalait toujours le même espace occupé, le serveur SQL n'avait pas vraiment fait quoi que ce soit lors de la suppression des colonnes, autre que de les marquer comme "abandonné". J'ai donc déplacé toutes les données de cette table dans une autre nouvelle table, je l'ai tronquée et j'ai déplacé toutes les données afin qu'elles soient toutes reconstruites.SQL Server 2005: espace disque pris par les colonnes supprimées

Maintenant, après cela, les données prennent 2,8 Go, ce qui est moins qu'auparavant, mais je m'attendais à une baisse plus importante.

Est-il possible que le fait que cette table ait à l'origine ces colonnes laisse encore quelque chose?

La tronçonnait-elle pas assez? Devrais-je le laisser tomber et le créer à nouveau avec le jeu de colonnes plus petit?

Ou est-ce que les données prennent vraiment 2,8 Go?

Merci!

Répondre

2

Comment avez-vous calculé que "prévu une plus grande baisse"? Notez que les données sont fournies dans des pages de 8 Ko, ce qui signifie que même si les lignes individuelles sont plus petites, cela ne signifie pas toujours que vous avez besoin de moins de pages pour les stocker. Par exemple (un exemple extrême), si vos lignes étaient de 7,5 Ko chacune, une seule ligne par page correspondrait. Vous déposez quelques colonnes, votre rangée est 5K, mais c'est toujours une rangée par page.

4

Vous devrez reconstruire l'index cluster (en supposant que vous en ayez un - par défaut, votre clé primaire est la clé en cluster).

ALTER INDEX (your clustered index) ON TABLE (your table) REBUILD 

Les données sont vraiment le niveau des feuilles de votre index cluster - une fois que vous reconstruisez, il sera « compactée » et les lignes doivent être stockées sur les pages de données beaucoup moins, ce qui réduit la taille de votre base de données, aussi.

Si cela ne vous aide pas du tout, vous devrez peut-être également exécuter un DBCC SHRINKDATABASE sur votre base de données pour vraiment récupérer l'espace. Ces deux étapes ensemble devraient vraiment vous obtenir un fichier de base de données plus petit!

Marc

+0

Et juste en supposant que c'est une table de 3,5 Go, cette opération serait bien avec le système en cours d'exécution? – marquito

+1

@marquito: il faudra des temps d'arrêt pour terminer cette opération - bien sûr - pas de problème. –

+0

merci, @marc_s. Comme je fais face à la même situation, il est bon de savoir que je devrai attendre pour exécuter la procédure ou faire face aux conséquences. :) – marquito

Questions connexes