Niveaux d’isolation des transactions dans les tables optimisées en mémoire

  • Article

Les niveaux d'isolation suivants sont pris en charge pour les transactions qui accèdent à des tables mémoire optimisées.

  • SNAPSHOT

  • REPEATABLE READ

  • SERIALIZABLE

  • READ COMMITTED

Le niveau d'isolation de la transaction peut être spécifié dans le bloc Atomic d'une procédure stockée compilée en mode natif. Pour plus d’informations, consultez CREATE PROCEDURE (Transact-SQL). Lors de l’accès à des tables optimisées en mémoire à partir de Transact-SQL interprété, le niveau d’isolation peut être spécifié à l’aide d’indicateurs au niveau de la table.

Vous devez spécifier le niveau d'isolation de la transaction lorsque vous définissez une procédure stockée compilée en mode natif. Vous devez spécifier le niveau d’isolation dans les indicateurs de table lors de l’accès aux tables optimisées en mémoire à partir de transactions utilisateur dans Transact-SQL interprété. Pour plus d’informations, consultez Recommandations pour les niveaux d’isolation des transactions avec des tables Memory-Optimized.

Le niveau d'isolation READ COMMITTED est pris en charge pour les tables mémoire optimisées avec des transactions validées automatiquement. READ COMMITTED n'est pas valide dans les transactions utilisateur ou dans un bloc atomique. READ COMMITTED n'est pas pris en charge avec les transactions utilisateur explicites ou implicites. Le niveau d'isolation READ_COMMITTED_SNAPSHOT est pris en charge pour les tables mémoire optimisées avec transactions en mode de validation automatique et uniquement si la requête n'accède pas à des tables sur disque. En outre, les transactions démarrées à l’aide de Transact-SQL interprété avec l’isolation SNAPSHOT ne peuvent pas accéder aux tables mémoire optimisées. Les transactions qui utilisent Transact-SQL interprété avec une isolation REPEATABLE READ ou SERIALIZABLE doivent accéder aux tables mémoire optimisées à l’aide de l’isolation SNAPSHOT. Pour plus d’informations sur ce scénario, consultez Transactions entre conteneurs.

READ COMMITTED est le niveau d’isolation par défaut dans SQL Server. Lorsque le niveau d'isolation de la session est READ COMMITED (ou un niveau inférieur), procédez comme suit :

  • Utilisez explicitement un indicateur de niveau d'isolation supérieur pour accéder à la table mémoire optimisée, par exemple WITH (SNAPSHOT).

  • Spécifiez l'option SET MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT, qui définira le niveau d'isolation pour la table mémoire optimisée sur SNAPSHOT (comme si vous aviez inclus des indicateurs WITH(SNAPSHOT) à chaque table mémoire optimisée). Pour plus d’informations sur MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT, consultez OPTIONS ALTER DATABASE SET (Transact-SQL).

Alternativement, si le niveau d'isolement de la session est READ COMMITTED, utilisez des transactions en mode de validation automatique.

Les transactions SNAPSHOT démarrées dans Transact-SQL interprétés ne peuvent pas accéder aux tables optimisées en mémoire.

Les niveaux d'isolation des transactions pris en charge pour les tables mémoire optimisées fournissent les mêmes garanties logiques que les tables sur disque. Le mécanisme utilisé pour fournir des garanties de niveau d'isolation est différent.

Pour les tables sur disque, la plupart des garanties de niveau d'isolation sont implémentées à l'aide d'un verrouillage, qui empêche les conflits par blocage. Pour les tables mémoire optimisées, les garanties sont appliquées à l'aide d'un mécanisme de détection de conflit, qui évite de prendre des verrous. L'exception est l'isolation SNAPSHOT sur les tables sur disque. Cela est implémenté de façon similaire à l'isolation SNAPSHOT sur les tables mémoire optimisées à l'aide d'un mécanisme de détection de conflit.

SNAPSHOT
Ce niveau d'isolation spécifie que les données lues par n'importe quelle instruction d'une transaction représenteront la version cohérente d'un point de vue transactionnel des données qui existaient au début de la transaction. La transaction peut seulement reconnaître les modifications de données qui ont été validées avant qu'elle ne commence. Autrement dit, les modifications de données effectuées par d'autres transactions après le début de la transaction active ne sont pas visibles pour les instructions qui s'exécutent dans le cadre de ladite transaction. Les instructions d'une transaction obtiennent un instantané des données validées telles qu'elles existaient au début de cette transaction.

Les opérations d'écriture (mises à jour, insertions et suppressions) sont toujours totalement isolées des autres transactions. Par conséquent, les opérations d'écriture dans une transaction SNAPSHOT peuvent être en conflit avec les opérations d'écriture d'autres transactions. Lorsque la transaction active tente de mettre à jour ou de supprimer une ligne mise à jour ou supprimée par une autre transaction validée après le début de la transaction active, la transaction prend fin avec le message d'erreur suivant.

Erreur 41302. La transaction en cours a tenté de mettre à jour un enregistrement dans la table X qui a été mis à jour depuis le début de cette transaction. La transaction a été abandonnée.

Lorsque la transaction active tente d'insérer une ligne avec la même valeur de clé primaire qu'une ligne insérée par une autre transaction validée avant la transaction active, il y a un échec de validation avec le message d'erreur suivant.

Erreur 41325. La transaction en cours n'a pas été validée en raison d'un échec de validation SERIALIZABLE.

Si une transaction écrit sur une table qui est supprimée avant la validation de la transaction, celle-ci est arrêtée avec le message d'erreur suivant :

Erreur 41305. La transaction en cours n'a pas été validée en raison d'un échec de validation REPEATABLE READ.

REPEATABLE READ
Ce niveau d'isolation inclut les garanties fournies par le niveau d'isolation SNAPSHOT. En outre, REPEATABLE READ garantit que pour n'importe quelle ligne lue par la transaction, au moment de la validation de la transaction, la ligne n'a pas été modifiée par une autre transaction. Chaque opération de lecture dans la transaction est renouvelable jusqu'à la fin de la transaction.

Si la transaction active a lu une ligne qui a ensuite été mise à jour par une autre transaction validée avant la transaction active, la validation échoue avec le message d'erreur suivant.

Erreur 41305. La transaction en cours n'a pas été validée en raison d'un échec de validation REPEATABLE READ.

SERIALIZABLE
Ce niveau d'isolation inclut les garanties fournies par REPEATABLE READ. Aucune ligne fantôme n'est apparue entre l'instantané et la fin de la transaction. Les lignes fantômes correspondent à la condition de filtre d'une sélection, d'une mise à jour ou d'une suppression.

La transaction est exécutée comme s'il n'existait aucune transaction simultanée. Toutes les actions se produisent virtuellement à un seul point de sérialisation (au moment de la validation).

Si l'une de ces garanties n'est pas respectée, la transaction échoue avec le message d'erreur suivant :

Erreur 41325. La transaction en cours n'a pas été validée en raison d'un échec de validation SERIALIZABLE.

Voir aussi

Comprendre les transactions sur les tables mémoire optimisées
Instructions pour les niveaux d'isolement des transactions sur les tables mémoire optimisées
Instructions pour la logique de nouvelle tentative des transactions sur des tables mémoire optimisées