2009-06-02 5 views
1

J'ai hérité d'une base de données avec des tables contenant de nombreuses colonnes nvarchar. Les tables devenaient assez grandes, et j'ai décidé de changer les types de données en varchar pour couper le stockage parce que nous n'utilisons pas de caractères internationaux. L'espace de données sur la table (clic droit, puis "Propriétés") n'a pas changé. Cependant, si je copie cette table dans une nouvelle table, l'espace de données utilisé là est environ 60% de la taille de la table d'origine.Récupérer de l'espace dans la table SQL 2005 après avoir modifié le type de données?

J'ai utilisé 'DBCC CLEANTABLE' dans d'autres instances pour récupérer de l'espace après avoir déposé une colonne de longueur variable. Mais cela ne semble pas fonctionner lors du CHANGEMENT de types de données de longueur variable. Comment puis-je récupérer cet espace?

Pour ceux qui ne sont pas familiers avec DBCC CLEANTABLE, MS a un bon article avec un exemple de code contre AdventureWorks.

http://msdn.microsoft.com/en-us/library/ms174418(SQL.90).aspx

+0

L'espace est-il si important que vous ayez à vous soucier de telles choses? –

Répondre

4

Reconstruire l'index cluster si le DBCC ne fonctionne pas.

+0

@gbn +1: Cela fera l'affaire. –

+0

Cela semblait faire l'affaire! Merci. –

0

Comme BOL spécifie CLEANABLE uniquement les pages libres de colonnes de longueur variable. Votre base de données est probablement fragmentée, ce qui se produit normalement pendant le fonctionnement de la base de données. Il semble que SQL Server considère une page fragmentée comme étant en cours d'utilisation et ne l'affiche pas comme espace disponible (btw sp_spaceused appelle cet espace non alloué)

Vous pouvez voir à quel point vos tables sont fragmentées avec DBCC SHOWCONTIG. En reconstruisant tous les index de votre base de données, vous allez vous débarrasser de la fragmentation, ce qui se passe à peu près lorsque vous copiez ces données ailleurs.

Questions connexes