Триггеры и информация о версиях строк

Question

При каких обстоятельствах триггеры таблиц приводят к добавлению 14 байтов в конец строки для контроля версий строк?

Раздел «Пробел, используемый в строках данных» на этой странице состояния "Каждая строка базы данных может использовать до 14 байтов в конце строки для информации о версиях строки ... Эти 14 байтов добавляются при первом изменении строки или при вставке новой строки при любом из этих условий... В таблице есть триггер . "

В моем тесте такого не было (сценарий ниже).При просмотре страницы данных я не вижу никакой информации о версиях, которая появляется под изоляцией моментального снимка.Могу ли я с уверенностью предположить, что строки на страницах данных никогда не будут раздуты этими 14 байтами только потому, что триггер находится на таблице?Если нет, то когда это произойдет?

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

Answer 1

Это все объясняется в этом сообщении в блоге .

Причина, по которой я не видел указателей контроля версий в моем исходном тесте, связана с определением таблицы.*

Существует оптимизация производительности, которая позволяет избежать добавления информации о версиях строк, но только если таблица не может сгенерировать ROW_OVERFLOW или LOB единиц распределения.Это означает, что определение таблицы не должно учитывать большие объекты или возможность перемещения столбцов переменной длины за пределы строки.Фактический размер хранимых данных не имеет значения - это потенциальный размер, который имеет значение.

Если я изменю определение таблицы на

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

, так что потенциально это может непоместиться в строку, тогда я вижу указатели версий в результатах DBCC.например, как показано ниже.

Record Type = PRIMARY_RECORD         Record Attributes =  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)

Answer 2

У Пола Рэндала есть удобная статья под названием: «Внутри механизма хранения: когда добавляются теги контроля версий?» .Подсказка есть в заголовке: -)