226
Chapitre 7. Transactions et verrous
WHERE nombre = 2;
SELECT session_id, transaction_id, elapsed_time_seconds
FROM sys.dm_tran_active_snapshot_database_transactions;
ROLLBACK;
Pourquoi cela ? Afin de permettre, dans la même transaction, d’éviter les lectures
non renouvelables et les lectures fantômes. De fait, ce niveau d’isolation correspond
à un niveau SERIALIZABLE, sans le verrouillage. Une requête dans sys.dm_tran_locks
ne montre aucun verrou maintenu. Les autres transactions pourront donc modifier
la ligne WHERE nombre = 2 à loisir. Durant toute la durée de la transaction, notre session en isolation SNAPSHOT verra la version de ligne équivalant à la première lecture.
Mais que se passera-t-il si nous cherchons à modifier ensuite la ligne dans notre
transaction ? Imaginons qu’après avoir exécuté le SELECT précédent, une autre session a mis à jour la ligne de dbo.testSnapshot, WHERE nombre = 2. Pourrons-nous à
notre tour effectuer un UPDATE, basé sur une version de ligne précédant la mise à jour
externe ? Non. Au moment de l’UPDATE dans notre transaction, un conflit sera
détecté, et une erreur sera retournée : la cohérence des mises à jour est toujours
garantie, pour nous protéger contre les lost updates. Le mode d’isolation SNAPSHOT est
donc à proprement parler un mode de verrouillage optimiste : les données lues sont
conservées sans verrouillage, avec la supposition qu’il y a peu de probabilité qu’un
conflit apparaisse.
Compteurs de performances
Ces compteurs vous donnent une visibilité sur les statistiques du niveau d’isolation snapshot :
MSSQL:Transactions\Longest Transaction Running Time, MSSQL:Transactions\Snapshot Transactions, MSSQL:Transactions\Update conflict ratio.
Identification du niveau d’isolation
Vous pourriez avoir envie de savoir dans quel niveau d’isolation se trouve votre
session, ou une autre session en cours d’exécution. En SQL Server 2000, la
commande DBCC USEROPTIONS était votre seul salut. Cette commande retourne un jeu
de résultats comportant deux colonnes : [Set Option] et Value. Pour la manipuler en
programmation, vous deviez insérer le résultat dans une table temporaire, en l’appelant dans du SQL dynamique. Par exemple :
CREATE TABLE #setoption (so varchar(64), val varchar(64))
INSERT INTO #setoption (so, val)
EXEC ('DBCC USEROPTIONS')
SELECT val
FROM #setoption
WHERE so = 'isolation level'
Chapitre 7. Transactions et verrous
WHERE nombre = 2;
SELECT session_id, transaction_id, elapsed_time_seconds
FROM sys.dm_tran_active_snapshot_database_transactions;
ROLLBACK;
Pourquoi cela ? Afin de permettre, dans la même transaction, d’éviter les lectures
non renouvelables et les lectures fantômes. De fait, ce niveau d’isolation correspond
à un niveau SERIALIZABLE, sans le verrouillage. Une requête dans sys.dm_tran_locks
ne montre aucun verrou maintenu. Les autres transactions pourront donc modifier
la ligne WHERE nombre = 2 à loisir. Durant toute la durée de la transaction, notre session en isolation SNAPSHOT verra la version de ligne équivalant à la première lecture.
Mais que se passera-t-il si nous cherchons à modifier ensuite la ligne dans notre
transaction ? Imaginons qu’après avoir exécuté le SELECT précédent, une autre session a mis à jour la ligne de dbo.testSnapshot, WHERE nombre = 2. Pourrons-nous à
notre tour effectuer un UPDATE, basé sur une version de ligne précédant la mise à jour
externe ? Non. Au moment de l’UPDATE dans notre transaction, un conflit sera
détecté, et une erreur sera retournée : la cohérence des mises à jour est toujours
garantie, pour nous protéger contre les lost updates. Le mode d’isolation SNAPSHOT est
donc à proprement parler un mode de verrouillage optimiste : les données lues sont
conservées sans verrouillage, avec la supposition qu’il y a peu de probabilité qu’un
conflit apparaisse.
Compteurs de performances
Ces compteurs vous donnent une visibilité sur les statistiques du niveau d’isolation snapshot :
MSSQL:Transactions\Longest Transaction Running Time, MSSQL:Transactions\Snapshot Transactions, MSSQL:Transactions\Update conflict ratio.
Identification du niveau d’isolation
Vous pourriez avoir envie de savoir dans quel niveau d’isolation se trouve votre
session, ou une autre session en cours d’exécution. En SQL Server 2000, la
commande DBCC USEROPTIONS était votre seul salut. Cette commande retourne un jeu
de résultats comportant deux colonnes : [Set Option] et Value. Pour la manipuler en
programmation, vous deviez insérer le résultat dans une table temporaire, en l’appelant dans du SQL dynamique. Par exemple :
CREATE TABLE #setoption (so varchar(64), val varchar(64))
INSERT INTO #setoption (so, val)
EXEC ('DBCC USEROPTIONS')
SELECT val
FROM #setoption
WHERE so = 'isolation level'