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
.Réponses:
Vous devez reconstruire l'index cluster après avoir rendu les colonnes éparses. Les colonnes supprimées existent toujours dans la page de données jusqu'à ce que vous le fassiez comme vous pouvez le voir avec une requête sur
sys.system_internals_partition_columns
ou en utilisantDBCC PAGE
la source