DBCC CLEANTABLE befreit nicht genutzten Speicherplatz

Question

Ich habe etwa 300 Tabellen mit je 5,5kk Zeilen. Eine der Zeilen verwendet nvarchar (128) als Datentyp (SQL Server 2012).
Wir haben uns entschieden, dies in int zu ändern und FK zur Dictionary-Tabelle mit allen nvarchars hinzuzufügen.

Nachdem ich alles getan habe, habe ich die nvarchar Spalte entfernt, aber die Größe der Tabellen blieb gleich. Ich habe DBCC CLEANTABLE verwendet und die Indizes neu erstellt, um freien Speicherplatz zurückzugewinnen, aber die Größe der Tabelle ändert sich immer noch nicht.

Bis jetzt ist die einzige Möglichkeit, die ich gefunden habe, alle Daten in die neue Tabelle zu kopieren.

Frage: Was fehlt mir hier? Warum wird der Raum immer noch als gebraucht markiert und ich kann nicht durch Schrumpfen oder CREANTABLE-Befehl frei werden?

Vielen Dank!

Answ: Sieht aus wie die Antwort war ziemlich einfach und ich konnte es wegen meines Mangels an Wissen nicht finden. Das Hauptproblem hier war Haufen Fragmentierung. Diese Abfrage arbeitete für mich:

ALTER TABLE [TABLE_NAME] REBUILD 

Ich bin nicht sicher, dass es der beste Weg ist, aber zumindest ist es eine Arbeitsgruppe ein.

Edited1: Sorry, ich glaube, ich vergaß zu erwähnen - ich Index auf dem Textfeld gruppierten hatte, also musste ich den Index entfernen, um in der Lage zu entfernen, tatsächlich das Feld. Jetzt habe ich keine Indizes.

Edited2:

alte Tabelle:

CREATE TABLE [dbo].[Data_](
    [ID] [bigint] PRIMARY KEY IDENTITY(1,1) NOT NULL, 
    [Text] [nvarchar](128) NOT NULL, 
    [Category] [tinyint] NOT NULL, 
    [Country] [nvarchar](2) NOT NULL, 
    [ImportTimestamp] [date] NOT NULL 
) 

neue Tabelle:

CREATE TABLE [dbo].[Data_New](
    [ID] [int] PRIMARY KEY IDENTITY(1,1) NOT NULL, 
    [Category] [tinyint] NOT NULL, 
    [Country] [nvarchar](2) NOT NULL, 
    [TextID] [int] NOT NULL) 

ALTER TABLE [dbo].[Data_New] WITH CHECK ADD FOREIGN KEY([TextID]) 
REFERENCES [dbo].[Dictionary] ([Id]) 

Copy-Skript:

INSERT INTO Data_New 
     ([Category] 
     ,[Country] 
     ,[TextID]) 
SELECT 
     [Category] 
     ,[Country] 
     ,[TextID] 
    FROM Data_ 

Answer 1

Wenn Sie kümmern sich nicht um das Problem zu verstehen und wollen einfach nur von den Index dann loszuwerden Wiederaufbau ist ein sicherer Weg, alle Abfälle zu entfernen. Dies liegt daran, dass eine Indexrekonstruktion die physischen Datenstrukturen neu erstellt. Was auch immer der alte Index enthielt, spielt keine Rolle mehr.

Beim Vergleich mit CLEANTABLE sind Kompromisse erforderlich. Wenn eine Neuerstellung den Job für Sie erledigt, würde ich das immer tun, weil es eine so komplette Lösung ist.

Wenn ich "index" in dieser Antwort sage, meine ich alle physischen Strukturen, die eine der Spalten enthalten, die Ihnen wichtig sind. Das können B-Tree-Indizes oder der Heap sein, auf dem die Tabelle basiert.

Answer 2

Sind Sie su Soll die Tabelle wegen dieser Spaltenänderung kleiner werden? nvarchar (128) bedeutet nicht, dass SQL Server 128 Byte (+2) zum Speichern von Daten zuweist, z. B. die Zeichenfolge 'test'. Die Zeichenfolge 'test' benötigt nur 6 Bytes. Vielleicht müssen Sie zunächst freien Speicherplatz in der Tabelle überprüfen:

SELECT 
    t.NAME AS TableName, 
    s.Name AS SchemaName, 
    p.rows AS RowCounts, 
    SUM(a.total_pages) * 8 AS TotalSpaceKB, 
    SUM(a.used_pages) * 8 AS UsedSpaceKB, 
    (SUM(a.total_pages) - SUM(a.used_pages)) * 8 AS UnusedSpaceKB 
FROM 
    sys.tables t 
INNER JOIN  
    sys.indexes i ON t.OBJECT_ID = i.object_id 
INNER JOIN 
    sys.partitions p ON i.object_id = p.OBJECT_ID AND i.index_id = p.index_id 
INNER JOIN 
    sys.allocation_units a ON p.partition_id = a.container_id 
LEFT OUTER JOIN 
    sys.schemas s ON t.schema_id = s.schema_id 
WHERE 
    t.NAME = 'TABLE_NAME' 
    AND t.is_ms_shipped = 0' 
    AND i.OBJECT_ID > 255 
GROUP BY 
    t.Name, s.Name, p.Rows 
ORDER BY 
    t.Name