sys.dm_tran_version_store (Transact-SQL)
S’applique à : SQL ServerAzure SQL Database Azure SQL Managed Instance
Retourne une table virtuelle qui affiche tous les enregistrements de version dans la banque des versions. sys.dm_tran_version_store est inefficace pour s’exécuter, car il interroge l’intégralité du magasin de versions, et le magasin de versions peut être très volumineux.
Chaque enregistrement avec contrôle de version est stocké sous forme de données binaires, avec des informations de suivi ou d'état. À l'instar des enregistrements des tables de la base de données, ceux de la banque des versions sont stockés dans des pages de 8 192 octets. Si un enregistrement excède ces 8 192 octets, il est réparti sur deux enregistrements.
Comme l'enregistrement avec contrôle de version est stocké sous forme binaire, cela ne pose pas de problème avec les différents classements des différentes bases de données. Utilisez sys.dm_tran_version_store pour rechercher les versions précédentes des lignes dans la représentation binaire telle qu’elles existent dans le magasin de versions.
Syntaxe
sys.dm_tran_version_store
Table retournée
Nom de la colonne | Type de données | Description |
---|---|---|
transaction_sequence_num | bigint | Numéro de séquence de la transaction qui produit la version de l'enregistrement. |
version_sequence_num | bigint | Numéro de séquence de l'enregistrement avec version. Cette valeur est unique dans la transaction produisant la version. |
database_id | int | ID de base de données de l'enregistrement avec contrôle de version. Dans Azure SQL Database, les valeurs sont uniques au sein d’une base de données unique ou d’un pool élastique, mais pas dans un serveur logique. |
rowset_id | bigint | ID d'ensemble de lignes de l'enregistrement. |
statut | tinyint | Indique si un enregistrement avec version a été réparti sur deux enregistrements. Si la valeur est 0, l'enregistrement est stocké sur une seule page. Si la valeur est 1, l'enregistrement est réparti sur deux enregistrements, lesquels sont stockés sur deux pages différentes. |
min_length_in_bytes | smallint | Longueur minimale de l'enregistrement, en octets. |
record_length_first_part_in_bytes | smallint | Longueur de la première partie de l'enregistrement avec contrôle de version, en octets. |
record_image_first_part | varbinary(8000) | Image binaire de la première partie de l'enregistrement avec contrôle de version. |
record_length_second_part_in_bytes | smallint | Longueur de la deuxième partie de l'enregistrement avec contrôle de version, en octets. |
record_image_second_part | varbinary(8000) | Image binaire de la deuxième partie de l'enregistrement avec contrôle de version. |
autorisations
Sur SQL Server et SQL Managed Instance, l’autorisation VIEW SERVER STATE
est requise.
Sur les objectifs de service SQL Database Basic, S0 et S1, et pour les bases de données dans des pools élastiques, le compte d’administrateur du serveur, le compte d’administrateur Microsoft Entra ou l’appartenance au ##MS_ServerStateReader##
rôle serveur est requis. Sur tous les autres objectifs de service SQL Database, l’autorisation VIEW DATABASE STATE
sur la base de données ou l’appartenance au rôle serveur ##MS_ServerStateReader##
est requise.
Autorisations pour SQL Server 2022 (et versions plus récentes)
Nécessite l’autorisation VIEW SERVER PERFORMANCE STATE sur le serveur.
Exemples
L'exemple suivant illustre un scénario de test dans lequel quatre transactions simultanées, chacune étant identifiée par un numéro de séquence de transaction, sont exécutées dans une base de données où les options ALLOW_SNAPSHOT_ISOLATION et READ_COMMITTED_SNAPSHOT sont définies à ON. Les transactions suivantes sont exécutées :
XSN-57 est une opération Update exécutée avec le niveau d'isolement sérialisable.
XSN-58 est identique à XSN-57.
XSN-59 est une opération Select exécutée avec le niveau d'isolement d'instantané.
XSN-60 est identique à XSN-59.
La requête suivante est exécutée :
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;
Voici le jeu de résultats obtenu.
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
Le résultat indique que XSN-57 a créé trois versions de ligne à partir d'une table et que XSN-58 a créé une version de ligne à partir d'une autre table.
Voir aussi
Fonctions et vues de gestion dynamique (Transact-SQL)
Fonctions et vues de gestion dynamique relatives aux transactions (Transact-SQL)