Déclencheurs et informations de version de ligne

Dans quelles circonstances les triggersurs de table entraîneront-ils l'ajout de 14 octets à la fin de la ligne pour le versionnement des lignes?

La section "Espace utilisé dans les lignes de données" sur cette page indique clairement "Chaque ligne de database peut utiliser jusqu'à 14 octets à la fin de la ligne pour les informations de versionnement de ligne … Ces 14 octets sont ajoutés la première fois que la ligne est modifiée. ou quand une nouvelle ligne est insérée, dans l'une de ces conditions … La table a un triggersur . "

Cela n'est pas arrivé dans mon test (script ci-dessous). Lorsque je regarde la page de données, je ne vois aucune des informations de version qui apparaissent sous l'isolation de l'instantané. Suis-je sûr de supposer que les lignes sur les pages de données ne seront jamais gonflées par ces 14 octets juste parce qu'un triggersur est sur la table? Sinon, quand cela arrivera-t-il?

CREATE DATABASE D2 GO ALTER DATABASE D2 SET ALLOW_SNAPSHOT_ISOLATION OFF USE D2; GO CREATE TABLE T1 ( F1 INT IDENTITY(1,1) PRIMARY KEY, F2 INT, V1 VARCHAR(100) ) INSERT INTO T1 SELECT TOP 80 ROW_NUMBER() OVER (ORDER BY (SELECT 0)) AS F2, REPLICATE(CHAR((ROW_NUMBER() OVER (ORDER BY (SELECT 0) -1) % 26) + ASCII('A')),100) AS V1 FROM sys.all_columns GO CREATE TRIGGER TR ON T1 AFTER INSERT,DELETE,UPDATE AS BEGIN SET NOCOUNT ON; SELECT * FROM inserted END GO UPDATE T1 SET F2=F2+1 GO DECLARE @DBCCPAGE nvarchar(100) SELECT TOP 1 @DBCCPAGE = 'DBCC PAGE(''D2'',' + CAST(file_id AS VARCHAR) + ',' + CAST(page_id AS VARCHAR) + ',3)' FROM T1 CROSS APPLY sys.fn_PhysLocCracker(%%physloc%%) DBCC TRACEON(3604) EXEC (@DBCCPAGE) GO

Paul Randal a un article pratique intitulé: "Dans le moteur de stockage: quand les balises de version sont-elles ajoutées?" . L'indice est dans le titre 🙂

Tout est expliqué dans cet article de blog .

La raison pour laquelle je n'ai pas vu de pointeurs de version dans mon test d'origine est due à la définition de la table.

Il existe une optimization des performances qui peut éviter d'append des informations de versionnement de ligne, mais uniquement si la table ne peut pas générer d'unités d'allocation ROW_OVERFLOW ou LOB . Cela signifie que la définition de la table ne doit pas autoriser les objects LOB ou la possibilité de déplacement de colonnes de longueur variable hors ligne. La taille réelle des données stockées est sans importance – c'est la taille potentielle qui count.

Si je change la définition de la table en

 CREATE TABLE T1 ( F1 INT IDENTITY(1,1) PRIMARY KEY, F2 INT, V1 VARCHAR(1000), V2 VARCHAR(8000) NULL )

Donc, potentiellement, il ne pourrait pas tout en ligne, alors je vois des pointeurs de version dans les résultats DBCC . par exemple comme ci-dessous.

 Record Type = PRIMARY_RECORD Record Atsortingbutes = NULL_BITMAP VARIABLE_COLUMNS VERSIONING_INFO Record Size = 133 Memory Dump @0x63A4CC92 00000000: 70000c00 03000000 04000000 04004801 †p.............H. 00000010: 00770044 44444444 44444444 44444444 †.w.DDDDDDDDDDDDD 00000020: 44444444 44444444 44444444 44444444 †DDDDDDDDDDDDDDDD 00000030: 44444444 44444444 44444444 44444444 †DDDDDDDDDDDDDDDD 00000040: 44444444 44444444 44444444 44444444 †DDDDDDDDDDDDDDDD 00000050: 44444444 44444444 44444444 44444444 †DDDDDDDDDDDDDDDD 00000060: 44444444 44444444 44444444 44444444 †DDDDDDDDDDDDDDDD 00000070: 44444444 444444c8 7b000001 000500b8 †DDDDDDDÈ{......¸ 00000080: 00000000 00††††††††††††††††††††††††††..... Version Information = Transaction Timestamp: 184 Version Pointer: (file 1 page 31688 currentSlotId 5)