J'ai une table de log générique, environ 5m de lignes.
Il y a un champ "fortement typé" qui stocke le type d'événement, et un tas de colonnes "losely typées" qui contiennent des données pertinentes pour l'événement. C'est-à-dire que la signification de ces colonnes "typées losely" dépend du type de l'événement.
Ces colonnes sont définies comme:
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
Les colonnes 1 et 2 de chaque type sont largement utilisées, mais à partir du numéro 3, très peu de types d'événements fourniraient autant d'informations. J'ai donc souhaité marquer les colonnes 3 à 5 de chaque type comme SPARSE
.
J'ai d'abord fait une analyse et j'ai vu qu'en effet, au moins 80% des données dans chacune de ces colonnes le sont null
, et dans environ 100% des données null
. Selon le tableau du seuil d'économie de 40% , ce SPARSE
serait une énorme victoire pour eux.
Je suis donc allé et appliqué SPARSE
aux colonnes 3-5 dans chaque groupe. Maintenant, ma table prend environ 1,8 Go dans l'espace de données, comme indiqué par sp_spaceused
, alors qu'avant d'économiser, elle était de 1 Go.
J'ai essayé dbcc cleantable
, mais cela n'a eu aucun effet.
Ensuite dbcc shrinkdatabase
, aucun effet non plus.
Intrigué, j'ai retiré SPARSE
et répété le par dbcc
. La taille de la table est restée à 1,8 Go.
Ce qui donne?
rowid int not null identity(1,1) primary key clustered
.