Pourquoi mes index non cluster utilisent-ils plus d'espace lorsque je supprime des lignes?
J'ai une grande table avec 7,5 milliards de lignes et 5 index. Lorsque je supprime environ 10 millions de lignes, je remarque que les index non clusterisés semblent augmenter le nombre de pages sur lesquelles ils sont stockés.
J'ai écrit une requête contre dm_db_partition_stats pour signaler la différence (après - avant) dans les pages:
Index 1 est l'index clusterisé, Index 2 est la clé primaire. Les autres sont non clusterisés et non uniques.
Pourquoi les pages augmentent-elles sur ces index non groupés?
Je m'attendais à ce que les chiffres restent au pire les mêmes.
Je constate que les compteurs de performances signalent une augmentation des sauts de page pendant la suppression.
Lors de la suppression, l'enregistrement fantôme doit-il passer à une autre page? Est-ce que cela a à voir avec les "uniques"?
Nous sommes en train de déployer RCSI, mais pour l'instant, RCSI est désactivé.
Il s'agit d'un nœud principal dans un groupe de disponibilité. Je sais que l'instantané est utilisé d'une manière ou d'une autre sur les secondaires. Je serais surpris si cela était pertinent. J'ai l'intention de creuser dans ce (en regardant la sortie de la page dbcc) pour en savoir plus. Espérons que quelqu'un a vu quelque chose de similaire.
Un scénario possible qui m'amuse beaucoup:
- Les lignes ont été écrites à l'origine lorsque la base de données n'avait pas activé la lecture de l'instantané validé (RCSI), l'isolement de l'instantané (SI) ou les groupes de disponibilité (AG).
- RCSI ou SI a été activé ou la base de données a été ajoutée à un groupe de disponibilité
- Pendant les suppressions, un horodatage de 14 octets a été ajouté aux lignes supprimées pour prendre en charge les lectures RCSI/SI/AG
Étant donné que ce serveur est un serveur principal dans un AG, il est affecté tout comme les secondaires. Les informations de version sont ajoutées sur le primaire - les pages de données sont exactement les mêmes sur les primaires et les secondaires. Les secondaires exploitent le magasin de versions pour effectuer leurs lectures pendant la mise à jour des lignes par l'AG, mais les secondaires n'écrivent pas leurs propres versions de l'horodatage sur la page. Ils héritent juste les versions du travail du primaire.
Pour démontrer la croissance, j'ai pris l'exportation de la base de données Stack Overflow (qui n'a pas activé RCSI) et créé un tas d'index sur la table Posts. J'ai vérifié la taille des index avec sp_BlitzIndex @Mode = 2 (copié/collé dans une feuille de calcul et nettoyé un peu pour maximiser la densité des informations):
J'ai ensuite supprimé environ la moitié des lignes:
BEGIN TRAN;
DELETE dbo.Posts WHERE Id % 2 = 0;
GO
De manière amusante, alors que les suppressions se produisaient, le fichier de données augmentait pour accueillir les horodatages aussi! Le rapport d'utilisation du disque SSMS montre les événements de croissance - voici juste le haut pour illustrer:
(Je dois aimer une démo où les suppressions font grandir la base de données.) Pendant la suppression, j'ai exécuté à nouveau sp_BlitzIndex. Notez que l'index cluster a moins de lignes, mais sa taille a déjà augmenté d'environ 1,5 Go. Les index non cluster sur AcceptedAnswerId ont considérablement augmenté - ce sont des index sur une petite valeur qui est généralement nulle, donc leur taille d'index a presque doublé!
Je n'ai pas à attendre la fin de la suppression pour le prouver, alors je vais arrêter la démo ici. Le point étant: lorsque vous effectuez de grandes suppressions sur une table qui a été implémentée avant l'activation de RCSI, SI ou AG, les index (y compris le cluster) peuvent en fait augmenter pour s'adapter à l'ajout de l'horodatage du magasin de versions.