# Comparación de los niveles de aislamiento de Babelfish y SQL Server
<a name="babelfish-transaction.examples"></a>

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

**Topics**
+ [`READ UNCOMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ UNCOMMITTED`](#babelfish-transaction.examples.unc)
+ [`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED`](#babelfish-transaction.examples.com)
+ [`READ COMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ COMMITTED SNAPSHOT`](#babelfish-transaction.examples.snapshot)
+ [`REPEATABLE READ` de Babelfish en comparación con el nivel de aislamiento de SQL Server `REPEATABLE READ`](#babelfish-transaction.examples.read)
+ [`SERIALIZABLE` de Babelfish en comparación con el nivel de aislamiento de SQL Server `SERIALIZABLE`](#babelfish-transaction.examples.serialize)

## `READ UNCOMMITTED` de Babelfish en comparación con el nivel de aislamiento de SQL Server `READ UNCOMMITTED`
<a name="babelfish-transaction.examples.unc"></a>

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`
<a name="babelfish-transaction.examples.com"></a>

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`
<a name="babelfish-transaction.examples.snapshot"></a>

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`
<a name="babelfish-transaction.examples.read"></a>

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`
<a name="babelfish-transaction.examples.serialize"></a>

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. |