Comparaison de Babelfish avec le READ UNCOMMITTED niveau d'isolation SQL du serveur READ UNCOMMITTED Comparaison de Babelfish avec le READ COMMITTED niveau d'isolation SQL du serveur READ COMMITTED Comparaison de Babelfish avec le READ COMMITTED niveau d'isolation SQL du serveur READ COMMITTED SNAPSHOT Comparaison de Babelfish avec le REPEATABLE READ niveau d'isolation SQL du serveur REPEATABLE READ Comparaison de Babelfish avec le SERIALIZABLE niveau d'isolation SQL du serveur SERIALIZABLE

Comparaison des niveaux d'isolation de Babelfish et SQL du serveur

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

Note

Le niveau REPEATABLE READ d'isolement SNAPSHOT est le même dans Babelfish.
Le niveau READ UNCOMMITTED d'isolement READ COMMITTED est le même 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 Babelfish avec le READ UNCOMMITTED niveau d'isolation SQL du serveur READ UNCOMMITTED
Comparaison de Babelfish avec le READ COMMITTED niveau d'isolation SQL du serveur READ COMMITTED
Comparaison de Babelfish avec le READ COMMITTED niveau d'isolation SQL du serveur READ COMMITTED SNAPSHOT
Comparaison de Babelfish avec le REPEATABLE READ niveau d'isolation SQL du serveur REPEATABLE READ
Comparaison de Babelfish avec le SERIALIZABLE niveau d'isolation SQL du serveur SERIALIZABLE

Comparaison de Babelfish avec le `READ UNCOMMITTED` niveau d'isolation SQL du serveur `READ UNCOMMITTED`

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 READ UNCOMMITTED d'isolation dans SQL Server par rapport à l'implémentation de Babelfish.

Transaction 1	Transaction 2	SQLserveur `READ UNCOMMITTED`	Babelfish `READ UNCOMMITTED`
`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);`	L'insertion est réussie.	L'insertion est réussie.
`SELECT * FROM employee;`	État Idle in transaction (Transaction inactive)	La transaction 1 peut voir les modifications non validées par rapport à la transaction 2.	Comme `READ COMMITTED` dans Babelfish. Les modifications non validées par rapport à 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)	Permet de voir les modifications validées par la transaction 2.	Permet de voir les modifications validées par la transaction 2.

Comparaison de Babelfish avec le `READ COMMITTED` niveau d'isolation SQL du serveur `READ COMMITTED`

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 READ COMMITTED d'isolation dans SQL Server par rapport à l'implémentation de Babelfish.

Transaction 1	Transaction 2	SQLserveur `READ COMMITTED`	Babelfish `READ COMMITTED`
`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 apportées à 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 reçoit 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 un identifiant = 1.	La transaction 1 met à jour la ligne avec un identifiant = 3.

Comparaison de Babelfish avec le `READ COMMITTED` niveau d'isolation SQL du serveur `READ COMMITTED SNAPSHOT`

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 READ COMMITTED SNAPSHOT d'isolation dans SQL Server par rapport à l'implémentation de READ COMMITTED Babelfish.

Transaction 1	Transaction 2	SQLserveur `READ COMMITTED SNAPSHOT`	Babelfish `READ COMMITTED`
`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;`	L'étape est 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)	Commission réussie. La transaction 2 est désormais débloquée.	Commission réussie.
État Idle in transaction (Transaction inactive)	`SELECT * FROM employee;`	Les 4 lignes ont un age = 99.	La ligne avec id = 4 a une 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 à age=99.

Comparaison de Babelfish avec le `REPEATABLE READ` niveau d'isolation SQL du serveur `REPEATABLE READ`

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 REPEATABLE READ d'isolation dans SQL Server par rapport à l'implémentation de REPEATABLE READ Babelfish.

Transaction 1	Transaction 2	SQLserveur `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 et de l'écriture lorsque des transactions simultanées sont exécutées. Il montre les résultats observés lors de l'utilisation du niveau REPEATABLE READ d'isolation dans SQL Server par rapport à l'implémentation de REPEATABLE READ Babelfish.

Transaction 1	Transaction 2	SQLserveur `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 réussi et la transaction 2 échoue avec une erreur. Impossible de sérialiser l'accès en raison d'une mise à jour simultanée.
État Idle in transaction (Transaction inactive)	`COMMIT`	Commission 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 possède Name='A_ 'TX2.	La ligne avec id=1 possède Name='A_ 'TX1.

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

Transaction 1	Transaction 2	SQLserveur `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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 les différents résultats finaux lors de l'utilisation du niveau REPEATABLE READ d'isolation dans SQL Server par rapport à l'implémentation de REPEATABLE READ Babelfish.

Transaction 1	Transaction 2	SQLserveur `REPEATABLE READ`	Babelfish `REPEATABLE READ`
`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'SELECTinstruction tente de lire les lignes verrouillées par UPDATE une requête dans la transaction 1.	La transaction 2 se déroule sans aucun blocage puisque la lecture n'est jamais bloquée, l'SELECTinstruction s'exécute et enfin la ligne avec id = 3 est 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 Transaction 2.
`COMMIT`	État Idle in transaction (Transaction inactive)	La transaction 2 est désormais débloquée.	Commission 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 avec un identifiant = 1.	Les différentes lignes sont mises à jour par les transactions 1 et 2.

Comparaison de Babelfish avec le `SERIALIZABLE` niveau d'isolation SQL du serveur `SERIALIZABLE`

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 SERIALIZABLE d'isolation dans SQL Server par rapport à l'implémentation de SERIALIZABLE Babelfish.

Transaction 1	Transaction 2	SQLserveur `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 les différents résultats finaux lors de l'utilisation du niveau SERIALIZABLE d'isolation dans SQL Server par rapport à l'implémentation de SERIALIZABLE Babelfish.

Transaction 1	Transaction 2	SQLserveur `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 INSERT entrez dans une table avec une contrainte unique. Il montre les résultats observés lors de l'utilisation du niveau SERIALIZABLE d'isolation dans SQL Server par rapport à l'implémentation de SERIALIZABLE Babelfish.

Transaction 1	Transaction 2	SQLserveur `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 abandonnée avec une erreur. La valeur de la clé dupliquée viole une 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 et n'ont pas pu sérialiser l'accès 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 Isolation Level serializable échoueront 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 possibles (une par une) 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 SERIALIZABLE d'isolation dans SQL Server par rapport à l'implémentation de SERIALIZABLE Babelfish.

Transaction 1	Transaction 2	SQLserveur `SERIALIZABLE`	Babelfish `SERIALIZABLE`
`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 aux deux transactions sont visibles.	La transaction 2 a été annulée. Seules les modifications apportées à 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 de l'isolement. SERIALIZABLE Dans le tableau suivant, prenons l'exemple ci-dessus, mais définissons REPEATABLE READ plutôt la transaction 2 au niveau d'isolation.

Transaction 1	Transaction 2	SQLNiveaux d'isolation des serveurs	Niveaux d'isolement de 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 aux deux transactions sont visibles.	Les modifications apportées aux 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'isolation des transactions dans Babelfish

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