Transactions dans les tables Memory-Optimized

Le contrôle de version de ligne sur des tables sur disque (à l’aide de l’isolation SNAPSHOT ou READ_COMMITTED_SNAPSHOT) fournit une forme de contrôle de concurrence optimiste. Les lecteurs et les rédacteurs ne se bloquent pas mutuellement. Avec les tables optimisées en mémoire, les processus d'écriture ne bloquent pas les autres processus d'écriture. Avec le contrôle de version des lignes sur les tables sur disque, une transaction verrouille la ligne et les transactions simultanées qui tentent de mettre à jour la ligne sont bloquées. Il n'y a pas de verrouillage avec les tables optimisées pour la mémoire. En revanche, si deux transactions tentent de mettre à jour la même ligne, un conflit d'écriture entre transactions (erreur 41302) se produit.

Contrairement aux tables sur disque, les tables optimisées en mémoire permettent un contrôle concurrentiel optimiste avec les niveaux d'isolation plus élevés, REPEATABLE READ et SERIALIZABLE. Les verrous ne sont pas utilisés pour appliquer les niveaux d’isolation. Au lieu de cela, à la fin de la validation de la transaction, les hypothèses de lecture ou de sérialisabilité reproductibles sont garanties. Si les hypothèses sont violées, la transaction est arrêtée. Pour plus d’informations, consultez Niveaux d’isolation des transactions.

La sémantique de transaction importante pour les tables mémoire optimisées est la suivante :

• Gestion de versions multiples

• Isolation des transactions basée sur des captures instantanées

• Optimiste

• Détection des conflits

Chacune de ces sémantiques est expliquée dans les sections suivantes.

Gestion multi-versions dans les tables Memory-Optimized

Les lignes des tables mémoire optimisées peuvent avoir des versions différentes. Les transactions simultanées accèdent à des versions potentiellement différentes de la même ligne.

Les données de table optimisées en mémoire sont basées sur la version. Pour n’importe quelle ligne, il peut y avoir des versions de lignes différentes valides à des moments différents. Les tables basées sur disque gèrent différentes versions de lignes lorsque READ_COMMITTED_SNAPSHOT ou ALLOW_SNAPSHOT_ISOLATION est activé. Les tables optimisées en mémoire conservent différentes versions de lignes, même si READ_COMMITTED_SNAPSHOT et ALLOW_SNAPSHOT_ISOLATION sont désactivés. Les versions de lignes des tables mémoire optimisées ne sont pas conservées dans tempdb. Au lieu de cela, les versions de ligne sont conservées en ligne, dans le cadre des structures de données optimisées en mémoire stockant les lignes en mémoire.

Isolement des transactions Snapshot-Based pour les tables Memory-Optimized

Toutes les opérations d’une transaction unique utilisent la même capture instantanée cohérente transactionnellement des tables optimisées en mémoire. Toute l’isolation des transactions pour les tables optimisées en mémoire est basée sur des instantanés. Par exemple, une transaction utilisant le niveau d’isolation sérialisable pour accéder aux tables optimisées en mémoire effectue toutes les opérations sur la même capture instantanée cohérente transactionnellement.

Les transactions qui accèdent aux tables optimisées en mémoire utilisent ce versionnage de ligne pour obtenir un instantané transactionnellement cohérent des lignes des tables. Les données lues par n’importe quelle instruction de la transaction seront la version cohérente transactionnelle des données qui existaient au moment du démarrage de la transaction. Par conséquent, toutes les modifications effectuées par les transactions exécutées simultanément ne sont pas visibles pour les déclarations de la transaction actuelle.

Contrôle de concurrence optimiste pour les tables Memory-Optimized

Les conflits et les échecs sont rares et les transactions sur les tables mémoire optimisées supposent qu’il n’y a aucun conflit avec les transactions simultanées et les opérations réussissent. Les transactions ne prennent pas de verrous ou de loquets sur une table optimisée pour la mémoire afin de garantir l’isolation des transactions. Les rédacteurs ne bloquent pas les lecteurs. Les écrivains ne bloquent pas les écrivains. Au lieu de cela, les transactions continuent selon l’hypothèse (optimiste) qu’il n’y aura aucun conflit avec d’autres transactions. Ne pas utiliser de verrous et de loquets et ne pas attendre que d'autres transactions terminent le traitement des mêmes lignes améliore les performances.

En outre, si une transaction (TxA) lit des lignes qui ont été insérées ou modifiées par une autre transaction (TxB) qui se trouve dans le processus de validation, elle suppose de façon optimiste que l’autre transaction s’engage plutôt que d’attendre que la validation se produise. Dans ce cas, la transaction TxA prend une dépendance de validation sur la transaction TxB.

Détection des conflits, validation, et vérifications des dépendances d'engagement

SQL Server détecte les conflits entre les transactions simultanées, ainsi que les violations de niveau d’isolation, et condamne l’une des transactions en conflit. Cette transaction devra être retentée. (Pour plus d’informations, consultez Instructions pour la logique de nouvelle tentative pour les transactions sur les tables Memory-Optimized.)

Le système suppose de façon optimiste qu’il n’existe aucun conflit et aucune violation de l’isolation des transactions. Si des conflits peuvent entraîner des incohérences dans la base de données ou qui peuvent violer l’isolation des transactions, ces conflits sont détectés et la transaction est arrêtée.

Si un conflit est détecté, la transaction est arrêtée et le client doit réessayer.

Le tableau suivant récapitule les conditions d’erreur des transactions qui accèdent aux tables mémoire optimisées.

Conditions d’erreur pour les transactions accédant à des tables mémoire optimisées.

Erreur	Scénario
Conflit d’écriture. Tentative de mise à jour d’un enregistrement mis à jour depuis le démarrage de la transaction.	UPDATE ou DELETE une ligne qui a été mise à jour ou supprimée par une transaction simultanée.
Échec de validation de lecture répétable.	Une ligne lue par la transaction a changé (mise à jour ou supprimée) depuis le démarrage de la transaction. La validation de lecture reproductible se produit généralement lors de l’utilisation des niveaux d’isolation des transactions REPEATABLE READ et SERIALIZABLE.
Échec de validation sérialisée.	Une nouvelle ligne (fantôme) a été insérée dans l’une des plages d’analyse de la transaction, depuis le début de la transaction. La ligne aurait été visible à la transaction si la ligne avait été validée dans la base de données avant le démarrage de la transaction. La validation SERIALIZABLE se produit généralement lors de l’utilisation de l’isolation SERIALIZABLE et de la validation des contraintes PRIMARY KEY.
Échec de l'engagement de dépendance.	La transaction a pris une dépendance vis-à-vis d’une autre transaction qui n’a pas pu être validée, soit en raison de l’une des défaillances de cette table, d’une condition de mémoire insuffisante ou d’un échec de validation dans le journal des transactions. Cet échec peut se produire avec les transactions en lecture/écriture et en lecture seule.

Durée de vie des transactions

Les échecs mentionnés dans le tableau précédent peuvent se produire à différents points pendant une transaction. La figure suivante illustre les phases d’une transaction qui accède aux tables optimisées pour la mémoire.

Durée de vie d’une transaction qui accède aux tables mémoire optimisées.

Traitement régulier

Pendant cette phase, les instructions Transact-SQL émises par l’utilisateur sont exécutées. Les lignes sont lues à partir des tables et les nouvelles versions de lignes sont écrites dans la base de données. La transaction est isolée de toutes les autres transactions simultanées. La transaction utilise l’instantané des tables mémoire optimisées qui existent au début de la transaction.

Les écritures dans les tables de cette phase de la transaction ne sont pas encore visibles par d’autres transactions, à une exception près : les mises à jour et les suppressions de lignes sont visibles pour les opérations de mise à jour et de suppression dans d’autres transactions, afin de détecter les conflits d’écriture.

Si une opération de mise à jour ou de suppression voit qu’une ligne a été mise à jour ou supprimée depuis le début logique de la transaction, l’opération échoue avec l’erreur 41302. Le message d’erreur 41302 est « La transaction actuelle a tenté de mettre à jour un enregistrement dans la table X qui a été mis à jour depuis le démarrage de cette transaction. La transaction a été abandonnée. »

Cette erreur condamne la transaction (même si XACT_ABORT est DÉSACTIVÉ), ce qui signifie que la transaction sera restaurée lorsque la session utilisateur se termine. Les transactions condamnées ne peuvent pas être validées et ne prennent en charge que les opérations de lecture qui n'écrivent pas dans le journal et n'accèdent pas aux tables optimisées pour la mémoire.

Engager les dépendances

Pendant le traitement régulier, une transaction peut lire les lignes écrites par d’autres transactions qui se trouvent dans la phase de validation ou de commit, mais qui n’ont pas encore été commitées. Les lignes sont visibles, car l’heure de fin logique des transactions a été affectée au début de la phase de validation.

Si une transaction lit ces lignes non validées, elle prend une dépendance de validation sur cette transaction. Cela a deux implications principales :

• Une transaction ne peut pas être validée tant que les transactions dont elle dépend n’ont pas été validées. En d’autres termes, elle ne peut pas entrer dans la phase de validation, tant que toutes les dépendances n’ont pas été effacées.

• En outre, les jeux de résultats ne sont pas retournés au client tant que toutes les dépendances n’ont pas été résolues. Cela empêche le client d’observer des données non validées.

Si l'une des transactions dépendantes échoue à se valider, il y a un problème de dépendance de validation. Cela signifie que la transaction ne pourra pas se valider avec l’erreur 41301 (« Une transaction précédente dont dépendait la transaction actuelle a été abandonnée, et la transaction actuelle ne peut plus être validée. »).

Phase de validation

Pendant la phase de validation, le système vérifie que les hypothèses nécessaires pour le niveau d’isolation de transaction demandé étaient vraies entre le début logique et la fin logique de la transaction.

Au début de la phase de validation, la transaction reçoit une heure de fin logique. Les versions de ligne écrites dans la base de données deviennent visibles par d’autres transactions au moment de la fin logique. Pour plus d’informations, consultez Dépendances de commits.

Validation de lecture répétable

Si le niveau d’isolation de la transaction est REPEATABLE READ ou SERIALIZABLE, ou si les tables sont accessibles sous l’isolation REPEATABLE READ ou SERIALIZABLE (pour plus d’informations, consultez la section sur l’isolation des opérations individuelles dans les niveaux d’isolation des transactions), le système valide que les lectures sont reproductibles. Cela signifie qu’il valide que les versions des lignes lues par la transaction sont toujours des versions de lignes valides au moment de fin logique de la transaction.

Si l’une des lignes a été mise à jour ou modifiée, la transaction ne parvient pas à s’valider avec l’erreur 41305 (« La transaction actuelle n’a pas pu être validée en raison d’un échec de validation de lecture reproductible). »).

Cette erreur peut également se produire si une table est supprimée après une opération d’insertion, de mise à jour ou de suppression et avant la validation de la transaction. Cela s’applique uniquement aux opérations d’insertion, de mise à jour ou de suppression dans les procédures stockées compilées en mode natif. Ces opérations d’écriture effectuées via des interprétations de Transact-SQL provoquent le blocage de l’instruction DROP TABLE et attendent que la transaction soit validée.

Validation sérialisable

La validation sérialisable est effectuée dans deux cas :

• Si le niveau d’isolation de la transaction est SERIALIZABLE ou que les tables sont accessibles sous isolation SERIALIZABLE.

• Si des lignes sont insérées dans un index unique, par exemple l’index créé pour une contrainte PRIMARY KEY. Le système vérifie qu’aucune ligne avec la même clé n’a été insérée simultanément.

Le système vérifie qu’aucune ligne fantôme n’a été écrite dans la base de données. Les opérations de lecture effectuées par la transaction sont évaluées pour déterminer qu’aucune nouvelle ligne n’a été insérée dans les plages d’analyse de ces opérations de lecture.

L’insertion d’une clé dans un index unique inclut une opération de lecture implicite, pour déterminer que la clé n’est pas dupliquée. La validation sérialisable pour les index uniques garantit que ces index ne peuvent pas avoir de doublons dans le cas où deux transactions insèrent simultanément la même clé.

Si des lignes fantômes sont détectées, la transaction ne parvient pas à s’valider avec l’erreur 41325 (« La transaction actuelle n’a pas pu être validée en raison d’un échec de validation sérialisable. »).

Traitement de validation

Si la validation réussit et que toutes les dépendances de transaction sont effacées, la transaction entre dans la phase de traitement de validation. Pendant cette phase, les modifications apportées aux tables durables sont consignées dans le journal, et ce dernier est enregistré sur le disque pour garantir la durabilité. Une fois que l’enregistrement du journal de la transaction a été écrit sur le disque, le contrôle est retourné au client.

Toutes les dépendances de validation sur cette transaction sont effacées, et toutes les transactions qui attendaient que cette transaction soit validée peuvent continuer.

Limites

• Les transactions inter-bases de données ne sont pas prises en charge avec des tables optimisées en mémoire. Chaque transaction qui accède aux tables mémoire optimisées ne peut pas accéder à plusieurs bases de données, à l’exception de l’accès en lecture-écriture à tempdb et un accès en lecture seule au maître de base de données système.

• Les transactions distribuées ne sont pas prises en charge avec des tables optimisées en mémoire. Les transactions distribuées démarrées avec BEGIN DISTRIBUTED TRANSACTION ne peuvent pas accéder aux tables mémoire optimisées.

• Les tables optimisées en mémoire ne prennent pas en charge le verrouillage. Les verrous explicites par le biais d’indicateurs de verrouillage (tels que TABLOCK, XLOCK, ROWLOCK) ne sont pas pris en charge avec les tables optimisées en mémoire.

Voir aussi

Présentation des transactions sur les tables Memory-Optimized