sys.dm_tran_version_store
Возвращает виртуальную таблицу, в которой отображаются все записи версий в хранилище версий. Представление sys.dm_tran_version_store неэффективно, так как запрашивает все хранилище версий, которое может быть очень большим.
Каждая запись версии хранится в виде двоичных данных вместе с некоторыми сведениями о состоянии и отслеживании. Как и в таблицах базы данных, записи в хранилище версий хранятся в страницах размером 8192 байта. Если размер записи превышает 8192 байта, она разбивается на две различные записи.
Так как запись версии хранится в двоичном виде, не возникает проблем с разными параметрами сортировки из разных баз данных. Для поиска предыдущих версий строк в двоичном представлении, в котором они хранятся в хранилище версий, используется представление sys.dm_tran_version_store.
Синтаксис
sys.dm_tran_version_store
Возвращаемые таблицы
Имя столбца |
Тип данных |
Описание |
---|---|---|
transaction_sequence_num |
bigint |
Порядковый номер транзакции, формирующей версию записи. |
version_sequence_num |
bigint |
Порядковый номер версии записи. Значение является уникальным в рамках сформировавшей эту версию транзакции. |
database_id |
int |
Идентификатор базы данных версии записи. |
rowset_id |
bigint |
Идентификатор набора строк записи. |
status |
tinyint |
Указывает, была ли запись версии разбита на две записи. Если значение равно 0, запись хранится на одной странице. Если оно равно 1, запись разбивается на две записи, которые хранятся на двух различных страницах. |
min_length_in_bytes |
smallint |
Минимальная длина записи в байтах. |
record_length_first_part_in_bytes |
smallint |
Длина первой части записи версии в байтах. |
record_image_first_part |
varbinary(8000) |
Двоичный образ первой части записи версии. |
record_length_second_part_in_bytes |
smallint |
Длина второй части записи версии в байтах. |
record_image_second_part |
varbinary(8000) |
Двоичный образ второй части записи версии. |
Разрешения
Требует разрешения VIEW SERVER STATE на сервере.
Для просмотра столбцов record_image_first_part и record_image_second_part необходимо разрешение CONTROL SERVER. В противном случае эти столбцы вернут значения NULL.
Примеры
В следующем примере используется тестовый сценарий, в котором четыре параллельные транзакции, каждую из которых идентифицирует порядковый номер (XSN), выполняются в базе данных с параметрами ALLOW_SNAPSHOT_ISOLATION и READ_COMMITTED_SNAPSHOT, установленными в значение ON. Выполняются следующие транзакции:
XSN-57 — операция обновления с упорядочиваемым уровнем изоляции.
XSN-58 — то же, что и XSN-57.
XSN-59 — операция выборки с изоляцией моментального снимка.
XSN-60 — то же, что и XSN-59.
Выполняется следующий запрос.
SELECT
transaction_sequence_num,
version_sequence_num,
database_id rowset_id,
status,
min_length_in_bytes,
record_length_first_part_in_bytes,
record_image_first_part,
record_length_second_part_in_bytes,
record_image_second_part
FROM sys.dm_tran_version_store;
Ниже приводится результирующий набор.
transaction_sequence_num version_sequence_num database_id
------------------------ -------------------- -----------
57 1 9
57 2 9
57 3 9
58 1 9
rowset_id status min_length_in_bytes
-------------------- ------ -------------------
72057594038321152 0 12
72057594038321152 0 12
72057594038321152 0 12
72057594038386688 0 16
record_length_first_part_in_bytes
---------------------------------
29
29
29
33
record_image_first_part
--------------------------------------------------------------------
0x50000C0073000000010000000200FCB000000001000000270000000000
0x50000C0073000000020000000200FCB000000001000100270000000000
0x50000C0073000000030000000200FCB000000001000200270000000000
0x500010000100000002000000030000000300F800000000000000002E0000000000
record_length_second_part_in_bytes record_image_second_part
---------------------------------- ------------------------
0 NULL
0 NULL
0 NULL
0 NULL
Выход показывает, что транзакция XSN-57 создала три версии строк из одной таблицы, а XSN-58 — одну версию строки из другой таблицы.