READ UNCOMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ UNCOMMITTED READ COMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ COMMITTED READ COMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ COMMITTED SNAPSHOT REPEATABLE READ de Babelfish en comparación con el nivel de aislamiento de SQL Server REPEATABLE READ SERIALIZABLE de Babelfish en comparación con el nivel de aislamiento de SQL Server SERIALIZABLE

Comparación de los niveles de aislamiento de Babelfish y SQL Server

A continuación se muestran algunos ejemplos sobre los matices de la forma en que SQL Server y Babelfish implementan los niveles de aislamiento ANSI.

nota

El nivel de aislamiento REPEATABLE READ y SNAPSHOT son iguales en Babelfish.
El nivel de aislamiento READ UNCOMMITTED y READ COMMITTED son iguales en Babelfish.

En el ejemplo siguiente, se muestra cómo crear la tabla base para todos los ejemplos que se mencionan a continuación:


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);

Temas

READ UNCOMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ UNCOMMITTED
READ COMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ COMMITTED
READ COMMITTED de Babelfish en comparación con el nivel de aislamiento de SQL Server READ COMMITTED SNAPSHOT
REPEATABLE READ de Babelfish en comparación con el nivel de aislamiento de SQL Server REPEATABLE READ
SERIALIZABLE de Babelfish en comparación con el nivel de aislamiento de SQL Server SERIALIZABLE

`READ UNCOMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ UNCOMMITTED`

La siguiente tabla proporciona detalles sobre las lecturas sucias cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento READ UNCOMMITTED en SQL Server en comparación con la implementación de Babelfish.

Transacción 1	Transacción 2	`READ UNCOMMITTED` de SQL Server	`READ UNCOMMITTED` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED;`	Ninguna	Ninguna
Inactividad en la transacción	`UPDATE employee SET age=0;`	Actualización realizada correctamente.	Actualización realizada correctamente.
Inactividad en la transacción	`INSERT INTO employee VALUES (4, 'D', 40);`	La inserción se ha realizado correctamente.	La inserción se ha realizado correctamente.
`SELECT * FROM employee;`	Inactividad en la transacción	La transacción 1 puede ver los cambios no confirmados de la transacción 2.	Igual que `READ COMMITTED` en Babelfish. Los cambios no confirmados de la transacción 2 no son visibles en la transacción 1.
Inactividad en la transacción	`COMMIT`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ve los cambios efectuados por la transacción 2.	Ve los cambios efectuados por la transacción 2.

`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED`

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento READ COMMITTED en SQL Server en comparación con la implementación de Babelfish.

Transacción 1	Transacción 2	`READ COMMITTED` de SQL Server	`READ COMMITTED` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`UPDATE employee SET age=100 WHERE id = 1;`	Actualización realizada correctamente.	Actualización realizada correctamente.
`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	Inactividad en la transacción	Paso bloqueado hasta que se confirme la transacción 2.	Los cambios en la transacción 2 aún no están visibles. Actualiza la fila con id=3.
Inactividad en la transacción	`COMMIT`	La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada y recibe la actualización de la transacción 2.	La transacción 2 se confirma correctamente.
`SELECT * FROM employee;`	Inactividad en la transacción	La transacción 1 actualiza la fila con el id = 1.	La transacción 1 actualiza la fila con el id = 3.

`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED SNAPSHOT`

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de las filas recién insertadas cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento READ COMMITTED SNAPSHOT en SQL Server en comparación con la implementación de Babelfish READ COMMITTED.

Transacción 1	Transacción 2	`READ COMMITTED SNAPSHOT` de SQL Server	`READ COMMITTED` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	`SET TRANSACTION ISOLATION LEVEL READ COMMITTED;`	Ninguna	Ninguna
`INSERT INTO employee VALUES (4, 'D', 40);`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`UPDATE employee SET age = 99;`	Paso bloqueado hasta que se confirme la transacción 1. La fila insertada está bloqueada por la transacción 1.	Se actualizaron tres filas. La fila recién insertada aún no está visible.
`COMMIT`	Inactividad en la transacción	Confirmación realizada correctamente. La transacción 2 ahora está desbloqueada.	Confirmación realizada correctamente.
Inactividad en la transacción	`SELECT * FROM employee;`	Las 4 filas tienen una age=99.	La fila con un id = 4 tiene un valor de antigüedad de 40, ya que la transacción 2 no la pudo ver durante la consulta de actualización. Las demás filas se actualizan a una age=99.

`REPEATABLE READ` de Babelfish en comparación con el nivel de aislamiento de SQL Server `REPEATABLE READ`

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento REPEATABLE READ en SQL Server en comparación con la implementación de Babelfish REPEATABLE READ.

Transacción 1	Transacción 2	`REPEATABLE READ` de SQL Server	`REPEATABLE READ` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee WHERE id != 1;`	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee;`	La transacción 2 se bloquea hasta que se confirme la transacción 1.	La transacción 2 se lleva a cabo con normalidad.
`COMMIT`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee;`	La actualización de la transacción 1 está visible.	La actualización de la transacción 1 no está visible.
`COMMIT`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee;`	ve la actualización de la transacción 1.	ve la actualización de la transacción 1.

La siguiente tabla proporciona detalles sobre el comportamiento de bloqueo de lectura y escritura cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento REPEATABLE READ en SQL Server en comparación con la implementación de Babelfish REPEATABLE READ.

Transacción 1	Transacción 2	`REPEATABLE READ` de SQL Server	`REPEATABLE READ` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Ninguna	Ninguna
`UPDATE employee SET name='A_TXN1' WHERE id=1;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`UPDATE employee SET name='A_TXN2' WHERE id=1;`	Transacción 2 bloqueada.	Transacción 2 bloqueada.
`COMMIT`	Inactividad en la transacción	La confirmación se ha realizado correctamente y la transacción 2 se ha desbloqueado.	La confirmación se ha realizado correctamente y la transacción 2 falló debido a un error de tipo “No se pudo serializar el acceso debido a una actualización simultánea”.
Inactividad en la transacción	`COMMIT`	Confirmación realizada correctamente.	La transacción 2 ya se ha cancelado.
Inactividad en la transacción	`SELECT * FROM employee;`	La fila con id=1 tiene name='A_TX2'.	La fila con id=1 tiene name='A_TX1'.

La siguiente tabla proporciona detalles sobre el comportamiento de las lecturas fantasma cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento REPEATABLE READ en SQL Server en comparación con la implementación de Babelfish REPEATABLE READ.

Transacción 1	Transacción 2	`REPEATABLE READ` de SQL Server	`REPEATABLE READ` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`INSERT INTO employee VALUES (4, 'NewRowName', 20);`	La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.	La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.
Inactividad en la transacción	`SELECT * FROM employee;`	La fila recién insertada está visible.	La fila recién insertada está visible.
Inactividad en la transacción	`COMMIT`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	La nueva fila insertada por la transacción 2 está visible.	La nueva fila insertada por la transacción 2 no está visible.
`COMMIT`	Inactividad en la transacción	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	La fila recién insertada está visible.	La fila recién insertada está visible.

La siguiente tabla proporciona detalles sobre cuándo se ejecutan transacciones simultáneas y los diferentes resultados finales cuando se utiliza el nivel de aislamiento REPEATABLE READ en SQL Server en comparación con la implementación de Babelfish REPEATABLE READ.

Transacción 1	Transacción 2	`REPEATABLE READ` de SQL Server	`REPEATABLE READ` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Ninguna	Ninguna
`UPDATE employee SET age = 100 WHERE age IN (SELECT MIN(age) FROM employee);`	Inactividad en la transacción	La transacción 1 actualiza la fila con el id 1.	La transacción 1 actualiza la fila con el id 1.
Inactividad en la transacción	`UPDATE employee SET age = 0 WHERE age IN (SELECT MAX(age) FROM employee);`	La transacción 2 está bloqueada porque la instrucción SELECT intenta leer las filas bloqueadas por la consulta UPDATE en la transacción 1.	La transacción 2 se realiza sin ningún bloqueo, ya que la lectura nunca se bloquea, la instrucción SELECT se ejecuta y, finalmente, la fila con el id = 3 se actualiza, ya que los cambios en la transacción 1 aún no están visibles.
Inactividad en la transacción	`SELECT * FROM employee;`	Este paso se ejecuta después de que se haya confirmado la transacción 1. La fila con el id = 1 se actualiza con la transacción 2 del paso anterior y está visible aquí.	La fila con un id = 3 se actualiza mediante la transacción 2.
`COMMIT`	Inactividad en la transacción	La transacción 2 ahora está desbloqueada.	Confirmación realizada correctamente.
Inactividad en la transacción	`COMMIT`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ambas transacciones ejecutan una actualización en la fila con un id = 1.	Las distintas filas se actualizan por las transacciones 1 y 2.

`SERIALIZABLE` de Babelfish en comparación con el nivel de aislamiento de SQL Server `SERIALIZABLE`

La siguiente tabla proporciona detalles sobre los bloqueos de rango cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento SERIALIZABLE en SQL Server en comparación con la implementación de Babelfish SERIALIZABLE.

Transacción 1	Transacción 2	`SERIALIZABLE` de SQL Server	`SERIALIZABLE` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`INSERT INTO employee VALUES (4, 'D', 35);`	La transacción 2 se bloquea hasta que se confirme la transacción 1.	La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.
Inactividad en la transacción	`SELECT * FROM employee;`	Ninguna	Ninguna
`COMMIT`	Inactividad en la transacción	La transacción 1 se confirma correctamente. La transacción 2 ahora está desbloqueada.	La transacción 1 se confirma correctamente.
Inactividad en la transacción	`COMMIT`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	La fila recién insertada está visible.	La fila recién insertada está visible.

La siguiente tabla proporciona detalles sobre cuándo se ejecutan transacciones simultáneas y los diferentes resultados finales cuando se utiliza el nivel de aislamiento SERIALIZABLE en SQL Server en comparación con la implementación de Babelfish SERIALIZABLE.

Transacción 1	Transacción 2	`SERIALIZABLE` de SQL Server	`SERIALIZABLE` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Ninguna	Ninguna
Inactividad en la transacción	`INSERT INTO employee VALUES (4, 'D', 40);`	Ninguna	Ninguna
`UPDATE employee SET age =99 WHERE id = 4;`	Inactividad en la transacción	La transacción 1 se bloquea hasta que se confirme la transacción 2.	La transacción 1 se lleva a cabo sin ningún tipo de bloqueo.
Inactividad en la transacción	`COMMIT`	La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada.	La transacción 2 se confirma correctamente.
`COMMIT`	Inactividad en la transacción	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	La fila recién insertada es visible con un valor de age = 99.	La fila recién insertada es visible con un valor de age = 40.

En la siguiente tabla se proporcionan detalles cuando realiza la operación INSERT en una tabla con una restricción única. Muestra los resultados observados al utilizar el nivel de aislamiento SERIALIZABLE en SQL Server en comparación con la implementación de Babelfish SERIALIZABLE.

Transacción 1	Transacción 2	`SERIALIZABLE` de SQL Server	`SERIALIZABLE` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Ninguna	Ninguna
Inactividad en la transacción	`INSERT INTO employee VALUES (4, 'D', 40);`	Ninguna	Ninguna
`INSERT INTO employee VALUES ((SELECT MAX(id)+1 FROM employee), 'E', 50);`	Inactividad en la transacción	La transacción 1 se bloquea hasta que se confirme la transacción 2.	La transacción 1 se bloquea hasta que se confirme la transacción 2.
Inactividad en la transacción	`COMMIT`	La transacción 2 se confirma correctamente. La transacción 1 ahora está desbloqueada.	La transacción 2 se confirma correctamente. La transacción 1 abortada por un error de tipo “el valor clave duplicado infringe una restricción única”.
`COMMIT`	Inactividad en la transacción	La transacción 1 se confirma correctamente.	La confirmación de la transacción 1 falla y no se pudo serializar el acceso debido a las dependencias de lectura o escritura entre las transacciones.
`SELECT * FROM employee;`	Inactividad en la transacción	se inserta la fila (5, 'E', 50).	Solo existen 4 filas.

En Babelfish, las transacciones simultáneas que se ejecutan con nivel de aislamiento Serializable fallarán y generarán un error de anomalía de serialización si la ejecución de estas transacciones no es coherente con todas las posibles ejecuciones en serie (una a la vez) de esas transacciones.

Las siguientes tablas proporcionan detalles sobre la anomalía de la serialización cuando se ejecutan transacciones simultáneas. Muestra los resultados observados al utilizar el nivel de aislamiento SERIALIZABLE en SQL Server en comparación con la implementación de Babelfish SERIALIZABLE.

Transacción 1	Transacción 2	`SERIALIZABLE` de SQL Server	`SERIALIZABLE` de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
`UPDATE employee SET age=5 WHERE age=10;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee;`	La transacción 2 se bloquea hasta que se confirme la transacción 1.	La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.
Inactividad en la transacción	`UPDATE employee SET age=35 WHERE age=30;`	Ninguna	Ninguna
`COMMIT`	Inactividad en la transacción	La transacción 1 se confirma correctamente.	La transacción 1 se confirma primero y puede confirmarse correctamente.
Inactividad en la transacción	`COMMIT`	La transacción 2 se confirma correctamente.	La confirmación de la transacción 2 falla con un error de serialización, se revierte toda la transacción. Vuelva a intentar la transacción 2.
`SELECT * FROM employee;`	Inactividad en la transacción	Los cambios de ambas transacciones son visibles.	La transacción 2 se revirtió. Solo se ven los cambios en la transacción 1.

En Babelfish, la anomalía de serialización solo es posible si todas las transacciones simultáneas se ejecutan en el nivel de aislamiento SERIALIZABLE. En la siguiente tabla, tomemos el ejemplo anterior, pero establezcamos la transacción 2 en el nivel de aislamiento REPEATABLE READ.

Transacción 1	Transacción 2	Niveles de aislamiento de SQL Server	Niveles de aislamiento de Babelfish
`BEGIN TRANSACTION`	`BEGIN TRANSACTION`	Ninguna	Ninguna
`SET TRANSACTION ISOLATION LEVEL SERILAIZABLE;`	`SET TRANSACTION ISOLATION LEVEL REPEATABLE READ;`	Ninguna	Ninguna
`SELECT * FROM employee;`	Inactividad en la transacción	Ninguna	Ninguna
`UPDATE employee SET age=5 WHERE age=10;`	Inactividad en la transacción	Ninguna	Ninguna
Inactividad en la transacción	`SELECT * FROM employee;`	La transacción 2 se bloquea hasta que se confirme la transacción 1.	La transacción 2 se lleva a cabo sin ningún tipo de bloqueo.
Inactividad en la transacción	`UPDATE employee SET age=35 WHERE age=30;`	Ninguna	Ninguna
`COMMIT`	Inactividad en la transacción	La transacción 1 se confirma correctamente.	La transacción 1 se confirma correctamente.
Inactividad en la transacción	`COMMIT`	La transacción 2 se confirma correctamente.	La transacción 2 se confirma correctamente.
`SELECT * FROM employee;`	Inactividad en la transacción	Los cambios de ambas transacciones son visibles.	Los cambios de ambas transacciones son visibles.

Aviso JavaScript está desactivado o no está disponible en su navegador.

Para utilizar la documentación de AWS, debe estar habilitado JavaScript. Para obtener más información, consulte las páginas de ayuda de su navegador.

Convenciones del documento

Niveles de aislamiento de transacciones en Babelfish

Uso de las características de Babelfish con implementación limitada