Comparaison de READ UNCOMMITTED dans Babelfish avec le niveau d’isolement READ UNCOMMITTED de SQL Server Comparaison de READ COMMITTED dans Babelfish avec le niveau d’isolement READ COMMITTED de SQL Server Comparaison de READ COMMITTED dans Babelfish avec le niveau d’isolement READ COMMITTED SNAPSHOT de SQL Server Comparaison de REPEATABLE READ dans Babelfish avec le niveau d’isolement REPEATABLE READ de SQL Server Comparaison de SERIALIZABLE dans Babelfish avec le niveau d’isolement SERIALIZABLE de SQL Server

Comparaison des niveaux d’isolement Babelfish et SQL Server

Vous trouverez ci-dessous quelques exemples illustrant les nuances dans la manière dont SQL Server et Babelfish implémentent les niveaux d’isolement ANSI.

Note

Les niveaux d’isolement REPEATABLE READ et SNAPSHOT sont les mêmes dans Babelfish.
Les niveaux d’isolement READ UNCOMMITTED et READ COMMITTED sont les mêmes dans Babelfish.

L’exemple suivant montre comment créer la table de base pour tous les exemples mentionnés ci-dessous :


CREATE TABLE employee (
    id sys.INT NOT NULL PRIMARY KEY,
    name sys.VARCHAR(255)NOT NULL,
    age sys.INT NOT NULL
);
INSERT INTO employee (id, name, age) VALUES (1, 'A', 10);
INSERT INTO employee (id, name, age) VALUES (2, 'B', 20);
INSERT INTO employee (id, name, age) VALUES (3, 'C', 30);

Rubriques

Comparaison de READ UNCOMMITTED dans Babelfish avec le niveau d’isolement READ UNCOMMITTED de SQL Server
Comparaison de READ COMMITTED dans Babelfish avec le niveau d’isolement READ COMMITTED de SQL Server
Comparaison de READ COMMITTED dans Babelfish avec le niveau d’isolement READ COMMITTED SNAPSHOT de SQL Server
Comparaison de REPEATABLE READ dans Babelfish avec le niveau d’isolement REPEATABLE READ de SQL Server
Comparaison de SERIALIZABLE dans Babelfish avec le niveau d’isolement SERIALIZABLE de SQL Server

Comparaison de `READ UNCOMMITTED` dans Babelfish avec le niveau d’isolement `READ UNCOMMITTED` de SQL Server

Le tableau suivant fournit des détails sur les lectures incorrectes lors de l’exécution de transactions simultanées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement READ UNCOMMITTED dans SQL Server par rapport à l’implémentation Babelfish.

Transaction 1	Transaction 2	`READ UNCOMMITTED` dans SQL Server	`READ UNCOMMITTED` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age=0;`	Mise à jour réussie.	Mise à jour réussie.
État Idle in transaction (Transaction inactive)	`INSERT INTO employee VALUES (4, 'D', 40);`	Insertion réussie.	Insertion réussie.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La transaction 1 peut voir les modifications non validées de la transaction 2.	Comme `READ COMMITTED` dans Babelfish. Les modifications non validées de la transaction 2 ne sont pas visibles pour la transaction 1.
État Idle in transaction (Transaction inactive)	`COMMIT`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Voit les modifications validées par la transaction 2.	Voit les modifications validées par la transaction 2.

Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED` de SQL Server

Le tableau suivant fournit des détails sur le comportement de blocage en lecture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement READ COMMITTED dans SQL Server par rapport à l’implémentation Babelfish.

Transaction 1	Transaction 2	`READ COMMITTED` dans SQL Server	`READ COMMITTED` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age=100 WHERE id = 1;`	Mise à jour réussie.	Mise à jour réussie.
`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	État Idle in transaction (Transaction inactive)	Étape bloquée jusqu’à ce que la transaction 2 soit validée.	Les modifications de la transaction 2 ne sont pas encore visibles. Met à jour la ligne avec id=3.
État Idle in transaction (Transaction inactive)	`COMMIT`	La transaction 2 est validée avec succès. La transaction 1 est maintenant débloquée et voit la mise à jour de la transaction 2.	La transaction 2 est validée avec succès.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La transaction 1 met à jour la ligne avec id = 1.	La transaction 1 met à jour la ligne avec id = 3.

Comparaison de `READ COMMITTED` dans Babelfish avec le niveau d’isolement `READ COMMITTED SNAPSHOT` de SQL Server

Le tableau suivant fournit des détails sur le comportement de blocage des lignes nouvellement insérées lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement READ COMMITTED SNAPSHOT dans SQL Server par rapport à l’implémentation de READ COMMITTED dans Babelfish.

Transaction 1	Transaction 2	`READ COMMITTED SNAPSHOT` dans SQL Server	`READ COMMITTED` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Aucun	Aucun
`INSERT INTO employee VALUES (4, 'D', 40);`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age = 99;`	Étape bloquée jusqu’à ce que la transaction 1 soit validée. La ligne insérée est verrouillée par la transaction 1.	Trois lignes mises à jour. La ligne nouvellement insérée n’est pas encore visible.
`COMMIT`	État Idle in transaction (Transaction inactive)	Validation réussie. La transaction 2 est désormais débloquée.	Validation réussie.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	Les 4 lignes ont le valeur age=99.	La ligne avec id = 4 a la valeur d’âge 40, car elle n’était pas visible pour la transaction 2 lors de la requête de mise à jour. Les autres lignes sont mises à jour avec age=99.

Comparaison de `REPEATABLE READ` dans Babelfish avec le niveau d’isolement `REPEATABLE READ` de SQL Server

Le tableau suivant fournit des détails sur le comportement de blocage en lecture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement REPEATABLE READ dans SQL Server par rapport à l’implémentation de REPEATABLE READ dans Babelfish.

Transaction 1	Transaction 2	`REPEATABLE READ` dans SQL Server	`REPEATABLE READ` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee WHERE id != 1;`	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.	La transaction 2 se déroule normalement.
`COMMIT`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La mise à jour de la transaction 1 est visible.	La mise à jour de la transaction 1 n’est pas visible.
`COMMIT`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	voit la mise à jour de la transaction 1.	voit la mise à jour de la transaction 1.

Le tableau suivant fournit des détails sur le comportement de blocage de l’écriture-écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement REPEATABLE READ dans SQL Server par rapport à l’implémentation de REPEATABLE READ dans Babelfish.

Transaction 1	Transaction 2	`REPEATABLE READ` dans SQL Server	`REPEATABLE READ` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Aucun	Aucun
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`UPDATE employee SET name='A_TXN2' WHERE id=1;`	Transaction 2 bloquée.	Transaction 2 bloquée.
`COMMIT`	État Idle in transaction (Transaction inactive)	La validation a été effectuée avec succès et la transaction 2 a été débloquée.	La validation a été effectuée avec succès et la transaction 2 échoue avec une erreur signalant que l’accès n’a pas pu être sérialisé en raison d’une mise à jour simultanée.
État Idle in transaction (Transaction inactive)	`COMMIT`	Validation réussie.	La transaction 2 a déjà été abandonnée.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La ligne avec id=1 contient name=’A_TX2’.	La ligne avec id=1 contient name=’A_TX1’.

Le tableau suivant fournit des détails sur le comportement des lectures fantômes lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement REPEATABLE READ dans SQL Server par rapport à l’implémentation de REPEATABLE READ dans Babelfish.

Transaction 1	Transaction 2	`REPEATABLE READ` dans SQL Server	`REPEATABLE READ` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`INSERT INTO employee VALUES (4, 'NewRowName', 20);`	La transaction 2 se déroule sans aucun blocage.	La transaction 2 se déroule sans aucun blocage.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La ligne nouvellement insérée est visible.	La ligne nouvellement insérée est visible.
État Idle in transaction (Transaction inactive)	`COMMIT`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La nouvelle ligne insérée par la transaction 2 est visible.	La nouvelle ligne insérée par la transaction 2 n’est pas visible.
`COMMIT`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La ligne nouvellement insérée est visible.	La ligne nouvellement insérée est visible.

Le tableau suivant fournit des détails lorsque des transactions simultanées sont exécutées, et indique les différents résultats finaux lors de l’utilisation du niveau d’isolement REPEATABLE READ dans SQL Server par rapport à l’implémentation Babelfish REPEATABLE READ.

Transaction 1	Transaction 2	`REPEATABLE READ` dans SQL Server	`REPEATABLE READ` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Aucun	Aucun
`UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`	État Idle in transaction (Transaction inactive)	La transaction 1 met à jour la ligne avec l’identifiant 1.	La transaction 1 met à jour la ligne avec l’identifiant 1.
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	La transaction 2 est bloquée, car l’instruction SELECT tente de lire les lignes verrouillées par la requête UPDATE dans la transaction 1.	La transaction 2 se déroule sans aucun blocage, car la lecture n’est jamais bloquée, l’instruction SELECT s’exécute et la ligne avec id = 3 finira par être mise à jour, car les modifications de la transaction 1 ne sont pas encore visibles.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	Cette étape est exécutée une fois la transaction 1 validée. La ligne avec id = 1 est mise à jour par la transaction 2 à l’étape précédente et est visible ici.	La ligne avec id = 3 est mise à jour par la transaction 2.
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 2 est désormais débloquée.	Validation réussie.
État Idle in transaction (Transaction inactive)	`COMMIT`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Les deux transactions exécutent la mise à jour sur la ligne contenant id = 1.	Les différentes lignes sont mises à jour par les transactions 1 et 2.

Comparaison de `SERIALIZABLE` dans Babelfish avec le niveau d’isolement `SERIALIZABLE` de SQL Server

Le tableau suivant fournit des détails sur les blocages de plage lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement SERIALIZABLE dans SQL Server par rapport à l’implémentation de SERIALIZABLE dans Babelfish.

Transaction 1	Transaction 2	`SERIALIZABLE` dans SQL Server	`SERIALIZABLE` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`INSERT INTO employee VALUES (4, 'D', 35);`	La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.	La transaction 2 se déroule sans aucun blocage.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	Aucun	Aucun
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 1 est validée avec succès. La transaction 2 est désormais débloquée.	La transaction 1 est validée avec succès.
État Idle in transaction (Transaction inactive)	`COMMIT`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La ligne nouvellement insérée est visible.	La ligne nouvellement insérée est visible.

Le tableau suivant fournit des détails lorsque des transactions simultanées sont exécutées, et indique les différents résultats finaux lors de l’utilisation du niveau d’isolement SERIALIZABLE dans SQL Server par rapport à l’implémentation Babelfish SERIALIZABLE.

Transaction 1	Transaction 2	`SERIALIZABLE` dans SQL Server	`SERIALIZABLE` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`INSERT INTO employee VALUES (4, 'D', 40);`	Aucun	Aucun
`UPDATE employee SET age =99 WHERE id = 4;`	État Idle in transaction (Transaction inactive)	La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.	La transaction 1 se déroule sans aucun blocage.
État Idle in transaction (Transaction inactive)	`COMMIT`	La transaction 2 est validée avec succès. La transaction 1 est désormais débloquée.	La transaction 2 est validée avec succès.
`COMMIT`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La ligne nouvellement insérée est visible avec une valeur d’âge = 99.	La ligne nouvellement insérée est visible avec une valeur d’âge = 40.

Le tableau suivant fournit des informations détaillées lorsque vous exécutez une instruction INSERT dans une table avec une contrainte unique. Il montre les résultats observés lors de l’utilisation du niveau d’isolement SERIALIZABLE dans SQL Server par rapport à l’implémentation de SERIALIZABLE dans Babelfish.

Transaction 1	Transaction 2	`SERIALIZABLE` dans SQL Server	`SERIALIZABLE` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`INSERT INTO employee VALUES (4, 'D', 40);`	Aucun	Aucun
`INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);`	État Idle in transaction (Transaction inactive)	La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.	La transaction 1 est bloquée jusqu’à ce que la transaction 2 soit validée.
État Idle in transaction (Transaction inactive)	`COMMIT`	La transaction 2 est validée avec succès. La transaction 1 est désormais débloquée.	La transaction 2 est validée avec succès. La transaction 1 a été abandonnée avec une erreur de valeur de clé en double qui va à l’encontre de la contrainte unique.
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 1 est validée avec succès.	Les validations de la transaction 1 échouent, car l’accès n’a pas pu être sérialisé en raison de dépendances en lecture ou en écriture entre les transactions.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La ligne (5, ’E’, 50) est insérée.	Il n’existe que 4 lignes.

Dans Babelfish, les transactions simultanées exécutées avec le niveau d’isolement serializable échouent avec une erreur d’anomalie de sérialisation si l’exécution de ces transactions est incompatible avec toutes les exécutions en série (une par une) possibles de ces transactions.

Les tableaux suivants fournissent des détails sur les anomalies de sérialisation lors de l’exécution de transactions simultanées. Il montre les résultats observés lors de l’utilisation du niveau d’isolement SERIALIZABLE dans SQL Server par rapport à l’implémentation de SERIALIZABLE dans Babelfish.

Transaction 1	Transaction 2	`SERIALIZABLE` dans SQL Server	`SERIALIZABLE` dans Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
`UPDATE employee SET age=5 WHERE age=10;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.	La transaction 2 se déroule sans aucun blocage.
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age=35 WHERE age=30;`	Aucun	Aucun
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 1 est validée avec succès.	La transaction 1 est validée en premier et peut être validée avec succès.
État Idle in transaction (Transaction inactive)	`COMMIT`	La transaction 2 est validée avec succès.	La validation de la transaction 2 échoue avec une erreur de sérialisation, l’ensemble de la transaction a été annulée. Réessayez la transaction 2.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Les modifications apportées par les deux transactions sont visibles.	La transaction 2 a été annulée. Seules les modifications de la transaction 1 sont visibles.

Dans Babelfish, l’anomalie de sérialisation n’est possible que si toutes les transactions simultanées s’exécutent au niveau d’isolement SERIALIZABLE. Dans le tableau suivant, prenons l’exemple ci-dessus, mais définissons plutôt la transaction 2 sur le niveau d’isolement REPEATABLE READ.

Transaction 1	Transaction 2	Niveaux d’isolement SQL Server	Niveaux d’isolement Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Aucun	Aucun
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Aucun	Aucun
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
`UPDATE employee SET age=5 WHERE age=10;`	État Idle in transaction (Transaction inactive)	Aucun	Aucun
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	La transaction 2 est bloquée jusqu’à ce que la transaction 1 soit validée.	La transaction 2 se déroule sans aucun blocage.
État Idle in transaction (Transaction inactive)	`UPDATE employee SET age=35 WHERE age=30;`	Aucun	Aucun
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 1 est validée avec succès.	La transaction 1 est validée avec succès.
État Idle in transaction (Transaction inactive)	`COMMIT`	La transaction 2 est validée avec succès.	La transaction 2 est validée avec succès.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	Les modifications apportées par les deux transactions sont visibles.	Les modifications apportées par les deux transactions sont visibles.

Avertissement JavaScript est désactivé ou n'est pas disponible dans votre navigateur.

Pour que vous puissiez utiliser la documentation AWS, Javascript doit être activé. Vous trouverez des instructions sur les pages d'aide de votre navigateur.

Conventions de rédaction

Niveaux d’isolement des transactions dans Babelfish

Utilisation des fonctionnalités Babelfish dont la mise en œuvre est limitée