Ho una tabella di registro generica, circa 5m di righe.
C'è un campo "fortemente tipizzato" che memorizza il tipo di evento e un gruppo di colonne "tipicamente losco" che contengono dati rilevanti per l'evento. Cioè, il significato di quelle colonne "digitate male" dipende dal tipo di evento.
Queste colonne sono definite come:
USER_CHAR1 nvarchar(150) null,
USER_CHAR2 nvarchar(150) null,
USER_CHAR3 nvarchar(150) null,
USER_CHAR4 nvarchar(150) null,
USER_CHAR5 nvarchar(150) null,
USER_INTEGER1 int null,
USER_INTEGER2 int null,
USER_INTEGER3 int null,
USER_INTEGER4 int null,
USER_INTEGER5 int null,
USER_FLAG1 bit null,
USER_FLAG2 bit null,
USER_FLAG3 bit null,
USER_FLAG4 bit null,
USER_FLAG5 bit null,
USER_FLOAT1 float null,
USER_FLOAT2 float null,
USER_FLOAT3 float null,
USER_FLOAT4 float null,
USER_FLOAT5 float null
Le colonne 1 e 2 in ciascun tipo sono molto utilizzate, ma a partire dal numero 3, pochissimi tipi di eventi fornirebbero così tante informazioni. Ho quindi voluto contrassegnare le colonne 3-5 in ciascun tipo come SPARSE
.
Ho fatto prima alcune analisi e ho visto che, in effetti, almeno l'80% dei dati in ciascuna di quelle colonne lo è null
, e in circa il 100% dei dati lo è null
. Secondo la tabella della soglia di risparmio del 40% , SPARSE
sarebbe una grande vittoria per loro.
Quindi sono andato e applicato SPARSE
alle colonne 3-5 in ciascun gruppo. Ora la mia tabella occupa circa 1,8 GB di spazio dati come riportato da sp_spaceused
, mentre prima di risparmiare era di 1 GB.
Ci ho provato dbcc cleantable
, ma non ha avuto effetto.
Quindi dbcc shrinkdatabase
, nessun effetto neanche.
Perplesso, ho rimosso SPARSE
e ripetuto la dbcc
s. La dimensione della tabella è rimasta a 1,8 GB.
Cosa dà?
rowid int not null identity(1,1) primary key clustered
.