Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.
Niveaux d’isolement des transactions dans Babelfish
Babelfish prend en charge les niveaux d’isolement des transactions READ UNCOMMITTED, READ COMMITTED et SNAPSHOT. À partir de la version 3.4 de Babelfish, les niveaux d’isolement supplémentaires REPEATABLE READ et SERIALIZABLE sont pris en charge. Tous les niveaux d’isolement de Babelfish sont pris en charge avec le comportement des niveaux d’isolement correspondants dans PostgreSQL. SQL Server et Babelfish utilisent différents mécanismes sous-jacents pour implémenter les niveaux d’isolement des transactions (blocage des accès simultanés, verrous détenus par les transactions, gestion des erreurs, etc.). Il existe aussi des différences subtiles dans la manière dont l’accès simultané peut fonctionner pour différentes charges de travail. Pour plus d’informations sur ce comportement de PostgreSQL, consultez Isolement des transactions
Rubriques
Présentation des niveaux d’isolement des transactions
Les niveaux d’isolement des transactions SQL Server d’origine sont basés sur un verrouillage pessimiste où il n’existe qu’une seule copie des données et où les requêtes doivent verrouiller des ressources telles que les lignes avant de pouvoir y accéder. Par la suite, une variation du niveau d’isolement READ COMMITTED a été introduite. Cela permet d’utiliser des versions de ligne pour améliorer la simultanéité entre les lecteurs et les rédacteurs en utilisant un accès non bloquant. De plus, un nouveau niveau d’isolement appelé SNAPSHOT est disponible. Il utilise également des versions de ligne pour offrir une meilleure simultanéité que le niveau d’isolement REPEATABLE READ en évitant le verrouillage partagé des données de lecture qui sont bloquées jusqu’à la fin de la transaction.
Contrairement à SQL Server, tous les niveaux d’isolement des transactions de Babelfish sont basés sur le verrouillage optimiste (MVCC). Chaque transaction affiche un instantané des données au début de l’instruction (READ COMMITTED) ou au début de la transaction (REPEATABLE READ, SERIALIZABLE), quel que soit l’état actuel des données sous-jacentes. Par conséquent, le comportement d’exécution des transactions simultanées dans Babelfish peut être différent de celui de SQL Server.
Prenons l’exemple d’une transaction avec un niveau d’isolement SERIALIZABLE initialement bloqué dans SQL Server, mais qui aboutit ultérieurement. Elle peut échouer dans Babelfish en raison d’un conflit de sérialisation avec une transaction simultanée qui lit ou met à jour les mêmes lignes. Il peut également arriver que l’exécution de plusieurs transactions simultanées produise un résultat final différent dans Babelfish par rapport à SQL Server. Les scénarios de simultanéité des applications qui utilisent des niveaux d’isolement doivent être testés minutieusement.
| Niveaux d’isolement dans SQL Server | Niveau d’isolement Babelfish | Niveaux d’isolement PostgreSQL | Commentaires |
|---|---|---|---|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Les deux sont basés sur des instantanés (MVCC), mais ne sont pas exactement les mêmes. |
|
|
|
|
Exactement pareil. |
|
|
|
|
|
|
|
|
|
|
Note
Les indicateurs de table ne sont actuellement pas pris en charge, et leur comportement est contrôlé à l’aide de la trappe de secours prédéfinie escape_hatch_table_hints de Babelfish.
Configuration des niveaux d’isolement des transactions
Utilisez la commande suivante pour définir le niveau d’isolement des transactions :
SET TRANSACTION ISOLATION LEVEL { READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SNAPSHOT | SERIALIZABLE }
Activation ou désactivation des niveaux d’isolement des transactions
Les niveaux d’isolement des transactions REPEATABLE READ et SERIALIZABLE sont désactivés par défaut dans Babelfish. Vous devez donc les activer explicitement en réglant l’utilisation de la trappe de secours babelfishpg_tsql.isolation_level_serializable ou babelfishpg_tsql.isolation_level_repeatable_read sur pg_isolation à l’aide de sp_babelfish_configure. Pour plus d’informations, consultez Gestion du traitement des erreurs Babelfish avec des trappes de secours.
Vous trouverez ci-dessous des exemples d’activation ou de désactivation de l’utilisation de REPEATABLE READ et SERIALIZABLE dans la session en cours en définissant leur trappe de secours respective. Incluez éventuellement un paramètre server pour définir la trappe de secours pour la session en cours ainsi que pour toutes les nouvelles sessions suivantes.
Pour activer l’utilisation de SET TRANSACTION ISOLATION LEVEL REPEATABLE READ uniquement dans la session en cours.
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation'
Pour permettre l’utilisation de SET TRANSACTION ISOLATION LEVEL REPEATABLE READ dans la session en cours et dans toutes les nouvelles sessions qui en découlent.
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'pg_isolation', 'server'
Pour désactiver l’utilisation de SET TRANSACTION ISOLATION LEVEL REPEATABLE READ dans la session en cours et dans les nouvelles sessions qui en découlent.
EXECUTE sp_babelfish_configure 'isolation_level_repeatable_read', 'off', 'server'
Pour activer l’utilisation de SET TRANSACTION ISOLATION LEVEL SERIALIZABLE uniquement dans la session en cours.
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation'
Pour permettre l’utilisation de SET TRANSACTION ISOLATION LEVEL SERIALIZABLE dans la session en cours et dans toutes les nouvelles sessions qui en découlent.
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'pg_isolation', 'server'
Pour désactiver l’utilisation de SET TRANSACTION ISOLATION LEVEL SERIALIZABLE dans la session en cours et dans les nouvelles sessions qui en découlent.
EXECUTE sp_babelfish_configure 'isolation_level_serializable', 'off', 'server'
