Hallo,
ich verwende SQL Server 2012 (SP3, CU6, Enterprise Edition) und habe eine Tabelle mit aktivierter Page Compression. Das Schema ist wie folgt:
CREATE TABLE [DETAILED_ARCHIVE] (
[DEVICE_ID] [uniqueidentifier] NOT NULL,
[LOG_DATETIME] [datetime2](2) NOT NULL,
[MEASURE_ID] [uniqueidentifier] NOT NULL,
[MEASURE_VALUE] [bigint] NULL,
CONSTRAINT [PK_DETAILED_ARCHIVE] PRIMARY KEY CLUSTERED
(
[DEVICE_ID] ASC,
[LOG_DATETIME] ASC,
[MEASURE_ID] ASC
) WITH (DATA_COMPRESSION = PAGE)
)
Für diese Tabelle soll nun Partitionierung auf monatlicher Basis eingerichtet werden. Für jede Partition habe ich eine Filegroup erstellt und eine entsprechende Partition-Function (auf Basis datetime2(2)) sowie ein Partition-Schema angelegt.
Versuche ich nun den Clustered-Index auf dem Partition-Schema neu anzulegen (mit DROP_EXISTING), womit die Tabelle partitioniert werden sollte, dann explodiert der Speicherplatzbedarf in den neuen Filegroups für die Partitionen, obwohl ich für alle Partitionen
weiterhin DATA_COMPRESSION = PAGE angebe.
Folgenden Befehl verwende ich:
CREATE UNIQUE CLUSTERED INDEX [PK_DETAILED_ARCHIVE] ON [DETAILED_ARCHIVE]
(
[DEVICE_ID] ASC,
[LOG_DATETIME] ASC,
[MEASURE_ID] ASC
)
WITH (DROP_EXISTING = ON, ONLINE = OFF, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON, FILLFACTOR = 100, DATA_COMPRESSION = PAGE)
ON [PS_DateTime_Monthly_Detailed]([LOG_DATETIME])
Die ursprüngliche Tabelle hat eine Größe von 160GB, die Größe der neuen Filegroups für die Partitionen ist inzwischen auf 590GB angewachsen und der Vorgang trotzdem noch nicht abgeschlossen.
Kann es sein, dass der neue partitionierte Clustered Index zunächst unkomprimiert angelegt wird und dann erst im Nachhinein oder durch einen Rebuild die Komprimierung angewendet würde? Ich werde mir das wohl nächste Woche mit einem kleineren Testdatensatz
nochmal genauer ansehen, aber vielleicht hat hier ja auch schon jemand eine Idee oder einen Hinweis.
Vielen Dank!
